1. 相關(guān)概念

1.1 內(nèi)存數(shù)據(jù)庫(kù)

關(guān)系型數(shù)據(jù)庫(kù)處理永久、穩(wěn)定的數(shù)據(jù)，內(nèi)存數(shù)據(jù)庫(kù)就是將其數(shù)據(jù)放在內(nèi)存中，活動(dòng)事務(wù)只與內(nèi)存數(shù)據(jù)打交道，重新設(shè)計(jì)了體系結(jié)構(gòu)并且在數(shù)據(jù)緩存、快速算法、并行操作方面也進(jìn)行了相應(yīng)的改進(jìn)，所以數(shù)據(jù)處理速度比磁盤數(shù)據(jù)庫(kù)要快很多，一般都在10倍以上。但它不容易恢復(fù)，可能暫時(shí)不一致或非絕對(duì)正確的，要求較大的內(nèi)存量，而64位操作系統(tǒng)可以支持更大的地址（2T），為內(nèi)存數(shù)據(jù)庫(kù)的實(shí)現(xiàn)提供了可能。

1.2 計(jì)算密集型

計(jì)算密集型是指，每個(gè)請(qǐng)求的命令中，大都包含不同的參數(shù)值，很難重用前一次計(jì)算的結(jié)果，所以要按照約定的業(yè)務(wù)邏輯重新計(jì)算，并按照約定的格式返回?cái)?shù)據(jù)，且計(jì)算在總耗時(shí)中占比較大。

2. 數(shù)據(jù)存儲(chǔ)

2.1 DB

數(shù)據(jù)存儲(chǔ)在DB中，直接訪問(wèn)數(shù)據(jù)庫(kù)。但數(shù)據(jù)庫(kù)壓力太大，系統(tǒng)瓶頸明顯。

?

2.2 DB + All In One Cache

將DB中的數(shù)據(jù)加載到節(jié)點(diǎn)的內(nèi)存中，并定時(shí)從數(shù)據(jù)更新日志庫(kù)中讀取來(lái)更新內(nèi)存的數(shù)據(jù)，極大減輕數(shù)據(jù)庫(kù)的壓力。

但隨著數(shù)據(jù)的膨脹，節(jié)點(diǎn)啟動(dòng)加載慢，升級(jí)時(shí)間長(zhǎng)，宕機(jī)恢復(fù)難等。

2.3 DB + File + All In One Cache

每天晚上從DB讀取數(shù)據(jù)，生成帶有數(shù)據(jù)同步標(biāo)識(shí)的數(shù)據(jù)文件，分發(fā)到各個(gè)服務(wù)器節(jié)點(diǎn)。節(jié)點(diǎn)啟動(dòng)時(shí)，直接從本地?cái)?shù)據(jù)文件加載，大大提高了啟動(dòng)速度。

但隨著DB中數(shù)據(jù)的更新，實(shí)例間數(shù)據(jù)不一致性嚴(yán)重。

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

通過(guò)DP服務(wù)定時(shí)監(jiān)控?cái)?shù)據(jù)更新日志庫(kù)中的記錄，通過(guò)AMQ發(fā)布給訂閱的每個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)根據(jù)當(dāng)前同步的標(biāo)識(shí)決定是否處理消息記錄，根據(jù)消息記錄的屬性執(zhí)行具體的增刪改操作，使得數(shù)據(jù)的一致性較好。

但單個(gè)節(jié)點(diǎn)內(nèi)存過(guò)大，大數(shù)據(jù)量時(shí)仍會(huì)變慢，卡頓現(xiàn)象頻繁且耗時(shí)較長(zhǎng)。

2.5 DB + File + Distributed?Cache + AMQ Sync

按照業(yè)務(wù)將數(shù)據(jù)拆分到不同的節(jié)點(diǎn)上，通過(guò)管理節(jié)點(diǎn)分配任務(wù)，使得內(nèi)存大小可控，卡頓頻率和耗時(shí)明顯減少。

但生產(chǎn)bug、業(yè)務(wù)邏輯變更或新增需求時(shí)，只能重啟服務(wù)，不夠靈敏，可維護(hù)性差。

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

利用CodeDom實(shí)現(xiàn)動(dòng)態(tài)編譯，在運(yùn)行時(shí)增加或修改業(yè)務(wù)邏輯。

另外，可以為每個(gè)節(jié)點(diǎn)對(duì)應(yīng)一個(gè)獨(dú)立的DataProcess。

3. 數(shù)據(jù)運(yùn)算

3.1 存儲(chǔ)過(guò)程

將業(yè)務(wù)邏輯寫到存儲(chǔ)過(guò)程中，難以維護(hù)，請(qǐng)求排隊(duì)現(xiàn)象嚴(yán)重。

3.2 內(nèi)存運(yùn)算

通過(guò)緩存節(jié)點(diǎn)的中間層對(duì)外提供服務(wù)，在緩存數(shù)據(jù)的基礎(chǔ)上，提供：獲取單個(gè)運(yùn)算結(jié)果的API（對(duì)外），獲取數(shù)據(jù)集合的Enumerator（對(duì)內(nèi)），獲取數(shù)據(jù)運(yùn)算結(jié)果集合的Report（對(duì)外），內(nèi)存讀取速度較快。

但很難有效的負(fù)載均衡，無(wú)法高效并行。

3.3 負(fù)載均衡+并行

通過(guò)Master節(jié)點(diǎn)，將請(qǐng)求分給對(duì)應(yīng)的若干工作節(jié)點(diǎn)并行處理，再對(duì)結(jié)果進(jìn)行合并和歸納，返回給客戶端，實(shí)現(xiàn)高效并行處理。

延伸：數(shù)據(jù)運(yùn)算的耗時(shí)，大都在查找、比較、排序、序列化、壓縮、加密處理等，根據(jù)性能分析逐個(gè)調(diào)優(yōu)。

4. 系統(tǒng)調(diào)優(yōu)

4.1 GC

當(dāng)內(nèi)存越大時(shí)，二代回收耗費(fèi)幾秒甚至十幾秒，會(huì)掛起所有線程而使節(jié)點(diǎn)在這段時(shí)間內(nèi)不能正常工作。

1.可設(shè)置多核并發(fā)的Server GC模式，為每個(gè)核創(chuàng)建單獨(dú)的大小堆和GC線程，減少回收的粒度和影響。

2.監(jiān)控將要發(fā)生回收的工作節(jié)點(diǎn)，通知Mater并暫停該工作節(jié)點(diǎn)提供服務(wù)，直至GC完成。

4.2 Cache

1.運(yùn)行時(shí)內(nèi)存的增加，主要是因?yàn)閯?chuàng)建了很多臨時(shí)對(duì)象。所以，要盡量少用Linq，盡量避免創(chuàng)建不必要的對(duì)象。
2.頻繁使用的字符串可嘗試采用駐留機(jī)制。
3.將不常用的歷史數(shù)據(jù)以文件方式存儲(chǔ)和更新而不放入內(nèi)存。
4.業(yè)務(wù)拆分減少每個(gè)節(jié)點(diǎn)要加載的數(shù)據(jù)。
5.盡量避免創(chuàng)建大對(duì)象，必要時(shí)通過(guò)弱引用+延遲加載處理大對(duì)象。

原文地址：http://www.cnblogs.com/LoveOfPrince/p/6336472.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

總結(jié)

以上是生活随笔為你收集整理的计算密集型分布式内存存储和运算平台架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。