如何解決分布式系統(tǒng)數(shù)據(jù)事務(wù)一致性問題（HBase加Solr）-創(chuàng)新互聯(lián)

如何解決分布式系統(tǒng)數(shù)據(jù)事務(wù)一致性問題

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名申請、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、邵陽網(wǎng)站維護、網(wǎng)站推廣。

（HBase加Solr）

摘要：對于所有的分布式系統(tǒng)，我想事務(wù)一致性問題是極其非常重要的問題，因為它直接影響到系統(tǒng)的可用性。本文以下所述所要解決的問題是：對于入HBase和Solr的過程，如何保證HBase中寫入的數(shù)據(jù)與Solr中寫入的數(shù)據(jù)完全一致。

關(guān)鍵詞：HBase, Solr, 分布式, 事務(wù), 系統(tǒng)架構(gòu), 大數(shù)據(jù)

作者：王安琪（博客：http://www.cnblogs.com/wgp13x/）

---

一、關(guān)于分布式系統(tǒng)事務(wù)一致性問題

Java 中有三種可以的事務(wù)模型，分別稱作本地事務(wù)模型（Local Transaction Model），編程式事務(wù)模型（Programmatic Transaction Model），和聲明式事務(wù)模型（Declarative Transaction Model)。事務(wù)要求包含原子性（Atomicity），一致性（Consistency），獨立性（Isolation），和持久性（Durability）。

《大型網(wǎng)站系統(tǒng)與Java中間件實踐》一書中分享了一些解決分步式系統(tǒng)一致性問題的方案構(gòu)思與實踐，如在第六章中談到的消息中間件。下表展現(xiàn)了解決一致性方案與傳統(tǒng)方式的對比。

傳統(tǒng)方式是，我做完了，發(fā)你消息。解決一致性的方案的意思就是，我先發(fā)你消息，我做完了再跟你確認我做完了。這是改進后的有事務(wù)的消息中間件。

因為在非XA 環(huán)境中，消息隊列的插入過程獨立于數(shù)據(jù)庫更新操作，ACID 準(zhǔn)則中的原子性和獨立性不能得到保證，從而整體上數(shù)據(jù)完整性受到損害。使用X/Open 的XA 接口，我們便能夠做到協(xié)調(diào)多個資源，保證維持ACID 準(zhǔn)則。

在《淘寶技術(shù)這十年》這本書里也提到這么一段描寫“用戶在銀行的網(wǎng)關(guān)付錢后，銀行需要通知到支付寶，但銀行的系統(tǒng)不一定能發(fā)出通知；如果通知發(fā)出了，不一定能通知到；如果通知到了，不一定不重復(fù)通知一遍。這個狀況在支付寶持續(xù)了很長時間，非常痛苦。支付寶從淘寶剝離出來的時候，淘寶和支付寶之間的通信也面臨同樣的問題，那是2005年的事情，支付寶的架構(gòu)師魯肅提出用MQ（Message Queue）的方式來解決這個問題，我負責(zé)淘寶這邊讀取消息的模塊。但我們發(fā)現(xiàn)消息數(shù)量上來之后，常常造成擁堵，消息的順序也會出錯，在系統(tǒng)掛掉的時候，消息也會丟掉，這樣非常不保險。然后魯肅提出做一個系統(tǒng)框架上的解決方案，把要發(fā)出的通知存放到數(shù)據(jù)庫中，如果實時發(fā)送失敗，再用一個時間程序來周期性地發(fā)送這些通知，系統(tǒng)記錄下消息的中間狀態(tài)和時間戳，這樣保證消息一定能發(fā)出，也一定能通知到，且通知帶有時間順序，這些通知甚至可以實現(xiàn)事務(wù)性的操作?！?/p>

一致性更是可以分為強一致性和弱一致性兩種，弱一致性可以允許某一時間間隔內(nèi)的偶爾不一致，強一致性的要求要高很多。在實際中，弱一致性往往就能達到業(yè)務(wù)要求，甚至某些銀行系統(tǒng)都只要求弱一致性即可，允許不一致性的窗口存在，只要不造成損失即可。

