【框架學習與探究之定時器--Hangfire】

時間 2019-11-11

標籤框架學習探究定時器 hangfire 简体版

原文原文鏈接

聲明

本文歡迎轉載，請註明文章原始出處：http://www.cnblogs.com/DjlNet/p/7603632.htmlhtml

前言

在上篇文章當中咱們知道關於Quartz.NET的一些狀況，其實博主再寫Quartz.Net的時候也注意到了咱們今天須要瞭解的Hangfirehttps://www.hangfire.io，之因此爲什麼咱們在瞭解Quartz.Net的同時還去了解另外一款定時任務框架吶？這裏博主抱着好奇的心態，據說此框架各類各類好，可是博主原本以爲Quartz.Net歷經歲月以後自己已經挺優秀的了且已經支持.net core了beta版，噢耶！！，因此咱們仍是對Hangfire來個一探究竟吧，順便也能對比一下它們之間異同....linux

廢話時間：今天（2017年10月21日12:00:46）是S7全球總決賽系列賽事的LPL隊伍上場的日子，雖然博主偶爾和老鐵們玩玩LOL，可是對於電競帶來的那種熱情和團隊精神所深受感動鼓舞，而當今再也沒有洪水猛獸的楊叫獸了，這話總超級扭曲的東西存在了，電競也成了一項新的行業支撐數以千計的人在爲之奮鬥！好了，不扯遠了，就當博主從競技比賽中，看到的是爲之奮鬥人們的汗水和努力吧！！！遊戲並不必定是毒藥，它也能夠是催化劑，就得施藥人的手法了！git

Hangfire文檔劃重點

這裏博主首先把英文官方文檔通刷了一邊，基本總體感受是差很少能有的都有了，固然也是支持.net core的，更加着重於框架自己的易用性和用戶體驗相關的東西，致使我都以爲不像是在看一個框架或者東西，而是處於一種再看一個產品的眼光了，是的，它仍是確實是一款收費的產品了Hangfire Pro這個收費了，不過基本感受收費的功能也就那樣，通常狀況感受開發者仍是夠了哈......接着博主在園中一搜不出所料，原來不少老鐵都已經用上了此框架，也說明了必定的影響力了，還有些.NET開發者在推進這玩意兒的發展，那麼咱們仍是老規矩帶着文檔的着重點以及園中園友的研究一塊兒看看這玩意兒的優缺點！！！github

Hangfire設計上面的思考

這裏首先引用官方的示意圖，而後咱們接着分析這樣設計以及相比於Quartz.Net的設計而言它們的異同之處（Quartz.Net設計圖參考博主上文地址）。

從圖中能夠看出，總體組織結構的設計上面分紅主要的三大塊:
一、任務存儲器JobStorage；
二、客戶端添加對應類型的任務BackgroundJobClient、BackgroundJob、RecurringJob；
三、任務處理器處理存儲中待處理的任務BackgroundJobServer
由這三者共同協做完成任務的添加到存儲到執行的一整條使用鏈。數據庫

這裏咱們回想一下Quartz.Net的組織結構（主要成分是一、任務JobDetail；二、觸發器Trigger；三、任務與觸發器存儲Storage；四、調度器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名字）及其全部參數，根據序列化信息建立一個新的後臺做業，將後臺做業保存到持久存儲，將後臺做業排入隊列，因此並不會當即調用方法。而後接着由服務端啓動的工做線程處理，獲取下一個工做並與其餘工做線程互斥的拿取任務，執行做業及其全部擴展過濾器，最後執行完畢從隊列中刪除該做業。

一、使做業任務若是須要傳遞參數儘可能小而簡單，方法調用（即做業）在後臺做業建立過程當中被序列化，使用TypeConverter類將參數轉換爲JSON字符串。若是您有複雜的實體和/或大對象;包括數組，最好將它們放入數據庫，而後將其身份（例如傳遞userid、orderid 之類的）只傳遞給後臺做業。

二、使用 DisableConcurrentExecution(timeout) ，[AttributeUsage(AttributeTargets.Class | AttributeTargets.Interface | AttributeTargets.Method)]，能夠把此標記方法或者類或者接口上面，可使得執行的任務防止併發

寫到這裏發現文檔當中的東西，好像還真沒什麼能夠寫了( 尷尬，捂臉！ )，可能也是單純看文檔的緣故吧，沒有把應用於實際項目當中的話，對於一些套路的使用以及設計可能也只能存在一些想法可是並無實戰，因此在於後面文章當中，可能就不會就單單對於框架自己的使用啥的過多的瞭解，須要儘量把框架集成到系統當中去使用起來，以後再把途中遇到的問題記錄下來....

照例備份園中同類型文

一、Hangfire項目實踐分享 http://www.cnblogs.com/ecin/p/hangfire-best-practice.html
二、開源的.NET定時任務組件Hangfire解析 http://www.cnblogs.com/pengze0902/p/6583119.html
三、.NET Core開源組件:後臺任務利器之Hangfire http://www.cnblogs.com/chenug/p/6655636.html#top
四、執行後臺任務的利器——Hangfire http://www.cnblogs.com/heyu/articles/6404336.html

總結

可能此文，總的來講主要是博主對於此框架關於設計上面的一些本身的思考和解讀，以及與 Quartz.Net 的設計上面的對比以及一些各自的着重點偏向與使用者的需求吧，其次就是關於文檔當中的一些主要對象的解讀和對於任務的一系列操做流程等等，因此總之啦，不管使用那種關於定時器的框架，都要遵循一些你們共識的原則，例如：任務job參數傳遞的原則之類的，還有就是儘量遵循各自框架當中所寫到的一些最佳使用法制。可能博主在框架學習的路上越走越遠，越走越迷，爲何吶？博主經常問本身，在瞭解如何使用某某框架以後，本身獲得的是什麼，又知道了些什麼，因此框架是學不會完的，那博主就可能不會侷限於框架的學習了，更加須要在理論和概念的學習與思考上面下功夫了...

此文是博主對於hangfire的一些小記錄，若是對您有一點點幫助，您的評論和點贊都是對博主很大的支持！