分佈式數據庫（Elasticsearch、Redis、MySQL分佈式集羣等）場景選型和應用難點

近年來，隨着國際信息安全形式的日益嚴峻，國家信息安全策略逐步深刻。所以，一行兩會連續針對金融業數據庫技術受制於人的嚴峻形勢出臺了相關政策，以知足構建安全可靠可控的信息技術體系的要求。

縱觀近年來普惠金融的發展，多用戶、低額的客單價帶來的主要挑戰是數據量、交易額的大幅提升，並伴隨着數十倍的交易高峯壓力以及交易複雜度的增長。而傳統數據庫在處理此類應用場景的時，在擴展性、性能、吞吐量和可靠性等方面遇到了明顯的瓶頸，只能經過業務拆分、升級硬件的方式來提高性能，形成設備投入和人員成本的不斷攀升。面對着互聯網金融業態不斷的發展，數據的交互和存儲也呈現指數級增加，這樣的方式也沒法保證業務連續性。在此形式下，在分佈式數據庫的選型上，根據不一樣的業務場景和關鍵系統中選擇不一樣的開源產品，經過對開源數據庫的深刻研究和應用，知足了企業業務場景的事務處理和數據處理的要求。

精彩回覆

一、哪一個分佈式數據庫適合處理返回的數據集很大(幾兆幾十兆)的併發場景？

我有一批實時的時間序列數據，須要按時間來查詢，並作聚合及複雜處理(不止是sum、avg、max這種)。我這邊主要使用的分佈式數據庫是elasticsearch跟redis，可是它們兩個都不是特別適合。Redis是單線程的，返回大數據集會卡住，阻塞其餘查詢請求；elasticsearch的search返回的數據集上限是10000，超過這個就得用scroll了，並且總感受elasticsearch來作這種簡單的檢索，有點浪費了。有什麼好的分佈式數據庫適合作這個嗎?

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
命題中兩個需求，1：海量數據；2：時效性
若是是單純考慮1，基本上絕大部分的分佈式數據庫都適合，無非考慮到海量到什麼程度，可是每一個分佈式數據庫的優勢不同，好比說redis的場景是緩存和訂閱，es的場景更多的是搜索數據分析。如你所說，redis和es都有缺點，redis是單線程的，一個查詢慢了會致使整個查詢超時，es沒有事務的概念，查詢批量的數據集會有限制。
若是是2：其實絕大多數的分佈式數據庫也是適合的，關鍵仍是看你時效到什麼程度，拿hbase來講，寫入性能能達到每秒1W的速度。
關鍵仍是看場景，若是是基於時序的聚合處理，不妨選擇專門的時序數據庫，好比 InfluxDB

二、分佈式數據庫在跨機房數據同步須要考慮哪些因素？

嘉賓1：顧黃亮  技術總監 , 蘇寧消費金融有限公司
第一：考慮數據同步的場景；
第二：你分佈式數據庫的類型；
第三：你的業務架構；
第四：也是最重要的，對數據一致性的容忍性。
跨機房的數據複製方式通常是專線網絡 + DB複製 來保障，終端服務實現跨機房的話 就須要系統相關的全部組件都支持跨機房高可用，而且須要實現自動化切換。補充一點， 跨機房服務部終端，會犧牲必定的數據一致性。這是數據級的，若是是業務級別的，還得有數據入口的路由， 應用與依賴組件多機房高可用部署(MQ、Hbase、對象存儲服務等)，部分組件須要應用雙寫多機房，好比Hbase、對象存儲的寫入，諸如此類的細節也要考慮到。

嘉賓2：508mars  數據庫管理員 , 華泰證券
1）對數據同步延遲的要求，跟業務系統等級相關，高等級業務系統一般採用同步複製，反之採用異步複製
2）對性能的要求，數據同步延遲越低，對主節點性能影響越大
3）跨機房網絡質量，直接影響數據同步延遲

三、金融業務場景，分佈式數據庫一個事物的數據分別在不一樣的數據庫，如何實現事物一致性控制？

金融業務場景，假如分佈式數據庫一個事物的數據分別在不一樣的數據庫，如何實現事物一致性控制？經過數據庫層仍是應用層進行控制？應用層如何實現？若是數據庫層控制的話如何控制？