對于每一種分布式系統(tǒng)，其組織方式各不相同，實現(xiàn)形式也各有千秋，業(yè)務(wù)要求更是千變?nèi)f化，因此要因地制宜的實施一致性方案。表6-5提出的解決辦法是要求處理方在完成業(yè)務(wù)操作后主動發(fā)送給消息中間件這一結(jié)果，而后消息中間件確認后再做處理，這樣是可以保證事務(wù)性。但對于表6-5提出的解決辦法，在入HBase和Solr的流程中并不能適用。因為為了保證數(shù)據(jù)寫入Solr的性能，入Solr使用的是Concurrent....方式，然而此種方式并不會返回是否入Solr成功，因此這種異步特性不是表6-5中方案所能解決的。

二、針對HBase和Solr分布式系統(tǒng)事務(wù)一致性解決方案

在此，我們對于HBase加Solr這種分布式系統(tǒng)，經(jīng)過種種構(gòu)思-推翻-再構(gòu)思-再推翻，終于成功，特設(shè)計了如下事務(wù)一致性解決方案。

1、寫入數(shù)據(jù)到HBase和Solr

圖1 HBase加Solr分布式系統(tǒng)事務(wù)一致性解決方案(寫入數(shù)據(jù))

從圖1時序圖中可以看出，其思想與表6-5方案還是一致的，但實現(xiàn)手法則完全不同。它的本質(zhì)即是：需要確認數(shù)據(jù)處理成功后，方可證實數(shù)據(jù)同步。關(guān)鍵在于，如何確認數(shù)據(jù)處理成功，靠HBase返回？靠Solr返回？不行。那只有做個緩存，先把沒確認的存著，等后期有時間了挨個確認。這里的MySQL就起到了方案所述的緩存的作用。我們先把數(shù)據(jù)寫入到MySQL緩存起來，寫入時數(shù)據(jù)狀態(tài)為0，說明還沒有提交HBase和Solr，每間隔3秒我們使用“入庫線程”取狀態(tài)為0的數(shù)據(jù)，提交到HBase和Solr中，并將數(shù)據(jù)狀態(tài)更新為2，以此說明此數(shù)據(jù)已經(jīng)入了庫。如果沒有“核查線程”做數(shù)據(jù)一致性檢查，則數(shù)據(jù)一致性無法保證。有可能存在這樣一種情況：HBase里數(shù)據(jù)寫入成功了，Solr里出于某種原因沒有寫入成功（Solr異常了或網(wǎng)絡(luò)不通了等等）。如果此不一致性很久沒有被發(fā)現(xiàn)，那么就會在HBase中出現(xiàn)一些根本無法取得的飄浮數(shù)據(jù)。我們的“核查線程”可以保證HBase中和Solr里的數(shù)據(jù)是一致的。

2、從HBase和Solr中刪除數(shù)據(jù)

現(xiàn)在我們已經(jīng)做到了寫入數(shù)據(jù)操作的事務(wù)一致性，同理的還有，刪除數(shù)據(jù)操作的事務(wù)一致性，更新數(shù)據(jù)操作的事務(wù)一致性，都可以以這種思想實現(xiàn)。

 

圖2 HBase加Solr分布式系統(tǒng)事務(wù)一致性解決方案(刪除數(shù)據(jù))

從圖2中可以看出，刪除數(shù)據(jù)先從Solr中刪除，再從HBase中刪除，同樣的，如果發(fā)生某種不可預(yù)見的異常，HBase中也會出現(xiàn)一些根本無法取得的飄浮數(shù)據(jù)，這種情況很少見，然而一旦發(fā)生，我們的“核查線程”可以保證HBase中和Solr里的數(shù)據(jù)是一致的。

3、更新數(shù)據(jù)到HBase和Solr

圖3 HBase加Solr分布式系統(tǒng)事務(wù)一致性解決方案(更新數(shù)據(jù))

更新數(shù)據(jù)的一致性解決方案要稍微復(fù)雜一些，因為對HBase和Solr中數(shù)據(jù)核查某一數(shù)據(jù)是否已經(jīng)正確更新是很難做到的。你可以將HBase中的數(shù)據(jù)一個個地取出來與更新數(shù)據(jù)進行比較，查看是否已經(jīng)正確更新；但你沒有辦法將更新數(shù)據(jù)所有的字段去Solr中查，是否更新到Solr。因此我們設(shè)計的方案是：先對要更新的RowKey-數(shù)據(jù)生成一個新的newRowKey，再將HBase和Solr中的原始數(shù)據(jù)進行刪除，然后將更新后的數(shù)據(jù)添加入HBase和Solr中，這樣就是完成了一次更新數(shù)據(jù)的操作，將更新分成了刪除與添加兩步進行操作，核查此數(shù)據(jù)是否已經(jīng)正確更新也因此有跡可尋，此時只需要搜索HBase和Solr中有newRowKey即可證明數(shù)據(jù)已經(jīng)更新成功。

