POLARDB
筆者實習期間在某公司做雲計算開發，組内項目不成熟正巧趕上換底座的工作，要求實作程序當機和節點當機的高可用無感覺切換。
湊巧分到了實作Mysql資料庫高可用部分，實作過程中磕磕絆絆，但是關于資料庫有了初步的架構認識。
今天“阿裡爸爸”面試官老師打電話過來問是否有意向進行資料庫核心開發工作，介紹後原來是早有耳聞的POLARDB，懷着好奇心研究了下POLARDB的架構，解開了我在搭建資料庫高可用的許多疑惑
我是如何實作的
高可用其實是一個宏觀的問題，是以先來看看總體的架構圖
每次當機後，前者都會按順序拉起後者
systemd --> supervisor --> 所有無狀态服務
那麼這樣的架構為什麼就可以實作MySQL的高可用，其實分為兩種情況：
- 情況一：MySQL程序死亡，那麼supervisor就會定時的探測其狀态，如果發現死亡則主動拉起
- 情況二：MySQL所在的實體機當機，keepalived将故障的機器移出叢集，備用節點上的nginx啟動backup資料庫代理
- 情況三：僅nginx當機，keepalived可以寫定時腳本檢測所要保活的任務是否正常，如果不正常則自殺，所在MySQL實體機被移出叢集
更細緻的細節
我們的項目由于隻搭載在倆台管控系統上，是以選擇管控節點的主備方案：但是，我們的資料庫方案其實并沒選擇一主一從方案
為什麼資料庫不選擇一主一從
因為MySQL是靠nginx走的4層代理，如果資料庫在一主一從的情況下主庫發生當機，資料将會開始在從庫寫入，如果不巧此時主庫恢複，經過測試nginx又會重新代理主庫，這樣就造成了資料的不一緻
我們選擇了雙主方案，發生相同情況時隻要IO線程和SQL線程沒有死亡，那麼就算重新代理主庫也能保證資料同步
雙主模式是否會引起倆節點同時寫入的情況？
可以看出目前模式下其實就算是雙主配置，由于nginx同一時間隻會代理一個節點的資料庫，是以不會發生倆個節點同時寫入的情況
但！！也不完全一定，如果使用者将主備節點錯誤配置到了倆個網絡分區，此時就發生了keepalived腦裂，他們認為他們之間互相死亡，是以會對倆個資料庫同時寫入
雙主架構如何實作
筆者有了解過galera叢集方式、MHA三節點方式，但是都不如倆個資料庫互為主從模式簡單
最初，我們使用了MySQL 5.6版本更進階的GTID技術，完全基于事務，不用在發生錯誤時去手動連接配接pos點，但最後卻犯了緻命的錯誤放棄了
并不是GTID不可用，而是這個技術限制不可以事務中建立大量的臨時表，但是java的hibernate必須建立臨時表，最終導緻隻能選擇普通的主從複制方式。
存在的問題
雖說項目上線後，程式經過測試确實實作了高可用，而且比預期好很多，但是還是發現了下面的問題
- 管控擴容的問題：目前架構隻适合主備模式，後期如果需要加入更多的資料庫該如何擴容
- 達不到無感覺切換程度：當nginx需要切換backup進行代理時，需要一定的時間來進行切換
- 異步複制延遲大：當出現重大事故需要全量資料恢複時，主從複制延遲缺陷就展現了出來
- 冷資料髒資料無法清理：由于之前開發的錯誤，導緻資料庫中有大量的冷資料和髒資料
POLARDB如何解決我的問題
ps：圖檔來自POLARDB v2.0新聞釋出會
從架構上來看，我的nginx反向代理就像是POLARDB的PolarProxy，也是隻向使用者暴露唯一通路位址
第二層的資料庫引擎可以類比為我的資料庫節點
第三層也是讓我覺得設計非常驚豔的一層，普通資料庫其實計算存儲是一體的，但POLARDB則使用了共享存儲，這就以為者解決了我所遇到的最大問題
- 達不到無感覺切換程度：POLARDB采用共享存儲，主從切換可以做到秒級
- 異步複制延遲大：POLARDB采用共享存儲架構，主從切換不需要資料重構
而資料庫節點無法擴容的問題也得到了良好的解決：
- 管控擴容的問題：POLARDB的計算節點可以分鐘級擴容，任何時刻發現業務量突變即可快速擴容
冷資料的問題也在2.0版本的OSS存儲得到解決（但釋出會并未透露如何解決的），也整理了POLARDB其他的優點
POLARDB的特點
1、更新硬體需要遷移資料，更新周期長，無法從容應對突如其來的業務高峰。
（POLARDB的計算節點可以分鐘級擴容，任何時刻發現業務量突變即可快速擴容。）
2、金融級可靠性要求RPO=0，傳統架構使用執行個體層同步多副本，性能損耗巨大。
（POLARDB的存儲為多副本，底層使用RDMA、Parallel Raft、3D Xpoint等最新的軟硬體技術，性能比傳統架構最高提升6倍。）
3、執行個體層複制HA架構，主從切換時間長，無法滿足金融級連續性要求。
（POLARDB采用共享存儲，主從切換可以做到秒級，同時在計算與業務層之間有一層代理層，代理層可以幫助使用者識别計算節點的異常，自動切換，在大多數時候業務感覺不到計算節點的切換，保證了業務連續性。）
4、傳統HA架構采用主從異步複制，切換後從庫可能需要重建，耗費資源多，重建時間長，存在長時間單點故障。
（POLARDB采用共享存儲架構，主從切換不需要資料重構。）
5、每個隻讀節點都需要一份與主完全一樣的副本，成本高。
（POLARDB采用共享存儲架構，增加計算節點，不需要增加存儲副本數，使得整體成本相比傳統架構低很多。）
6、讀寫分離采用邏輯REDO複制，主從延遲高。
（POLARDB的資料存儲為共享存儲，不需要同步REDO資料，隻需要同步REDO的位點，主從延遲在毫秒級。）
7、sharding架構沒有想象的好，功能閹割、對業務有巨大侵入（限制SQL較多）。
（POLARDB完全相容MYSQL，對業務沒有任何侵入，使用者不需要修改一行代碼即可使用POLARDB。）
8、TB以上執行個體備份慢，往往數十小時。
（POLARDB使用快照備份技術，無論資料量多大，秒級備份）
POLARDB 2.0版本則實作了更多的功能，有待筆者進一步的深入研究。
後續
已成功加入polardb團隊，和我想的居然有點不太一樣，讓我在好好研究幾天更新文檔，麼麼叽！