聲明
本文歡迎轉載，請注明文章原始出處：http://www.cnblogs.com/DjlNet/p/7603632.html
前言
在上篇文章當中我們知道關於Quartz.NET的一些情況，其實博主再寫Quartz.Net的時候也注意到了我們今天需要了解的Hangfirehttps://www.hangfire.io，之所以為何我們在了解Quartz.Net的同時還去了解另一款定時任務框架吶？這里博主抱着好奇的心態，聽說此框架各種各種好，但是博主本來覺得Quartz.Net歷經歲月之后本身已經挺優秀的了且已經支持.net core了beta版，噢耶！！，所以我們還是對Hangfire來個一探究竟吧，順便也能對比一下它們之間異同....
廢話時間：今天（2017年10月21日12:00:46）是S7全球總決賽系列賽事的LPL隊伍上場的日子，雖然博主偶爾和老鐵們玩玩LOL，但是對於電競帶來的那種熱情和團隊精神所深受感動鼓舞，而當今再也沒有洪水猛獸的楊叫獸了，這話總超級扭曲的東西存在了，電競也成了一項新的行業支撐數以千計的人在為之奮斗！好了，不扯遠了，就當博主從競技比賽中，看到的是為之奮斗人們的汗水和努力吧！！！游戲並不一定是毒葯，它也可以是催化劑，就得施葯人的手法了！
Hangfire文檔划重點
這里博主首先把英文官方文檔通刷了一邊，基本整體感覺是差不多能有的都有了，當然也是支持.net core的，更加着重於框架本身的易用性和用戶體驗相關的東西，導致我都覺得不像是在看一個框架或者東西，而是處於一種再看一個產品的眼光了，是的，它還是確實是一款收費的產品了
Hangfire Pro這個收費了，不過基本感覺收費的功能也就那樣，一般情況感覺開發者還是夠了哈......接着博主在園中一搜不出所料，原來很多老鐵都已經用上了此框架，也說明了一定的影響力了，還有些.NET開發者在推動這玩意兒的發展，那么我們還是老規矩帶着文檔的着重點以及園中園友的研究一起看看這玩意兒的優缺點！！！
Hangfire設計上面的思考
這里首先引用官方的示意圖，然后我們接着分析這樣設計以及相比於Quartz.Net的設計而言它們的異同之處（Quartz.Net設計圖參考博主上文地址）。
從圖中可以看出，整體組織結構的設計上面分成主要的三大塊:
1、任務存儲器JobStorage；
2、客戶端添加對應類型的任務BackgroundJobClient、BackgroundJob、RecurringJob；
3、任務處理器處理存儲中待處理的任務BackgroundJobServer
由這三者共同協作完成任務的添加到存儲到執行的一整條使用鏈。
這里我們回想一下Quartz.Net的組織結構（主要成分是1、任務JobDetail；2、觸發器Trigger；3、任務與觸發器存儲Storage；4、調度器Scheduler），也可能是因為定時器本身使用需求所致，到這里不知道大家有木有感受到兩者的大體設計考慮上很多相似之處：
a、同樣的組件式職責分離設計；
b、同樣都支持持久化存儲利用數據庫鎖支持多實例集群；
c、框架本身都支持較好的擴展winservice、topshelf、ioc等等和使用包含多種任務類型與Cron表達式等等
從這里也給我們開發者一個思考就是在設計一個框架是所需要考慮的問題，所以從上面來看出於設計而言，大家基本都是該做到的都做到，也基本二者選其一都可以滿足一般業務需求了，只是在具體實現上面大家側重點可能頗有不同罷了，接下來關於不同之處不限於設計也包括使用層面：
a、Hangfire的設計到實現的思路是通過序列化 [Newtonsoft.Json] 任務持久化到數據庫(泛指且不是RAM模式且RAM模式需要第三方包才支持)，這樣一來就完全隔離了Job與JobProcessor之間的關系，因為它們之間的紐帶是Queue已經在落地數據庫層面了，從這里也可以看出作者是更加注重於功能獨立且更加偏向引導使用者更加關注於自己的業務邏輯方便集成進來方便，也看得出來作者的心意了哈，所以相對而言通過隊列使得二者貌似不知道對方的存在一樣，這樣設計巧妙的規避了任務創建和任務調度之間復雜和交織的關系，同樣帶來的負面效應就是基於數據庫來支持增加了依賴項以及受限於數據庫連接數的性能瓶頸的影響（不過一般都不是事兒），但是這里需要注意的一點就是雖然不用相互感知，但是需要client在添加任務的時候以及server在調度執行任務是它們使用的相關class、assembly需要所共有，不然解析不了的。相比之下 Quartz.Net 就需要在代碼級別層面 Scheduler 與 Trigger 或者 JobDetail 耦合，同樣可以持久化到數據庫做到多機部署，延續了一直以來的設計思路且相互之間可以組合可實現可配置復雜的應用開發，且不說那種方式好，這是指出它們的思路不同之處，好不好不是我說算，是技術選型和使用者的感受來定的，切莫為了捧一個而故意摔另一個就不好了，站在思考欣賞的角度看問題就好....
b、Quartz.Net支持秒級單位的定時任務處理，但是Hangfire只能支持分鍾及以上的定時任務處理，原因在於Hangfire用的是開源的NCrontab組件，跟linux上的crontab指令相似，且Quartz.Net支持任務和觸發器之間的組合使用構建復雜的關系，Hangfire在指定任務時就需要指定類型和調度規則，是一一對應關系，這個得看使用者需求對於這兩者的需求度如何而定，並沒有必選項
c、UI控制台方面：這里Hangfire對於任務UI（Hangfire Dashborad）方面展示下了功夫了，界面簡潔展示信息充足而且支持自定義擴展，不限於Job、Queue、Server、Detail等信息以及統計結果，這里基本上都滿足了開發者的監控需求了，且還圖表可以查看每天/周的大致情況，支持手動重啟任務刪除查看詳情等等，相比Quartz.Net官方是沒提供UI控制台界面，由社區開發者提供了一個第三方擴展的UI界面，也大致能夠做到展示統計信息和運行情況，還算是朴實簡潔，這里博主還是更加偏向於Hangfire的界面更加分一些，哈哈！Hangfire這里還包含UI界面的訪問權限控制，貌似Quartz.Net的擴展https://github.com/guryanovev/CrystalQuartz木有權限控制，所以被壞人知道地址就麻煩了，當然也可以自己找方法ip過濾白名單之類的，或者加上基本權限過濾改寫默認實現......
所以綜上的話，一般情況如果對整體任務的統計以及詳情查看UI界面和易用性上面考慮的話，Hangfire 也可以出作為技術選型的一個參考選擇，以及對於時間刻度上面的要求可以接受分鍾級別的話就可以考慮使用這種來的直接的框架，Quarzt.Net 對於沒怎么使用過的老鐵來說，結構組織略微比 Hangfire 代碼上面編寫復雜些了吧...
Hangfire 文檔選擇性記錄
BackgroundJobClient、BackgroundJob、RecurringJob ，客戶端主要的3個類的API分別表示了可以添加不同類型的Job到storage當中，會序列化方法信息（所以這里API是通過表達式來傳遞，可以是靜態方法或者實例方法，這樣就可以通過表達式才能來命名任務job名字）及其所有參數，根據序列化信息創建一個新的后台作業，將后台作業保存到持久存儲，將后台作業排入隊列，所以並不會立即調用方法。然后接着由服務端啟動的工作線程處理，獲取下一個工作並與其他工作線程互斥的拿取任務，執行作業及其所有擴展過濾器，最后執行完畢從隊列中刪除該作業。
1、使作業任務如果需要傳遞參數盡量小而簡單，方法調用（即作業）在后台作業創建過程中被序列化，使用TypeConverter類將參數轉換為JSON字符串。如果您有復雜的實體和/或大對象;包括數組，最好將它們放入數據庫，然后將其身份（例如傳遞userid、orderid 之類的）只傳遞給后台作業。
2、使用 DisableConcurrentExecution(timeout) ，[AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface | AttributeTargets.Method)]，可以把此標記方法或者類或者接口上面，可以使得執行的任務防止並發
寫到這里發現文檔當中的東西，好像還真沒什么可以寫了( 尷尬，捂臉！ )，可能也是單純看文檔的緣故吧，沒有把應用於實際項目當中的話，對於一些套路的使用以及設計可能也只能存在一些想法但是並沒有實戰，所以在於后面文章當中，可能就不會就單單對於框架本身的使用啥的過多的了解，需要盡可能把框架集成到系統當中去使用起來，之后再把途中遇到的問題記錄下來....
照例備份園中同類型文
1、Hangfire項目實踐分享 http://www.cnblogs.com/ecin/p/hangfire-best-practice.html
2、開源的.NET定時任務組件Hangfire解析 http://www.cnblogs.com/pengze0902/p/6583119.html
3、.NET Core開源組件:后台任務利器之Hangfire http://www.cnblogs.com/chenug/p/6655636.html#top
4、執行后台任務的利器——Hangfire http://www.cnblogs.com/heyu/articles/6404336.html
總結
可能此文，總的來說主要是博主對於此框架關於設計上面的一些自己的思考和解讀，以及與 Quartz.Net 的設計上面的對比以及一些各自的着重點偏向與使用者的需求吧，其次就是關於文檔當中的一些主要對象的解讀和對於任務的一系列操作流程等等，所以總之啦，無論使用那種關於定時器的框架，都要遵循一些大家共識的原則，例如：任務job參數傳遞的原則之類的，還有就是盡可能遵循各自框架當中所寫到的一些最佳使用法制。可能博主在框架學習的路上越走越遠，越走越迷，為什么吶？博主常常問自己，在了解如何使用某某框架之后，自己得到的是什么，又知道了些什么，所以框架是學不會完的，那博主就可能不會局限於框架的學習了，更加需要在理論和概念的學習與思考上面下功夫了...
此文是博主對於hangfire的一些小記錄，如果對您有一點點幫助，您的評論和點贊都是對博主很大的支持！