計算密集型分布式內存存儲和運算平台架構

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

牢騷：本來想弄個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.盡量避免創建大對象，必要時通過弱引用+延遲加載處理大對象。