三、總結(jié)

在這里，我們引用一下《支付寶數(shù)據(jù)平臺》中的海狗系統(tǒng)的架構(gòu)設(shè)計。海狗系統(tǒng)（ARSC）——準(zhǔn)實時搜索查詢，它提供千億級別數(shù)據(jù)實時查詢和全文檢索、支持每天10億+級別的數(shù)據(jù)更新。它的實時性可以保證實時搜索延遲3s、查詢和插入TPS > 1.5WTPS。數(shù)據(jù)容量線性擴展，Schema擴展基于HBase列式無限擴張，基于ZK動態(tài)感知節(jié)點狀態(tài)自動容災(zāi)。下圖即簡單表明了其流程。

粗看不起眼，琢磨一下便知其是考慮到了HBase和Solr的數(shù)據(jù)一致性的。在HBase中的MQ表就是起到上面我們的設(shè)計方案中的MySQL的作用。在d步驟中，才批量刪除處理過的數(shù)據(jù)，MQ表是留憑證用的。HBase在高性能處理方面還是要遠遠優(yōu)于MySQL，如果可以，我們設(shè)計方案中的MySQL也可以用HBase取代。

做個總結(jié)：無論是我們設(shè)計方案，還是其他類似的分布式系統(tǒng)事務(wù)性解決方案，其的本質(zhì)思想是一樣的，即是：做個緩存，先把沒確認的存著，等后期有時間了挨個確認。

“既然計算是異步的，那么反饋也應(yīng)該是異步的，你完全可以讓SendMail將發(fā)送結(jié)果寫入數(shù)據(jù)庫，并生成報表，然后讓應(yīng)用程序定期對報告中發(fā)送失敗的郵件執(zhí)行再次發(fā)送。這里需要假設(shè)失敗的情況并不是很多?！痹凇稑?gòu)建高性能web站點》第17章分布式計算-異布計算中對此類問題的解決方法，也是構(gòu)成我們解決HBase和Solr分布式系統(tǒng)事務(wù)一致性問題的重要指導(dǎo)，感謝作者郭欣。當(dāng)然也感謝《大型網(wǎng)站系統(tǒng)與Java中間件實踐》的作者曾憲杰、《構(gòu)建高性能web站點》的作者郭欣。更感謝分享海狗系統(tǒng)設(shè)計的蔣杰（花名：平原君），以及眾多樂于分享技術(shù)的人們。

看這些書，覺得系統(tǒng)架構(gòu)方面的技術(shù)真的是非常龐大，佩服阿里的那群將數(shù)據(jù)從小做到大的問題解決者。千里之行，始于足下。

來自王安琪

作者：Angel 出處：http://www.cnblogs.com/wgp13x/ 歡迎轉(zhuǎn)載或分享，但請務(wù)必聲明文章出處。如果文章對您有幫助，希望你能推薦或關(guān)注。

王安琪，英文名Angel，南京郵電大學(xué)計算機應(yīng)用技術(shù)碩士學(xué)位。 熟悉Java、C#編程語言。專注于WebService、海量數(shù)據(jù)處理、搜索引擎技術(shù)、消息中間件技術(shù)、分布式文件存儲、.NET應(yīng)用程序開發(fā)、系統(tǒng)架構(gòu)設(shè)計。主要從事大數(shù)據(jù)管理系統(tǒng)的研發(fā)，項目經(jīng)理，系統(tǒng)架構(gòu)師，就職于江蘇金陵科技集團有限公司。

Email：aitanjupt@hotmail.com

QQ：289770363

當(dāng)前標(biāo)題：如何解決分布式系統(tǒng)數(shù)據(jù)事務(wù)一致性問題（HBase加Solr）-創(chuàng)新互聯(lián)
網(wǎng)站網(wǎng)址：http://muchs.cn/article48/csgehp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、網(wǎng)站設(shè)計公司、外貿(mào)網(wǎng)站建設(shè)、電子商務(wù)、網(wǎng)站設(shè)計、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)