基于zookeeper的HA集群設計思路--

1. 各個節(jié)點都可以消費任務，但是由主節(jié)點來投票；
2. 主節(jié)點通過注冊zookeeper的臨時節(jié)點來選舉--主節(jié)點需要同步從節(jié)點的信息
3. 正常工作機制--各個節(jié)點（包括主節(jié)點本身）在執(zhí)行任務之前詢問主節(jié)點，主節(jié)點通過布隆過濾器判斷該任務是否被執(zhí)行；
4. 如果該任務被執(zhí)行過，則從節(jié)點將該任務加入存疑隊列中--主節(jié)點不能保證一定被執(zhí)行；任務被消費的幾種可能--
   1. 新增節(jié)點，導致partition重分配--通過舉證即可完成校驗；
   2. 節(jié)點失敗，導致partition重分配--舉證無法校驗；執(zhí)行該任務的節(jié)點下線；需要運行任務檢查策略--消息冪等性校驗；
5. 存疑隊列中的任務間隔時間需要其他節(jié)點舉證--是否有其他節(jié)點準備執(zhí)行或者正在執(zhí)行或者執(zhí)行過但是沒有來得及提交；
6. 其他節(jié)點舉證成功則丟棄該消息；其他節(jié)點舉證失敗則運行檢查策略；
7. 節(jié)點任務執(zhí)行成功則向kafka提交消息；
8. kafka提交失敗說明此時發(fā)生了partition重分配，則節(jié)點向主節(jié)點提交消息，主節(jié)點負責處理該未提交的消息；
9. 主節(jié)點投票邏輯--
   1. 主節(jié)點自己判斷是否通過--可以通過則更新布隆過濾器并通知其他節(jié)點，返回所有節(jié)點的并集；
   2. 如果投票過程中某個節(jié)點下線；主節(jié)點主動和該節(jié)點斷開連接；
10. 節(jié)點下線邏輯---
    1. 網(wǎng)絡延遲--
       1. 保留任務執(zhí)行進度并嘗試重連
       2. 短時間內重連失敗則進入同步模式，等待和主節(jié)點同步數(shù)據(jù)；并不能直接消費；
    2. 節(jié)點宕機--
       1. 節(jié)點下線需要主節(jié)點處理--主節(jié)點斷開和該節(jié)點的鏈接
11. 節(jié)點上線--
    1. 如果沒有主節(jié)點，則該節(jié)點搶占leader，但是observer節(jié)點會被篡位--使用篡位機制還是同步機制--進入選舉狀態(tài)
    2. 如果存在主節(jié)點，向主節(jié)點發(fā)起連接請求，主節(jié)點會同步自己的布隆過濾器數(shù)據(jù)；同步完成即可加入；
12. 選舉--
    1. 集群初始化--節(jié)點啟動狀態(tài)為observer節(jié)點，如果沒有主節(jié)點，則observer搶占成為leader節(jié)點；如果有主節(jié)點，則請求主節(jié)點加入集群；
    2. 某個節(jié)點成為主節(jié)點之后需要和其他節(jié)點完成數(shù)據(jù)同步---這樣防止主節(jié)點在
13. 幾種節(jié)點下線情況--
    1. 從節(jié)點網(wǎng)絡延遲，被動斷開和主節(jié)點的連接--這時重新加入集群需要向主節(jié)點同步信息；
    2. 主節(jié)點下線--引發(fā)選舉節(jié)點---主節(jié)點有可能在消息分發(fā)的過程中下線，這樣會導致數(shù)據(jù)不同步的問題，所以主節(jié)點在重新接入集群的時候需要同步各個集群的數(shù)據(jù)；
    3. 主節(jié)點下線--等待主節(jié)點發(fā)送決議消息的從節(jié)點將直接將該消息加入存異隊列中；
    4. 主節(jié)點負責調度--管理各個節(jié)點已經(jīng)消費的消息和已經(jīng)提交的消息；
14. 消息消費流程-

?消息最多可能存在兩個節(jié)點中--文章來源地址http://www.zghlxwxcb.cn/news/detail-621731.html

1. 新增節(jié)點導致已經(jīng)被其他節(jié)點拉取但是沒被執(zhí)行的任務被新節(jié)點拉取，此時任務會被前一個節(jié)點執(zhí)行但是被新節(jié)點提交；
2. 某個節(jié)點宕機、或者與集群斷開連接導致被該節(jié)點拉取但是沒有提交的任務被其他節(jié)點拉取，此時該任務會被后拉取的節(jié)點執(zhí)行并提交；
3. 所以存異隊列中的消息肯定要被該節(jié)點提交；但是是否該由該節(jié)點執(zhí)行卻取決于舉證結果，如果其他節(jié)點舉證自己正在執(zhí)行該任務，則不執(zhí)行，如果沒有節(jié)點執(zhí)行或者沒有查詢到提交記錄則移交到執(zhí)行隊列中；
4. 閉環(huán)在于--被拉去過的任務如果被再次消費肯定會加入到存疑隊列中，加上舉證和檢查策略就能保證該任務最終狀態(tài)的確定；
5. 在情況1中，該任務被執(zhí)行應該提交給主節(jié)點還是直接提交給監(jiān)聽節(jié)點---因該監(jiān)聽主節(jié)點，保證在執(zhí)行節(jié)點下線的時候該節(jié)點能夠及時收到下線信息并重新承擔該任務的執(zhí)行角色；
6. 節(jié)點下線--宕機下線或者和主節(jié)點斷開連接，此時應該放棄消費kafka中的消息，保證消息不會被重復消費；

到了這里，關于分布式異步任務處理組件（四）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！