636
RDS 循序漸進 – 閃斷篇
阿裏雲關係型數據庫服務（後簡稱RDS） 為用戶提供的諸多功能中，其中有一個最基本也最為重要的特性：快速為用戶部署一個“高可用”的數據庫環境。本篇我們主要一起來探討RDS“高可用”的實現方案以及在此方案中出現的“閃斷”情況。
RDS高可用實現方案
RDS 為保證高可用服務，為每個用戶購買的實例在後端提供了兩個節點，正常情況下某一時刻隻由主節點（下圖中的節點A）提供讀寫服務，而備節點（下圖中的節點B）負責數據同步；當A發生（硬件）故障時， HA控製器（代號：AURORA）會在30秒內將服務切換到B節點上麵，通過這種機製來保證數據庫實例的高可用性。
RDS 簡易鏈路訪問圖
進行主備切換後，真正生效的服務節點為B。為了主備切換對用戶和應用透明，我們使用VIP技術來提供數據服務。用戶在程序裏隻要配置VIP地址，不管後端節點切換到哪裏，都不需要變更數據庫連接地址，即可繼續與數據庫服務建立會話並完成請求。
雖然RDS在發生主備切換後，應用程序與數據庫可以建立新會話（SESSION），但在切換前APP與RDS建立好的會話（保存在A節點）已經斷開，對程序來說這部分會話已經失效，這時候需要程序有能力重新建立會話以恢複正常請求。
RDS 閃斷，是指APP與RDS之間的網絡鏈路在短時間內（一般不超過三十秒）發生了中斷，需要應用重新建立連接即可恢複；雖然是通過VIP提供服務，但APP與數據庫的連接是保存在A節點上麵，在發生切換後，APP與A節點建立的物理鏈接也會被中斷，導致APP需要與B節點重新建立鏈接；這就是閃斷發生的整個過程。
如何應對“閃斷”
處理閃斷其實很簡單，有兩種常見方法：
1） 使用“短連接”模式向數據庫發起請求
短連接模式，是指與數據庫建立會話後，隻進行一次請求，完成後該會話即被關閉；
不過短連接模式下，每個請求都需要向數據庫認證賬號與密碼，每個認證過程至少6次網絡交互，效率較低；適合於請求量較小的應用或網站采用。
2） 配置連接池，使其消除掉有問題的連接（推薦模式）
大多數連接池均包含鏈接有效性探測，適當配置後即可消除連接閃斷對應用的影響，比如適用於JAVA語言的CP30、DBCP、Druid等連接池，均可通過以下幾個參數設置(需要充分測試以確定可能的性能開銷)：
| <property value=”SELECT 1″ name=”validationQuery”></property><property value=”true” name=”testWhileIdle”></property>
<property value=”true” name=”testOnBorrow”></property> <property value=”true” name=”testOnReturn”></property> |
當然技術總是需要不斷進步的。RDS 內核團隊正在研究一種”橋接”技術，當發生節點A到節點B的切換時，可以自動讓APP與節點B建立連接，做到對APP完全透明。該技術成功突破後，數據庫的重連機製會由底層統一實現，不再需要大家去重複敲相同的代碼，那將是開發者的一大福音。
最後更新：2017-04-03 12:56:05