MySQL Cluster, Fabric, Cobar 三大集羣特性對比

MySQL有衆多集羣方案，大多數公司用到的都是主從、讀寫分離、galera這類多主方案，很是適合於中小企業。對於大企業咱們須要分表分庫，我以前寫了3篇關於有分表分庫功能的MySQL集羣方案Fabric, Cobar, MySQL Cluster，使用這些方案可以簡化分表分庫的邏輯，加快開發速度。只看這3篇零散的文章還不可以很好的爲本身公司應該使用那種方案作出選擇，咱們這裏對這3種方案做了詳細的對比，他們各有優缺點，但願可以對您的選擇有所幫助。特性對比狀況請看下面的表格：

 

若是咱們本身在代碼中直接寫分表分庫，每每跟Fabric有點類似，代碼中用Hash或範圍查找某ID屬於哪一個數據，而後直接鏈接對應的MySQL服務，所以跨庫的操做就不支持了。當咱們要分片的表操做能夠只涉及單個分裂字段的那些行時，即不須要跨庫時，能夠選用Fabric。好比按用戶id分片，一個用戶在該表會有多行數據，然而他們都會被分到同一個庫中，用戶對本身的數據操做是沒有問題的。Fabric幫咱們作了不少運維相關動做，方便了使用。

若是操做時有時須要跨庫，可是能夠不要事務時，能夠考慮Cobar，當操做不符合分片查找規則時，Cobar會對全部庫進行操做，雖然最後返回的結果可能不如人意，加上少許代碼處理下結果，便可知足業務需求。而且Cobar是支持MariaDB的，另外兩款都不支持，所以當必須選擇MariaDB時也能夠考慮用Cobar。

若是不只有時須要跨庫，並且必定要事務時，能夠考慮用MySQL Cluster，雖然事務級別低了一級，仍是可以獲得很好的隔離效果的，通常可以知足您的事務需求。

若是必須要大量的跨庫，而且是全部庫都要操做，並且沒法優化成少許跨庫，那麼前面的三種集羣方案都不適合了，MySQL自帶的主從方式也許是最好的，提升下硬件，好比配置SSD，更多的內存CPU，讓寫操做都在一個庫裏完成反而會更快，更節省資源