一文淺談“讀寫分離”技術

1).何為讀寫分離

讀寫分離，從字面理解就是將對資料庫的讀操作與寫操作分離的一種最佳化手段。其最早起源於網際網路快速發展時期，面對海量使用者訪問問題，透過這一技術來解決資料庫效能瓶頸問題。目前已經成為非常常見的一種資料庫訪問最佳化技術。

2).讀寫分離好處

目前業界流行的讀寫分離方案，通常都是基於上述主從模式的資料庫架構，透過引入資料訪問代理層，來實現訪問動作的讀寫分離。引入資料訪問代理的好處是源程式不需要做任何改動就可以實現讀寫分離，壞處是由於多了一層中介軟體做中轉代理，效能上會有所下降，資料訪問代理也容易成為效能瓶頸，並且還存在一定維護成本。還有另一種方式，是將資料訪問代理層前置到應用側，透過SDK方式與應用整合在一起，可避免獨立一層所帶來的效能損耗和維護成本高的問題。但這種方式對開發語言有一定要求，存在適用性問題。

2).技術要點

讀寫分離功能的好與不好，主要是在易用性和靈活度問題。前者是關心如何讓業務開發像操作單個主庫一樣，無需過多關注主從讀寫分離的細節，只需要做好相應讀寫配置後，就無需考慮寫主讀從的細節。後者是解決使用者多變的業務場景和拓撲變化，並可實現自動適應。這其中是需要解決一系列技術問題，如下面這些常見的問題。

❖ 判斷讀寫操作

如何判斷讀寫操作，是讀寫分離面臨的首要問題。判斷方式可大致分為自動和手動兩種，前者是透過顯式的方式由使用者來指定；後者則是自動進行判斷，使用者無需關心。這兩種判斷方式往往是互補的，可配合來使用。下面是常見判斷邏輯及處理：

該實現方式就讀寫分離功能而言不是太好，因為此方式與應用自己實現沒有明顯差別，只是將直接連線不同資料庫的邏輯變成了連線中介軟體伺服器的不同埠，並沒有對應用系統開發帶來實質性的簡化工作。

採用正規表示式匹配是比較容易實現的方案，可以無需應用的修改，只需要在中介軟體新增正則匹配的規則，即可將讀、寫分發的邏輯在中介軟體完成。讀寫分離的效果，取決於中介軟體的正則匹配規則的編寫質量。

應用系統傳送SQL時，可以新增Hint，顯示的告訴中介軟體想要將該SQL傳送到何處。中介軟體解析特定規則的Hint，即可實現對帶有不同Hint的語句分發到不同的資料庫節點。

當中介軟體獲取到應用傳送的SQL字串時，對其進行完整的語法解析，可以最大程度的獲取SQL字串中的資訊，例如型別、操作物件等。基於語法的判斷，就能夠自動針對不同語句型別進行讀寫分發，可以最大限度的減少應用的適配工作。

使用語法解析是相對來說較為友好的方式，無需開發人員感知即可實現讀寫操作分離。但這其中存在難點，就是如何準確判斷出只讀操作存在一定困難，例如使用函式、儲存過程、觸發器或諸如“SELECT ... FOR UPDATE”類的操作。此時，是需要引入輔助機制進行判斷，可採取配置名單方式來輔助分析；或者透過Hint、API的方式強制指定走寫庫或讀庫。除此之外，還有些命令也需要規範是否可在備庫執行，如COPY、SHOW、SET、BEGIN...END等。

❖ 如何處理事務

事務類操作，往往意味著資料變化，在讀寫分離中如何處理呢？通常有兩種思路，一種是簡單粗暴方式，將所有事務及關聯操作全部傳送到主機；一種是更為精確的處理，即分析事務內的語句序列，將事務中先寫後讀的物件進行關聯，一起傳送到主機，確保資料正確，而把和寫操作無關的讀操作，進行拆分，傳送到備機執行。後一種處理方式能最大限度的利用讀寫分離，當然需要解決物件前後關係這一問題。

❖ 解決主備延遲

基於副本方式的延遲是常見的，也是讀寫分離在設計之初就需考慮的問題。其通常的處理思路可以有多種：

這類解決方案最簡單粗暴，也是實際工作中最常用的方案。透過對主備節點延遲情況的判斷，來決定如何是走主庫還是備庫。通常可將延遲判斷封裝在中間層，前端應用可不感知，只需配置延遲閾值即可，當超過這一閾值就自動走主庫。如下次訪問時延遲低於閾值，可重新走備庫。當然，這一方式無疑會加大對主庫的壓力。

