中間件系統的架構設計

中間件系統的架構設計

1. Master-Slave架構

 　　該系統的本質是但願可以用分佈式的方式來處理一些數據，核心思想，就是把數據分發到不少臺機器上來處理，而後須要有一臺機器來控制N多臺機器的分佈式處理：

 　　分佈式的處理，就會確定涉及到在Master中要維護這個集羣的一些核心元數據。數據的分發處理的調度，處理的具體過程的進度，對集羣裏存放數據進行描述的一些核心元數據。

　　　這些核心元數據會不斷的頻繁的修改，不管你是基於外部的文件仍是數據庫，或者是zookeeper來存放這些元數據的話，其實都會致使他的元數據更新性能下降，由於要訪問外部依賴。這種複雜的元數據不必定能經過數據庫來存放，它的非格式化有可能的。

　　　　核心的設計是：將核心元數據直接存放在Master的內存裏，這樣能夠保證高併發更新元數據的時候，性能極高，可直接基於內存來提供對外的更新服務。若是Master部署在高配置物理機上，好比32核128GB的那種，每秒支持10萬+的請求都沒問題。

 

　　2.異步日誌持久化機制

　　　　Master進程重啓或者忽然宕機，內存中的數據不就丟失了?針對這個問題，採起異步持久化日誌的機制，來經過異步化的方式把元數據的更新日誌寫入磁盤文件。每次Master收到一個請求，在內存裏更新元數據以後，就須要生成一條元數據的更新日誌，把這個更新日誌須要寫入到一個內存緩衝裏去。而後等內存緩衝滿了以後，由一個後臺線程把這裏的數據刷新到磁盤上去。

　　　　那若是一條更新日誌剛寫入緩衝區，結果Master宕機了，此時不是仍是會丟失少許數據嗎？由於還沒來得及進入磁盤。

　　　　沒錯，需採用異步持久化磁盤的模式，要容忍極端宕機狀況下，丟失幾秒鐘的數據的狀況。

　　　　若是是正常的Master重啓：必須先把日誌緩衝區清空刷入磁盤，而後才能正常重啓Master，保證數據都在磁盤上不會丟失。重啓的時候，從磁盤上讀取更新日誌，每一條都依次回訪到內存裏，恢復出來核心元數據便可。

 

　　　3.檢查點機制：定時持久化全量數據

 

　　　　元數據不斷的在更新，不斷在產生最新的變動日誌寫入磁盤文件，因此磁盤上的日誌文件愈來愈大，系統運行一段時間之後，每次重啓都須要從磁盤讀取歷史所有日誌，一條一條回放到內存來恢復核心元數據嗎？不，須要引入檢查點機制。

　　　　每隔一段時間，就須要開啓一個後臺線程，把內存裏的所有核心元數據序列化後寫入磁盤上的元數據文件，做爲這個時間的一個快照文件，同時清空掉日誌文件，這個叫作檢查點操做。下次重啓，只要把元數據文件讀取出來直接反序列化後方入內存，而後把上次檢查點以後的變動日誌從日誌文件裏讀出來回放到內存裏，就能夠恢復出來完整的元數據了。

　　這種方式，可讓Master重啓很快，由於大部分數據都是在檢查點寫入的那個元數據文件裏。

 　　　4.引入檢查點節點

　　　　Master內存裏的元數據須要高併發的被人訪問和修改，同時每隔一段時間還要檢查點寫入磁盤。因此在檢查點過程當中，是否須要須要把內存數據所有加鎖，不容許別人修改？

　　　　在加鎖的時候，把不會變更的數據寫入磁盤文件中，這個過程很慢，這樣會致使系統在幾秒內出現卡頓沒法響應請求的問題。此時須要在架構設計裏引入一個檢查點節點，專門負責同步Master的變動日誌。而後在本身內存裏維護一份如出一轍的核心元數據，每隔一段時間由檢查點節點來負責將內存數據寫入磁盤，接着上傳發送給Master。這樣就不須要Master本身執行檢查點的時候對本身內存數據進行加鎖了。對Master來講，它只須要一個後臺線程負責接收檢查點進程定時傳送過來的元數據文件快照而後寫入本地磁盤就能夠了。