一、heartbeat模組：
整個heartbeat軟體的通訊模組，各個節點之間的任何通訊都是通過這個模組完成。這個模組會根據不同型別的通訊啟動不同的事件 handler，當監聽到不同型別的通訊請求後會分給不同的handler來處理。這個從整個heartbeat的啟動日誌中看出來。
二、crm：cluster resource manager
從這個名字就可以看出這個模組基本上就是v2的heartbeat的乙個只會中心，整個系統的乙個大腦了，他主要負責整個系統的各種資源的 當前配置資訊，以及各個資源的排程。也就是根據各資源的配置資訊，以及當前的執行狀況來決定每乙個資源（或者資源組）到底該在哪個節點執行。不過這些事情 並不是他直接去做的，而是通過排程其他的一些模組來進行。
他通過heartbeat模組來進行節點之間的通訊，排程節點之間的工作協調。隨時將通過heartbeat模組收集到的各個成員節點的基 本資訊轉交給ccm某塊來更新整個集群的membership資訊。他指揮lrm（local resource manager）對當前節點的各資源執行各種相應的操作（如start、stop、restart和monitor等等），同時也接收lrm在進行各種操 作的反饋資訊並作出相應的決策再指揮後續工作。另外crm模組還負責將各個模組反饋回來的各種資訊通過呼叫設定的日誌記錄程式記錄到日誌檔案中。
三、lrm：local resource manager
lrm是整個heartbeat系統中直接操作所管理的各個資源的乙個模組，負責對資源的監控，啟動，停止或者重啟等操作。這個模組目前好 像支援有四種型別的資源**（resource agent）：heartbeat自身的，ocf（open cluster framework），lsb（linux standard base，其實就是linux下標準的init指令碼），還有一種就是stonith。stonith這種我還不是太清楚是乙個什麼型別的。
四種型別的resource agent中的前三種所呼叫的指令碼分別存如下路徑：
heartbeat：/etc/ha.d/resource.d/
ocf:/usr/lib/resource.d/heartbeat/
lsb:/etc/init.d/
lrm就是通過呼叫以上路徑下面的各種指令碼來實現對資源的各種操作。每一種型別的指令碼都可以由使用者自定義，只要支援各型別的標準即可。實際 上這裡的標準就是接受乙個標準的呼叫命令和引數格式，同時返回符合標準的值即可。至於指令碼中的各種操作時如何的lrm並不care。
四、pe：crm policy engine
他主要負責將crm發過來的一些資訊按照配置檔案中的各種設定來進行計算，分析。然後將結果資訊按照某種固定的格式通過crm提交給te （transition engine）去分析出後續需要採取的相應的action。pe需要計算分析的資訊主要是當前有哪些節點，各節點的狀況，當前管理有哪些資源，各資源當前 在哪乙個節點，在各個節點的狀態如何等等。
五、te：transition engine
主要工作是分析pe的計算結果，然後根據配置資訊轉換成後續所需的相應操作。個人感覺pe和te組合成乙個類似於規則引擎實現的功能，而且 pe和te這兩個模組只有在處於active的節點被啟動。另外pe和te並不直接通訊，而都是通過heartbeat的指揮中心crm來傳達資訊的。
六、cib：cluster information base
cib在系統中充當的是當前集群中各資源原始配置以及之後動態變化了的狀態，統計資訊收集分發中心，是乙個不斷更新的資訊庫。當他收集到任 何資源的變化，以及節點統計資訊的變化後，都會整合整合到一起組成當前集群最新的資訊，並分發到集群各個節點。分發動作並不是自己和各個節點通訊，同樣也 是通過heartbeat模組來做的。
cib收集整理並彙總出來的資訊是以乙個xml格式儲存起來的。實際上heartbeat v2的資源配置檔案也就是從haresources遷移到了乙個叫cib.xml檔案裡面。該檔案實際上就是cib的資訊庫檔案。在執行過程中，cib可 能會常讀取並修改該檔案的內容，以保證資訊的更新。
七、ccm：consensus cluster membership
ccm的最主要工作就是管理集群中各個節點的成員以及各成員之間的關係。他讓集群中各個節點有效的組織稱乙個整體，保持著穩定的連線。heartbeat模組所擔當的只是乙個通訊工具，而ccm是通過這個通訊工具來將各個成員連線到一起成為乙個整體。
八、logd：logging daemon（non-blocking）
乙個無阻塞的日誌記錄程式，主要負責接收crm從各個其他模組所收集的相關資訊，然後記錄到指定額度日誌檔案中。當logd接收到日誌資訊後會立刻返回給crm反饋。並不是一定要等到將所有資訊記錄到檔案後再返回，日誌資訊的記錄實際上是乙個非同步的操作。
十、rmd：recovery manager daemon
**：覺得好分享一下。還有強烈推薦有道筆記，用了一年多了，適合學習。
Jforum中索引模組的分析 2
在第一部分中主要分析了通過searchsetting對檢索和索引進行控制。本部分主要對於搜尋部分lucenesearch類進行乙個分析和闡述。1.lucenesearch類 lucenesearch類主要完成post的檢索功能，通過分析使用者輸入的搜尋引數，反正相關的結果。1.1 通過postid進...
支付模組分析
1，一筆訂單支付成功，會在第一時間通知，系統收到通知處理邏輯，必然返回1個success，第三方接到success就不再通知，否第三方支付平台會認為未收到通知，然後再過10s 20s 180s再 通知你。客戶端會上傳接收通知的介面，定時呼叫，客戶端也要定時去查詢，在錯過第一次接收後，通知通知，非同步...
響應模組分析
響應類構造器 rest framework.response.response def init self,data none,status none,template name none,headers none,exception false,content type none param da...