當在備庫讀取不到最新資料時，另一種思路多讀取幾次或者嘗試讀取其他備庫。這裡面的核心是對讀取最新資料的判斷，通常需要在應用開發時有所考慮才可。同時還需要制定退化方案，在何種情況下退化到讀取主庫。

如延遲是常態，很難短期內解決，透過引入快取可達到立竿見影的效果。其原理是在資料寫入主庫時，同步或非同步寫入快取，應用讀取時優先讀取快取，失效時才讀取資料庫。這種方案因引入快取元件稍顯複雜，需解決快取與資料庫同步更新及失效問題；同時對應用側有一定影響，需感知到快取。比較好的處理方式是都封裝在中間層，透過它來統一處理訪問邏輯。

最後一種就是儘量避免出現延遲，常見對資料庫有些可最佳化的措施。例如儘量減少在主節點上執行大事務操作、減少主庫索引進而減小寫入開銷、主備庫採用不同儲存引擎提升效率等等。當然這些方案只能起到一定作用，無法完全避免延遲問題。

❖ 靈活負載策略

針對多個讀庫，讀寫分離元件還需提供靈活的負載均衡策略，常見的如隨機、輪詢、權重等等。這其中有幾個特殊情況需要考慮：

不同讀庫的服務能力有所差異下，其能提供的服務保障不同，需在讀寫分離中提供例如權重的配置，進行干預。當然，更好的方式是提供服務質量評估機制，可根據各讀庫的服務能力進行分配。

針對多AZ、多Region的情況，不同讀庫承載的角色不同，有的只作為備選主庫不承擔讀、有的作為遠端災備等，因此在讀寫分離中希望能感知到這些資訊，有所區別對待。往往可透過設定標籤的方式解決，根據不同標籤設定不同策略。

❖ 解決讀一致性

在讀寫分離中，當存在多個讀庫下，會因為延遲不同，出現讀取不一致的情況。即路由到不同的讀庫，讀取的資料鮮活度不同。這對於前端應用會造成一定困擾，解決的方法可採用會話粘性的策略，針對同一會話路由到同一讀庫，避免出現讀不一致。

❖ 拓撲結構感知

如果讀寫分離訪問的資料叢集拓撲發生變化，例如主備發生切換，寫操作要到新的主庫；亦或是增加了備庫數量，流量可以打到新備庫等，這些都是需要讀寫分離元件感知到底層資料庫拓撲的變化。這裡的難點在於幾個方面：

當出現網路等原因，底層發生變化，可能讀寫分離元件沒有探查到；或者探查本身就出現問題，沒有發生變化而誤認為發生變化。此時就會出現兩張拓撲結構，一個實際結構，一是讀寫分離元件感知到的結構。這一問題，一方面可透過引入共識機制，增加多方判斷解決；一方面也可透過與高可用元件互動減少誤判。

當發生拓撲變化後，從發生變化到被讀寫分離元件感知是需要時間的，過短會導致資料庫探查壓力大；過長會影響整體恢復時間，這其中需要有個取捨。建議將這一能力開放給使用者，由使用者根據自身業務進行決策。同時也可與高可用元件互動，將拓撲變化資訊儘快推送到讀寫分離元件，變被動探查為主動感知，提高時效性。

除因故障等原因發生的拓撲變化外，有時還需人工干預讀寫分離。如發生機器維護、資料庫升級等情況下，可提前透過人工手段，從拓撲結構中摘除相關節點，做到更加平順。

❖ 個性化訴求

除了上述要點外，還有些使用者個性化的需求。如某個資料庫使用者的訪問只走主庫，某類應用的訪問只走主庫等，這類需求比較分散，比較好的處理方式是提供一定的指令碼擴充套件能力，類似lua擴充套件Nginx的方式。

讀寫分離技術，是一種有效的資料庫訪問最佳化手段，但不是唯一。隨著業務增長，達到一定規模後，提升資料庫承載能力可以有多種方式，從大的分類來看可分為業務層最佳化、架構層最佳化、訪問層最佳化與資料庫最佳化幾個方面。

從上述對比可見，讀寫分離，可以說是對應用侵入最小，也最容易實現的最佳化手段。相對投入不到，就可取得一定效果。特別是對於大量讀請求和少量寫請求的業務場景，會有不錯的效果。

2).讀寫分離適用場景

讀寫分離是一種簡單有效的最佳化方式，但不是萬能，其有著明顯的適用場景特徵。

當單機資料庫不能支援業務的讀寫規模，就可以考慮讀寫分離。但需要考慮兩者的比例，如果寫操作比例大於讀操作，那麼大量寫操作都在主庫進行，讀寫分離達不到預期降低主庫壓力的作用。一般來說，兩者讀寫比越大，效果越好。當然還需考慮寫規模不能也不能高於單機資料庫支援規模。

