上篇 yarn原始碼分析之集群啟動流程 我們介紹了yarn的啟動過程，捎帶介紹了asyncdispatcher，但感覺有必要單獨詳細分析下（原始碼版本：hadoop2.7.1）…
為了更好的應對併發，yarn採用了基於事件的非同步模型。所謂基於事件的模型，就是通過事件佇列快取住各種事件，然後通過事件分發器裡的常駐執行緒不斷的從事件佇列裡取事件並將該事件交給相應的事件處理handler（eventhandler）進行處理，是乙個典型的生產者-消費者模型。其原理如下圖：
在yarn中，dispatcher 介面的實現有三種，不過在絕大多數場景下是使用它的一種實現— asyncdispatcher ，下面我們也是重點分析該類的。
register()方法負責註冊事件處理器，geteventhandler()方法獲得事件處理器以派發事件。
asyncdispatcher 內部是 有乙個 阻塞的事件佇列，有乙個一直執行的執行執行緒，當阻塞佇列中有事件被放入，執行執行緒會把事件取出來，並獲取事件的型別，從事件註冊器 map, eventhandler> 中獲取到對應的 eventhandler 物件，並呼叫該物件的 dispatch 方法分發事件。
由之前的文章《學習筆記之yarn啟動過程.md》可知，yarn啟動的入口類是 resourcemanager，而在serviceinit函式中初始化事件驅動器並賦值給全域性變數，由此可知asyncdispatcher作為yarn的常駐服務之一，**如下圖：
同樣由之前的文章《學習筆記之yarn啟動過程.md》可知，在resourcemanager.servicestart->compositeservice.servicestart -> asyncdispatcher.servicestart函式中啟動，檢視 asyncdispatcher **，摘關鍵**：
runnable createthread()
}}event event;
trycatch
(interruptedexception ie)
return;}
if(event != null)}}
};}@override
protected
void
servicestart()
throws exception
protected
void
dispatch
(event event)
class<
?extends
enum
> type = event.
gettype()
.getdeclaringclass()
;try
else
}catch
(throwable t)
}}
檢視上面dispatcher介面發現，register方法是核心方法之一，該方法是將各種事件對應的事件處理器儲存下來，用於判斷哪個handler對應哪個event。下面我們首先看asyncdispatcher中該方法的實現如下：
可以看到該方法比較簡單，僅僅做判斷並put到eventdispatchers中，下面我們看何時呼叫該方法：
在resourcemanager 元件中註冊過程，舉例如下：
註冊完後，asyncdispatcher在消費端就能按照事件型別分發到具體的事件處理器了。
下面列舉註冊的事件處理器便於參閱，如下：
格式：《事件型別，事件處理器》
yarn的事件驅動模型與狀態機：原始碼|yarn的事件驅動模型與狀態機
WebRTC原始碼分析之事件 Event
event原始碼分析 小結event類實現了事件的等待和觸發，通過介面 wait 函式可以實現執行緒的阻塞，而 set 函式可以啟用阻塞的執行緒。event類在webrtc的很多位置都有使用，理解了event類才能更好的閱讀其他webrtc原始碼。event使用示例 工程示例工程 提取碼 cenz ...
NHiberante原始碼分析之 事務
對資料庫的操作是少不了事務處理的，事務能保整資料完整性和有效性。在nh中，使用transaction物件對.net的事務物件 實現了idbtransaction介面的物件 進行了包裝。在nh中，乙個典型的事務處理是這樣的 見isession.cs的注釋 isession sess factory.o...
Redis原始碼分析之事務
redis是通過multi discard exec watch四個命令來實現事務的。事務提供了一種將多個命令打包，然後一次性並順序的執行所有命令的機制，並且事務在執行中不會主動中斷，伺服器只有在事務執行完後，才會繼續執行其他客戶端的請求。下面是乙個事務的例子 redis multi okredis...