計算密集型分佈式內存存儲和運算平臺架構

避嫌聲明：全部圖文都是根據本身的理解原創，且已離開這家公司三年以上，不存在保密協議，寫此文只是用來分享知識、探究不足。

牢騷：原本想弄個ppt交互展現的，不過個人js權限還沒批。。。

 

1. 相關概念

1.1 內存數據庫

關係型數據庫處理永久、穩定的數據，內存數據庫就是將其數據放在內存中，活動事務只與內存數據打交道，從新設計了體系結構而且在數據緩存、快速算法、並行操做方面也進行了相應的改進，因此數據處理速度比磁盤數據庫要快不少，通常都在10倍以上。但它不容易恢復，可能暫時不一致或非絕對正確的，要求較大的內存量，而64位操做系統能夠支持更大的地址（2T），爲內存數據庫的實現提供了可能。

1.2 計算密集型

計算密集型是指，每一個請求的命令中，大都包含不一樣的參數值，很難重用前一次計算的結果，因此要按照約定的業務邏輯從新計算，並按照約定的格式返回數據，且計算在總耗時中佔比較大。

2. 數據存儲

2.1 DB

數據存儲在DB中，直接訪問數據庫。但數據庫壓力太大，系統瓶頸明顯。

 

2.2 DB + All In One Cache

將DB中的數據加載到節點的內存中，並定時從數據更新日誌庫中讀取來更新內存的數據，極大減輕數據庫的壓力。

但隨着數據的膨脹，節點啓動加載慢，升級時間長，宕機恢復難等。

2.3 DB + File + All In One Cache

天天晚上從DB讀取數據，生成帶有數據同步標識的數據文件，分發到各個服務器節點。節點啓動時，直接從本地數據文件加載，大大提升了啓動速度。

但隨着DB中數據的更新，實例間數據不一致性嚴重。

2.4 DB + File + All In One Cache + AMQ Sync

經過DP服務定時監控數據更新日誌庫中的記錄，經過AMQ發佈給訂閱的每一個節點，節點根據當前同步的標識決定是否處理消息記錄，根據消息記錄的屬性執行具體的增刪改操做，使得數據的一致性較好。

但單個節點內存過大，大數據量時仍會變慢，卡頓現象頻繁且耗時較長。

2.5 DB + File + Distributed Cache + AMQ Sync

按照業務將數據拆分到不一樣的節點上，經過管理節點分配任務，使得內存大小可控，卡頓頻率和耗時明顯減小。

但生產bug、業務邏輯變動或新增需求時，只能重啓服務，不夠靈敏，可維護性差。

 2.6 DB + File + Distributed Cache + AMQ Sync +CodeDom

利用CodeDom實現動態編譯，在運行時增長或修改業務邏輯。

另外，能夠爲每一個節點對應一個獨立的DataProcess。

3. 數據運算

3.1 存儲過程

將業務邏輯寫到存儲過程當中，難以維護，請求排隊現象嚴重。

3.2 內存運算

經過緩存節點的中間層對外提供服務，在緩存數據的基礎上，提供：獲取單個運算結果的API（對外），獲取數據集合的Enumerator（對內），獲取數據運算結果集合的Report（對外），內存讀取速度較快。

但很難有效的負載均衡，沒法高效並行。

3.3 負載均衡+並行

經過Master節點，將請求分給對應的若干工做節點並行處理，再對結果進行合併和概括，返回給客戶端，實現高效並行處理。

延伸：數據運算的耗時，大都在查找、比較、排序、序列化、壓縮、加密處理等，根據性能分析逐個調優。

4. 系統調優

4.1 GC

當內存越大時，二代回收耗費幾秒甚至十幾秒，會掛起全部線程而使節點在這段時間內不能正常工做。

1.可設置多核併發的Server GC模式，爲每一個核建立單獨的大小堆和GC線程，減小回收的粒度和影響。

2.監控將要發生回收的工做節點，通知Mater並暫停該工做節點提供服務，直至GC完成。

4.2 Cache

1.運行時內存的增長，主要是由於建立了不少臨時對象。因此，要儘可能少用Linq，儘可能避免建立沒必要要的對象。2.頻繁使用的字符串可嘗試採用駐留機制。3.將不經常使用的歷史數據以文件方式存儲和更新而不放入內存。4.業務拆分減小每一個節點要加載的數據。5.儘可能避免建立大對象，必要時經過弱引用+延遲加載處理大對象。