針對承載讀的規模超大的情況，也需慎重。透過讀寫分離是可以實現一定程度讀操作的橫向擴充套件，但不是無限的，受限於資料庫複製的效率與成本，其存在擴充套件上限。對於大規模的可綜合考慮快取、資料拆分等多種手段。

針對主備方式難免存在延遲，因此對於延遲很敏感的操作不適於此方案。

採用讀寫分離能在一定程度上解決查詢效率問題，但針對複雜查詢試圖透過這一方式去解決不是一個好的思路。這類訴求建議透過搜尋引擎、OLAP等技術去解決。

1).MySQL-Proxy

MySQL-Proxy是MySQL官方提供的MySQL中介軟體服務。MySQL-Proxy實際上是在客戶端請求與MySQLServer之間建立了一個連線池。所有客戶端請求都是發向MySQL-Proxy，然後經由MySQL-Proxy進行相應的分析，判斷出是讀操作還是寫操作，分發至對應的MySQLServer上。對於多節點Slave叢集，也可以起做到負載均衡的效果。

# ./mysql-proxy --daemon --log-level=debug --user=mysql --keepalive --log-file=/var/log/mysql-proxy.log --plugins="proxy" --proxy-backend-addresses="192.168.1.5:3306" --proxy-read-only-backend-addresses="192.168.1.6:3306" --proxy-lua-script="/root/soft/mysql-proxy/rw-splitting.lua" --plugins=admin --admin-username="admin" --admin-password="admin" --admin-lua-script="/root/soft/mysql-proxy/lib/mysql-proxy/lua/admin.lua"

其中proxy-backend-addresses是master伺服器，proxy-read-only-backend-addresses是slave伺服器。

2).Apache ShardingSphere

Apache ShardingSphere 是一款開源的資料庫中介軟體產品，並在Apache基金會畢業，可以說是非常成熟的開源專案。其產品內建了豐富的功能，包括讀寫分離能力，具體包括：

3).MyCAT

MyCAT 是一款開源的資料庫中介軟體產品。讀寫分離功能透過配置檔案完成，如下

balance，讀寫分離策略

writeType，寫模式

switchType，切換模式

4).阿里雲-RDS資料庫代理（以RDS PG為例）

資料庫代理是阿里雲資料庫RDS提供的一款安全、穩定、高效能，對應用完全透明的資料庫中間層服務。資料庫代理是位於資料庫服務端和應用服務端之間的網路代理服務，代理服務端代替應用服務端資料庫傳送和接受所有資料庫請求，進而可以在代理服務層上實現比如讀寫分離、連線池、端對端加密、防閃斷等附加功能。透過資料庫代理使用者只需要透過一個連結地址即可實現讀寫分離架構，讀寫屬性和只讀屬性的多樣化選擇滿足了不同業務場景。

資料庫代理支援了PostgreSQL的協議，並且具備對使用者的請求連線認證許可權的能力。代理中的路由策略是核心：可以透過hint中指定固定的例項節點來轉發流量；也能夠將事務內寫操作之前的讀請求轉發到只讀例項，降低主例項負載；路由策略還可以根據使用者自定義的只讀模式或讀寫模式對請求進行不同的分發執行。健康巡檢模組週期性感知讀寫分離架構的拓撲變化情況，在例項節點不健康或者超過延遲閾值，會自動把讀請求路由到其他的只讀例項上。

5).OceanBase

OceanBase 資料庫天然支援讀寫分離的功能，即透過 OBProxy 代理服務和修改 OBServer 的配置即可實現業務的讀寫分離策略。OceanBase 資料庫在讀取資料時，提供了兩種一致性級別：強一致性和弱一致性。

透過應用側為執行的 SQL 新增 SQL Hint 來顯性開啟弱一致性讀就可以實現基於註釋的讀寫分離功能，同時也衍生出如下三種常用的讀寫分離策略：

6).KunlunBase

KunlunBase是一個開源、高效能的分散式關聯式資料庫，支援混合負載、PB級資料量管理並提供毫秒延遲的新一代資料庫解決方案。

KunlunBase 的讀寫分離在計算層的遠端查詢最佳化器內實現的，當使用者的SQL同時滿足如下條件：

      - 如果在只讀事務中，則允許讀寫分離；

     - 如果在讀寫事務中，則該事務未更新過資料；

遠端查詢最佳化器就會將相應的SQL 執行計劃下發到從備機的節點上執行。KunlunServer 會根據以下規則選擇傳送select語句到目標儲存叢集的哪個備機節點：