這個中介軟體系統的本質是希望能夠用分布式的方式來處理一些資料，但是具體的作用涉及到核心技術，所以這裡不能直接說明。
但是他的核心思想，就是把資料分發到很多臺機器上來處理，然後需要有一台機器來控制n多台機器的分布式處理
那麼既然是分布式的處理，就肯定涉及到在master中要維護這個集群的一些核心元資料。
比如說資料的分發處理是如何排程的，處理的具體過程現在什麼進度了，還有就是對集群裡存放資料進行描述的一些核心元資料。
這些核心元資料肯定會不斷的頻繁的修改，大家此時可以想，無論你是基於外部的檔案還是資料庫，或者是zookeeper來存放這些元資料的話，其實都會導致他的元資料更新效能降低，因為要訪問外部依賴。
何況這種複雜的元資料其實還不一定能通過zk或者資料庫來存放，因為他可能是非格式化的。
所以這裡乙個核心的設計，就是將核心元資料直接存放在master的記憶體裡，這樣可以保證高併發更新元資料的時候，他的效能是極高的，而且直接基於記憶體來提供對外的更新服務。
如果master部署在高配置物理機上，比如32核128gb的那種，每秒支援10萬+的請求都沒問題。
但是這裡有乙個問題，假如說master程序重啟，或者是突然宕機了，那麼記憶體裡的資料不就丟失了麼？
對，所以針對這個問題，既然已經否決掉了基於外部儲存來寫入元資料，那麼這裡就可以採取非同步持久化日誌的機制，來通過非同步化的方式把元資料的更新日誌寫入磁碟檔案。
每次master收到乙個請求，在記憶體裡更新元資料之後，就需要生成一條元資料的更新日誌，把這個更新日誌需要寫入到乙個記憶體緩衝裡去。
然後等記憶體緩衝滿了之後，由乙個後台執行緒把這裡的資料重新整理到磁碟上去，
肯定會有人說，那如果一條更新日誌剛寫入緩衝區，結果master宕機了，此時不是還是會丟失少量資料嗎？因為還沒來得及刷入磁碟。
沒錯啊，這個為了保證高併發請求都是由記憶體來處理的，你必須得用非同步持久化磁碟的模式，所以必然要容忍極端宕機情況下，可能丟失比如幾秒鐘的資料。
那麼如果是正常的master重啟呢？
那簡單，必須先把日誌緩衝區清空刷入磁碟，然後才能正常重啟master，保證資料都在磁碟上不會丟失。
接著重啟的時候，從磁碟上讀取更新日誌，每一條都依次回訪到記憶體裡，恢復出來核心元資料即可。
但是這裡又有乙個問題了，那個磁碟上的日誌檔案越來越大，因為元資料不斷的在更新，不斷在產生最新的變更日誌寫入磁碟檔案。
那麼系統執行一段時間以後，每次重啟都需要從磁碟讀取歷史全部日誌，一條一條回放到記憶體來恢復核心元資料嗎？
不可能，所以這裡一定要配合引入檢查點機制。
也就是說，每隔一段時間，就需要開啟乙個後台執行緒，把記憶體裡的全部核心元資料序列化後寫入磁碟上的元資料檔案，作為這個時間的乙個快照檔案，同時清空掉日誌檔案，這個叫做檢查點操作。
下次重啟，只要把元資料檔案讀取出來直接反序列化後方入記憶體，然後把上次檢查點之後的變更日誌從日誌檔案裡讀出來回放到記憶體裡，就可以恢復出來完整的元資料了。
這種方式，可以讓master重啟很快，因為大部分資料都是在檢查點寫入的那個元資料檔案裡。
但是這個時候又有乙個問題了。
大家可以想一下，master記憶體裡的元資料需要高併發的被人訪問和修改，同時每隔一段時間還要檢查點寫入磁碟。
那麼在檢查點過程中，是不是需要把記憶體資料全部加鎖，不允許別人修改？
在加鎖的時候，把不會變動的資料寫入磁碟檔案中，但是這個過程是很慢的，意味著此時別人高併發的寫入操作都需要等待核心元資料的鎖。
因為此時別人鎖住了，你無法加鎖去寫資料進去，這會導致系統在幾秒內出現卡頓無法響應請求的問題。
所以此時需要在架構設計裡引入乙個檢查點節點，專門負責同步master的變更日誌。
然後在自己記憶體裡維護乙份一模一樣的核心元資料，每隔一段時間由檢查點節點來負責將記憶體資料寫入磁碟，接著上傳傳送給master。
這樣做，就不需要master自己執行檢查點的時候對自己記憶體資料進行加鎖了，
總結一下這個架構設計，其實就是master基於記憶體維護元資料，這樣一台物理機可以支撐每秒10萬+的高併發請求。
每次元資料出現更新，寫一條日誌到記憶體緩衝區，然後後台執行緒去重新整理日誌到日誌檔案裡去，同時需要傳送一條日誌到checkpoint節點去。
checkpoint節點會在自己記憶體裡維護乙份一模一樣的元資料，然後每隔一段時間執行checkpoint檢查點寫乙份元資料檔案快照。
接著上傳給master節點後清空掉他的日誌檔案。然後master節點每次重啟的時候直接讀取本地元資料檔案快照，加上回放上次checkpoint之後的日誌即可。
這裡可能大家會提幾個問題，比如說master節點突然死機會如何？
那很簡單，直接影響就是他記憶體緩衝裡的那些日誌丟了，導致少量資料丟失，這個在我們的場景下可以容忍。
如果checkpoint節點宕機怎麼辦？
那不要緊，因為他之前上傳過元資料檔案的快照，所以對master而言最多就是無法同步資料過去。
但是master重啟，還是可以讀取最近一次的元資料快照，然後回放日誌即可。
等checkpoint節點恢復了，可以繼續接著上一次同步日誌，然後繼續執行checkpoint操作。
架構之道之軟體架構設計的思想
一 架構師決定著軟體質量 在軟體組織中，架構師的作用舉足輕重。軟體的質量很大程度上是由架構設計的質量來決定的。為了建立高質量的軟體產品 增強產品的競爭力，培養高水平的架構師隊伍，建立有效的架構團隊，提公升架構師隊伍的分析與設計能力，成為企業關注的重心。二 體系結構設計決定著架構的成敗 多年來的實踐告...
滴滴出行分而治之的架構設計之道
網際網路生下來就是為了服務海量使用者，在這個時代，幾乎沒有哪個應用再為單機而生。每個公司的每個產品將要面臨的都是不可預知的使用者海量請求。顯然這個靠分布式程式來解決，比靠單機靠譜得多。然而不幸的是，如果一開始你的架構設計不可擴充套件，有再多的機器，有再多的雲解決方案，對你來說至多是將單機程式跑在了乙...
架構師之道 面向元件的Web架構設計
一直以來，不斷有工程師詢問我有關架構設計上的問題，很希望能聽聽我的意見。也有工程師原封不動的在自己的專案中引用我的架構設計。最近，部門內的學習小組又在向我約稿 大師，可否分享一些架構設計經驗。說到架構設計，這是架構師最本職的工作。好架構是第一生產力，不良的架構會埋下種種 伏筆 進而讓使用者怨聲載道。...