解決方案

由于水平拆分牽涉的邏輯比較復雜，當前也有了不少比較成熟的解決方案。這些方案分為兩大類：客戶端架構和代理架構。

客戶端架構

通過修改數據訪問層，如JDBC、Data Source、MyBatis，通過配置來管理多個數據源，直連數據庫，并在模塊內完成數據的分片整合，一般以Jar包的方式呈現

這是一個客戶端架構的例子：

可以看到分片的實現是和應用服務器在一起的，通過修改Spring JDBC層來實現

客戶端架構的優點是：

• 應用直連數據庫，降低外圍系統依賴所帶來的宕機風險

• 集成成本低，無需額外運維的組件

缺點是：

• 限于只能在數據庫訪問層上做文章，擴展性一般，對于比較復雜的系統可能會力不從心

• 將分片邏輯的壓力放在應用服務器上，造成額外風險

代理架構

通過獨立的中間件來統一管理所有數據源和數據分片整合，后端數據庫集群對前端應用程序透明，需要獨立部署和運維代理組件

這是一個代理架構的例子：

代理組件為了分流和防止單點，一般以集群形式存在，同時可能需要Zookeeper之類的服務組件來管理

代理架構的優點是：

• 能夠處理非常復雜的需求，不受數據庫訪問層原來實現的限制，擴展性強

• 對于應用服務器透明且沒有增加任何額外負載

缺點是：

• 需部署和運維獨立的代理中間件，成本高

• 應用需經過代理來連接數據庫，網絡上多了一跳，性能有損失且有額外風險

各方案比較

如此多的方案，如何進行選擇？可以按以下思路來考慮：

• 確定是使用代理架構還是客戶端架構。中小型規模或是比較簡單的場景傾向于選擇客戶端架構，復雜場景或大規模系統傾向選擇代理架構

• 具體功能是否滿足，比如需要跨節點 ORDER BY，那么支持該功能的優先考慮

• 不考慮一年內沒有更新的產品，說明開發停滯，甚至無人維護和技術支持

• 最好按大公司->社區->小公司->個人這樣的出品方順序來選擇

• 選擇口碑較好的，比如github星數、使用者數量質量和使用者反饋

• 開源的優先，往往項目有特殊需求可能需要改動源代碼

按照上述思路，推薦以下選擇：

• 客戶端架構：ShardingJDBC

• 代理架構：MyCat或者Atlas

兼容MySQL且可水平擴展的數據庫

目前也有一些開源數據庫兼容MySQL協議，如：

• TiDB(https://github.com/pingcap/tidb)

• Cubrid(http://www.cubrid.org)

但其工業品質和MySQL尚有差距，且需要較大的運維投入，如果想將原始的MySQL遷移到可水平擴展的新數據庫中，可以考慮一些云數據庫：

• 阿里云PetaData(https://cn.aliyun.com/product/petadata/?spm=5176.7960203.237031.38.cAzx5r)

• 阿里云OceanBase(https://cn.aliyun.com/product/oceanbase?spm=5176.7960203.237031.40.cAzx5r)

• 騰訊云DCDB(https://www.qcloud.com/product/dcdbfortdsql.html)

NOSQL

在MySQL上做Sharding是一種戴著鐐銬的跳舞，事實上很多大表本身對MySQL這種RDBMS的需求并不大，并不要求ACID，可以考慮將這些表遷移到NoSQL，徹底解決水平擴展問題，例如：

• 日志類、監控類、統計類數據

• 非結構化或弱結構化數據

• 對事務要求不強，且無太多關聯操作的數據

原文出處：https://segmentfault.com/a/1190000006158186

END