簡介

RDS為使用者提供高透明，高可用，高效能，高靈活的讀寫分離服務。在最近的版本我們基於短連線的使用者進行了優化，使得短連線的使用者負載均衡更加完善合理。RDS讀寫分離有如下特性：

• 易用/透明性

使用者只需要在原來的只讀例項的主例項上開通一個讀寫分離的VIP就可以使用讀寫分離，而不需要修改任何業務程式碼。對使用者的接入成本幾乎為0。

• 高可用

RDS讀寫分離服務能夠主動判斷只讀庫的健康情況（包括節點crash，主備同步異常，延遲較大等），對於不健康的只讀庫不再進行路由，從而保證系統的整體可用性。同時在故障節點恢復後重新按權重進行負載均衡。

• 高效能

RDS的讀寫分離服務，由RDS的中介軟體服務提供路由及負載均衡，對於讀多寫少的業務能夠充分利用只讀庫的資源，使得整體業務效能得到顯著的提高。

• 高靈活

RDS的讀寫分離服務為使用者提供按權重的請求及連線雙重負載均衡模式，使用者可以根據自己只讀庫的硬體資源情況，對每個只讀庫設定相應的讀權重，同時也支援把主庫放到讀列表裡，分擔部分讀請求。

另外，為使用者提供讀庫同步延遲的可用性配置，當使用者對資料的實時性要求較高的話，使用者可以通過調小該值來保證只有在只讀庫與主庫的同步延遲小於該值時，讀寫分離服務才會把讀請求路由到該只讀庫。

擴容更靈活，使用者可以隨著業務的增長適當的擴容只讀庫，而這個也只需要在控制檯上下發一個擴容請求就可以，無需業務上做任務調整。

提供特定的hit語法：如/

/ //，方便使用者指定SQL到master或slave上執行；以及//show last route檢視sql路由情況等。

場景應用

隨著業務增長，資料越來越大，使用者對資料的讀取需求也隨之越來越多，比如各種AP操作，都需要把資料從資料庫中讀取出來，同時，隨著資料量的增加，讀請求的效能消耗也可能隨之增加，從而導致影響到使用者的寫請求，反之亦然，寫請求也可能會影響到使用者的讀請求，使得DB的總體吞吐量下降。為了解決該問題，RDS之前提供了只讀例項的方案，使用者可以通過開通多個只讀例項，將讀請求業務直接連線到只讀例項上，該方案能夠解決上述問題，但引來的問題也很明顯，使用者的使用成本增大了：需要手動區分讀寫業務，有多個訪問地址維護性差，無法做負載均衡，容易受只讀例項的可用性影響等。

RDS雲資料庫讀寫分離就是為了解決如上問題而產生的。使用者只需要一個請求地址，業務不需要做任何修改，由RDS自帶的讀寫分離中介軟體服務來完成讀寫請求的路由及根據不同的只讀例項規格進行不同的負載均衡，同時當只讀例項出現故障時能夠主動摘除，減少對使用者的影響。對使用者達到一鍵開通，一個地址，快速使用。

架構簡介

圖1 使用者鏈路檢視

對於使用者來說看到的還是一個普通的mysql連線，只是這個連線先直接訪問RDS的中介軟體服務，再由中介軟體服務進行轉發，對使用者來說是完全透明的。

• 內部框架

圖2 RDS中介軟體內部元件

RDS中介軟體服務的讀寫分離功能，主要由圖2所示的模組組成。

• RW SESSION：每個使用者連線對應的RDS中介軟體服務裡的一個rw session，其中主要維護著一個與主庫的socket以及與只讀庫的ro_session，同時負責session狀態的保持及恢復
• RO SESSION：負責與只讀庫的請求處理
• ROUTE STRATEGT：該模組也是讀寫分離的核心模組，負責sql的路由決策
• LB：load balance，負責讀請求的負載均衡，使用常用的weighted round robin演算法
• QOS：負責只讀庫的健康檢查

PS：當前PGSQL暫時不支援讀寫分離

總結

RDS雲資料庫自帶的讀寫分離服務能夠有效的解決使用者資料量大讀請求多，帶來的DB吞吐量下降等問題；一鍵開通、一個地址、快速使用極大的減少了使用者的使用成本；配置靈活，自動檢測消除了單點故障提高了系統的可用性。