如何理解數(shù)據(jù)庫集群讀寫分離

本篇內(nèi)容介紹了“如何理解數(shù)據(jù)庫集群讀寫分離”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

“靈魂拷問：

• 解決數(shù)據(jù)庫讀寫瓶頸有哪些解決方案呢?

• 這些方案解決了什么問題呢?

• 這些方案有那些優(yōu)勢和劣勢呢?

一個可以抵抗高并發(fā)流量系統(tǒng)的背后必定有一個高性能的數(shù)據(jù)庫集群，就像每一個成功的男人背后總有一個強勢的女人一樣。數(shù)據(jù)庫集群在部署模式上屬于分布式，但是CAP原則卻不適用于分布式數(shù)據(jù)庫。

分庫分表作為一種普遍的解決方案，幾乎已經(jīng)成為面試者吹水的利劍，卻很少有人在意它所帶來的副作用。其實分庫分表是利用了分治的思路來解決數(shù)據(jù)庫的瓶頸問題，這種方案同時解決了并發(fā)讀和并發(fā)寫的瓶頸，利用數(shù)據(jù)分片的方式，以堆積硬件的方式來抵抗了高流量的沖擊，當然帶來了某些業(yè)務(wù)需要跨庫查詢，跨表join等問題，不過這些問題總能以別的解決方案來應(yīng)對。

數(shù)據(jù)庫讀寫分離是解決數(shù)據(jù)庫性能瓶頸的另外一個方案，和分庫分表方案相比較，他們有著本質(zhì)的區(qū)別。分庫分表會把數(shù)據(jù)分散在多個庫表中，然后利用數(shù)據(jù)分片的規(guī)則來讀取和寫入數(shù)據(jù)，而讀寫分離是利用“冗余”的方式來應(yīng)對大流量的沖擊。

讀寫分離原理

讀寫分離的基本原理是將數(shù)據(jù)讀寫分散到不同的數(shù)據(jù)庫節(jié)點上，寫操作一般只發(fā)生在主節(jié)點，可以接受少量延遲的讀操作發(fā)生在從節(jié)點上

image

至于讀寫分離的實現(xiàn)方式：

• 多臺數(shù)據(jù)庫服務(wù)器組件成集群，并配置主從關(guān)系

• 主節(jié)點負責讀寫操作，從節(jié)點只負責讀操作

• 主節(jié)點通過數(shù)據(jù)復制機制，把數(shù)據(jù)從主節(jié)點同步到所有的從節(jié)點

• 業(yè)務(wù)方利用程序或者中間件把寫操作發(fā)送給主節(jié)點，將讀操作發(fā)送給從節(jié)點

讀寫分離優(yōu)勢

一般的系統(tǒng)都會滿足28原則，既：80%的操作是讀操作，20%的操作是寫操作。系統(tǒng)的讀操作占比越大，讀寫分離的優(yōu)勢就越發(fā)明顯，因為讀操作可以通過簡單的增加數(shù)據(jù)庫從節(jié)點來解決，當然從節(jié)點的增加并不是毫無限制，當從節(jié)點到達一定數(shù)量的時候，必然會影響主從同步的效率，會降低主節(jié)點的性能，這個時候需要考慮一致性和可用性的平衡問題了。

另外一點，在很多業(yè)務(wù)中都會有一定的數(shù)據(jù)統(tǒng)計需求，單機數(shù)據(jù)庫的時候，這些統(tǒng)計需求執(zhí)行的sql和業(yè)務(wù)sql混合在一起，在一定程度上會影響正常業(yè)務(wù)的運行，尤其是那些數(shù)據(jù)量比較大的業(yè)務(wù)場景。在做了讀寫分離的策略之后，統(tǒng)計業(yè)務(wù)完全可以獨占一個從庫來進行統(tǒng)計，就算是比較耗時的操作，也不會影響正常的業(yè)務(wù)運行。

數(shù)據(jù)庫的讀寫分離方案在所有讀操作場景中，發(fā)揮了最大優(yōu)勢

讀寫分離劣勢

數(shù)據(jù)庫讀寫分離有一個很多系統(tǒng)都會遇到的問題，那就是有些業(yè)務(wù)在寫操作成功之后需要實時的讀取到數(shù)據(jù)，可是數(shù)據(jù)從主節(jié)點同步到從節(jié)點是有一定時間延遲的，所以很多情況下業(yè)務(wù)方在從節(jié)點并不能實時的讀取到正確的數(shù)據(jù)，這種業(yè)務(wù)場景其實就是主節(jié)點也需要提供讀操作的典型場景，當然如果系統(tǒng)架設(shè)的有緩存模塊，在主節(jié)點寫操作成功之后可以同步更新緩存，以達到業(yè)務(wù)需要實時數(shù)據(jù)的要求。