嘉賓1：顧黃亮  技術總監 , 蘇寧消費金融有限公司
你想問的應該是，多數據源狀況下事務一致性問題，若是不是，請另補充
簡單說一下解決辦法：（1） 配置多個數據源，不一樣的 sessionFactory控制，在dao層根部不一樣的業務場景和需求路由到相應的數據源（2）dao層可進行封裝，將不一樣的sql sessionFactory注入到 sessionFactory，創建session對象，這樣dao就實現基於basedao的集成（3）最關鍵的是一個事務涉及多個數據源，當異常須要回滾（4）接着3繼續說，service添加事務發生異常，A庫進行回滾，B庫沒有回滾怎麼辦，經過分佈式事務，atomikos來處理。

嘉賓2：508mars  數據庫管理員 , 華泰證券
數據庫層控制：通常會由數據庫計算節點經過「兩階段提交+悲觀鎖/樂觀鎖」來實現跨節點事務一致性，其中還涉及到全局事務id等概念。
應用層控制：兩階段提交、本地消息表、TCC補償模式等，網上有不少介紹。

四、分佈式數據庫（elasticsearch、redis、mysql分佈式集羣、mongodb等）

這四種分佈式數據庫的優缺點和應用選擇注意點分別是什麼？

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
es優勢：將你的文檔分割到不一樣容器或者分片中，能夠存在單個節點或多個節點
複製每一個分片提供數據備份，防止硬件問題致使數據丟失。
對集羣中任意節點的相互請求進行路由，保證獲取的數據是你須要的，集羣增長或者從新分配分片時，不停機讓新節點恢復丟失的節點分片數據
redis優勢：1速度快，由於數據存在內存中，相似於 HashMap ， HashMap 的優點就是查找和操做的時間複雜度都是;
2支持豐富數據類型，支持 string ， list ， set ， sorted set ， hash;
3支持事務，操做都是原子性，所謂的原子性就是對數據的更改要麼所有執行，要麼所有不執行;
4豐富的特性：可用於緩存，消息，按 key 設置過時時間，過時後將會自動刪除

mongo優勢：1弱一致性（最終一致），更能保證用戶的訪問速度;
2 文檔結構的存儲方式，可以更便捷的獲取數據;
3內置 GridFS ，支持大容量的存儲4在使用場合下，千萬級別的文檔對象，近 10G 的數據，對有索引的 ID 的查詢不會比 mysql 慢，而對非索引字段的查詢，則是全面勝出 。

es缺點： 沒有用戶驗證和權限控制，沒有事務的概念，不支持回滾，誤刪不能恢復，須要 java 環境 .
redis缺點：1具有自動容錯和恢復功能，主機從機的宕機都會致使前端部分讀寫請求失敗，須要等待機器重啓或者手動切換前端的 IP 才能恢復;
2主機宕機，宕機前有部分數據未能及時同步到從機，切換 IP 後還會引入數據不一致的問題，下降了系統的可用性;
3主從複製採用全量複製，複製過程當中主機會 fork 出一個子進程對內存作一份快照，並將子進程的內存快照保存爲文件發送給從機，這一過程須要確保主機有足夠多的空餘內存。若快照文件較大，對集羣的服務能力會產生較大的影響，並且複製過程是在從機新加入集羣或者從機和主機網絡斷開重連時都會進行，也就是網絡波動都會形成主機和從機間的一次全量的數據複製，這對實際的系統運營形成了不小的麻煩;
4Redis 較難支持在線擴容，在集羣容量達到上限時在線擴容會變得很複雜。爲避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源形成了很大的浪費 。

五、mongodb數據庫v3.0強一致性事務能力怎麼樣，生產環境有坑嗎？

據說mongodb數據庫最新版本增長了事務功能，在銀行業有落地案例嗎？相比傳統數據庫，這類nosql將來的SQL能力可否知足業務需求，穩定性和性能如何？

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
Mongo3.0自身是不提供事務處理的。若是要實現事務操做，必須本身寫實現代碼。在爲你的項目選定數據庫的時候，要根據你的項目來量身選擇。若是須要強事務操做的和數據一致性很高的地方，最好選擇健壯的關係行數據庫。若是對事務處理要求不高，而對數據存取要求很高的，則選擇非關係型數據庫。
貌似4.0提供文檔事務支持。說說坑，其實Mongo最大的坑是鎖，通常遇到的延遲問題，尤爲涉及用戶名密碼訪問的方式，mongo從最開始的全局鎖，到庫鎖，一直到3.0的表鎖，無處不是坑，4.0不知道又到什麼級別的鎖

