[[340907]]

 “靈魂拷問：

• 解決數據庫讀寫瓶頸有哪些解決方案呢?
• 這些方案解決了什么問題呢?
• 這些方案有那些優勢和劣勢呢?

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

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

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

讀寫分離原理

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

image

至于讀寫分離的實現方式：

• 多臺數據庫服務器組件成集群，并配置主從關系
• 主節點負責讀寫操作，從節點只負責讀操作
• 主節點通過數據復制機制，把數據從主節點同步到所有的從節點
• 業務方利用程序或者中間件把寫操作發送給主節點，將讀操作發送給從節點

讀寫分離優勢

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

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

數據庫的讀寫分離方案在所有讀操作場景中，發揮了最大優勢

讀寫分離劣勢

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

路由機制

讀寫分離在寫操作上有著嚴格的要求，寫操作必須發生在主節點上，因為讀寫分離是基于中心化的思想來建立的集群，中心化的思想要求主節點上的數據必須是最新且最全的。這就要求調用方必須要區分出主節點才可以。

• 代碼封裝

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

image

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

• 數據庫中間件

數據庫中間件是指基于數據庫提供的SQL協議來開發的一套和具體業務無關的系統，它的作用也是實現操作分離和數據庫的連接管理等，它同樣也是對讀寫分離的一個抽象層，但是這個抽象層是基于數據庫協議的，對于業務的使用方來說，就像訪問單個數據庫一樣方便。

image

同步延遲

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

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

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

主備方案

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

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

• 可用性是利用keepalive機制來保證的，這個切換過程對業務是透明的，業務方無需修改任何代碼
• 讀寫都在主庫上進行，很容易產生單點的瓶頸問題，由于沒有其他節點的數據同步過程，所以數據可以保證一致性
• 主備架構中，備庫只是單純的備份，整體的資源利用率50%，因為備庫一直在被閑置
• 擴展性比較差，無法做到橫向擴展，但是可以利用分庫分表來解決擴展性問題

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

寫在最后

數據庫的擴展由于其屬于有狀態的范疇，所以比無狀態的網站或者服務要困難很多。現在主流的落地方案也都是基于“分”的策略，分庫分表方案和主從讀寫分離方案是兩種最常用的擴展方式，在很多情況下，二者是結合起來使用的，即：在分庫分表的情況下，每個節點采用主從讀寫分離的方式，這也是目前比較主流的方式了。

本文轉載自微信公眾號「架構師修行之路」，可以通過以下二維碼關注。轉載本文請聯系架構師修行之路公眾號。