路由機制

讀寫分離在寫操作上有著嚴格的要求，寫操作必須發(fā)生在主節(jié)點上，因為讀寫分離是基于中心化的思想來建立的集群，中心化的思想要求主節(jié)點上的數(shù)據(jù)必須是最新且最全的。這就要求調(diào)用方必須要區(qū)分出主節(jié)點才可以。

• 代碼封裝

用程序代碼封裝讀寫分離邏輯需要在代碼中抽象出一個數(shù)據(jù)訪問層，在這一層中實現(xiàn)操作分離以及數(shù)據(jù)庫的連接管理等。

image

用代碼封裝讀寫分離邏輯在落地上并非易事，需要經(jīng)過很長時間的測試才可以上生產(chǎn)環(huán)境。如果公司內(nèi)部存在多個語言的開發(fā)團隊，每個語言可能都需要實現(xiàn)一次，開發(fā)量還是比較大的。但是在針對不同的業(yè)務(wù)中，可以做到定制化的需求，在落地過程中還需要考慮如果主從發(fā)生切換，代碼中必須要有類似選舉的過程。

• 數(shù)據(jù)庫中間件

數(shù)據(jù)庫中間件是指基于數(shù)據(jù)庫提供的SQL協(xié)議來開發(fā)的一套和具體業(yè)務(wù)無關(guān)的系統(tǒng)，它的作用也是實現(xiàn)操作分離和數(shù)據(jù)庫的連接管理等，它同樣也是對讀寫分離的一個抽象層，但是這個抽象層是基于數(shù)據(jù)庫協(xié)議的，對于業(yè)務(wù)的使用方來說，就像訪問單個數(shù)據(jù)庫一樣方便。

image

同步延遲

任何分布式的系統(tǒng)都逃不過一致性的問題。數(shù)據(jù)庫的主從架構(gòu)也是一樣，發(fā)生在主節(jié)點的操作需要同步給每個從庫。像MySQL的主從復制是依賴于binlog的，主從復制就是將binlog中的數(shù)據(jù)從主庫復制到從庫上，一般這個過程都會采用異步的方式，因為在網(wǎng)絡(luò)延遲的情況下，如果采用同步方式會大大降低主庫的可用性。

在binlog的復制過程中，極低的概率會發(fā)生binlog還沒有來得及刷新到磁盤就出現(xiàn)磁盤壞掉或者down機的情況，最終的效果就是主從數(shù)據(jù)的不一致，但是這種不可抗拒的因素，一般是可以容忍的。

還有一種現(xiàn)象，一般數(shù)據(jù)從主節(jié)點復制到從節(jié)點會開啟單線程模式，如果主庫產(chǎn)生新數(shù)據(jù)的速度大于同步的速度，那有可能會進一步加大主從同步的延遲時間，這個是否可以考慮開啟多線程或者利用緩存模塊來屏蔽同步延遲的問題呢?

主備方案

說到數(shù)據(jù)庫主從的架構(gòu)部署方式，還有一種類似的方案：主備。主備是利用冗余一個節(jié)點來做備用節(jié)點，但是這個節(jié)點在主節(jié)點正常運行的情況下，不會對外提供服務(wù)，做了一個真正的“備胎”。當主節(jié)點掛掉，備用節(jié)點會代替主節(jié)點的位置，并成為主節(jié)點開始對外提供服務(wù)。

主備方式可以利用簡單的類似keepalive機制來實現(xiàn)自動化，理論上不需要進行選舉操作。利用主備方式來實現(xiàn)數(shù)據(jù)庫高可用有哪些特點呢?

• 可用性是利用keepalive機制來保證的，這個切換過程對業(yè)務(wù)是透明的，業(yè)務(wù)方無需修改任何代碼

• 讀寫都在主庫上進行，很容易產(chǎn)生單點的瓶頸問題，由于沒有其他節(jié)點的數(shù)據(jù)同步過程，所以數(shù)據(jù)可以保證一致性

• 主備架構(gòu)中，備庫只是單純的備份，整體的資源利用率50%，因為備庫一直在被閑置

• 擴展性比較差，無法做到橫向擴展，但是可以利用分庫分表來解決擴展性問題

一主一備或者一主多備方案在資源的利用率上很低，所以后來出現(xiàn)了多主的架構(gòu)，多主架構(gòu)是指，會存在多個主庫，每個主庫都提供讀寫功能，這就涉及到多個主庫之間數(shù)據(jù)同步的方式，雖然性能上要比一主要高，但是數(shù)據(jù)一致性上很難搞。所以很多互聯(lián)網(wǎng)公司并不推薦使用這種方案。

“如何理解數(shù)據(jù)庫集群讀寫分離”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！