六、Elasticsearch、redis在數據中臺中如何選型使用，如何讓數據開發的數據快速生成API對外服務？

嘉賓：  顧黃亮  技術總監 , 蘇寧消費金融有限公司
這個問題思考了好久，對於ES或redis來講，針對數據中臺不該該說選型，應該是數據集成的選擇。
暫時不說選型，先說說數據集成的準備工做，在數據集成開發以前，應該準備數據源的分類、環境的梳理、數據內容、數據質量、數據的範圍。而後進行數據集成的業務架構涉及，再進行數據集成、數據同步、數據處理的流程，肯定數據庫的選型，最後纔是API類數據的輸出。
ES和redis的使用徹底參照這兩種軟件的使用場景，數據快速生產API對外服務是數據輸出的一種方式

七、在選擇分佈式數據庫的時候如何解決後續的維護問題？

大多數分佈式數據庫都是開源的，如何來確保本身選擇的數據庫是穩定的呢？一旦出現問題如何解決呢?

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
分佈式數據庫運維中，總體來講有幾個地方的挑戰：1. 是運維的複雜度會提高很多。譬如：異常故障的處理等。 2.備份和恢復會複雜一些。這些的恢復是指產生邏輯錯誤致使的問題恢復。
穩定都是基於保證基礎設施的架構合理性；保證數據庫集羣自身的健壯性；保證應用層架構的合理性

八、mysql分佈式數據如何同步與備份？

目前公司做了mysql集羣，同時也做了主備，但因爲每次備份時採用全量備分，出了問題時恢復麻煩。若是採用增量備份，維護數據一致性又很複雜。 有沒有實踐中將兩者處理得很較好的案例。

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
mysql其實只有一種複製方式，就是基於binlog的複製，可是基於binlog的複製又分三種，一種是基於sql的複製，第二種是基於行的複製，第三個就是混合複製，第一種是使用最多的。我不知道你描述的全量和增量是什麼方式，繼續說下binlog，若是是基於sql的複製，它的binlog文件比較小，並且能夠用於實時的還原，可是有一些更新語句不能使用，複雜一些的語句對系統的開銷比較大。若是基於行的複製，顧名思義，那就是binlog文件會很大，任何狀況都會被複制，更加安全可靠，且速度會快不少。鑑於以上，mysql還提供混合模式，能夠試一試。

九、請問分佈式數據庫如何解決理論上的備節點髒讀問題？

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
髒讀的狀況很常見，通常是在併發事務的時候出現，相似的還有幻讀和不可重複讀。這種場景在金融中很是常見，好比還款和取款。
解釋下髒讀，一個事務讀取另外一個事務的數據，另外一個事務的數據存在更改沒有提交，若是出現被讀取事務出現回滾，那這個被讀取的數據是不合法的，這就是髒讀。基於數據庫來講，並無更好的處理方式，不管讀取仍是寫入都是合法的，通常只能應用經過鎖來控制，鎖用了越多，效率就越低了，這是須要一個平衡

十、請問對於各個已有老的應用，咱們想平滑過分過度布式數據庫，須要作哪些工做？

請問對於各個已有老的應用，集中式數據庫，咱們想平滑過分過度布式數據庫，須要作哪些工做？
是要對應用代碼進行重構，好比代碼的修改，包括sqk語句，仍是數據庫的中間件是我無感知.

嘉賓：顧黃亮  技術總監 , 蘇寧消費金融有限公司
1：充分的測試，評估時間，總結經驗，提高性能在生產中進行數據的大批量遷移時，充分的測試時必須的。一方面能夠根據這些測試積累一些必要的數據做爲生產中使用參考，另一方面能夠基於以前的測試，總結經驗，總結不足之處，加入改進，在生產中每一分鐘的改進都是很重要的。這部分包括你說的代碼的修改，sql的適配
2：完整的備份
3： 遷移前期進行精密的規劃，不管是遷移時間、事先準備、操做過程、過後處理等等
4： 遷移結束後須要驗證新庫，好比序列，重編譯新庫失效的對象，檢查新庫是否須要重建索引，用事先準備好的腳本驗證新老庫之間的數據是否有差別
這種大級別的遷移，是很難作到無感知的.

---

原做者：顧黃亮
原文連接： 分佈式數據庫（elasticsearch、redis、mysql分佈式集羣、mongodb等）場景選型探討 - 顧黃亮 - twt企業IT交流平臺
原出處：twt企業IT交流平臺