之前工作做了下分庫分表的技術選型，對現有的中間件進行了一番總結。
最開始想用mycat的，畢竟名氣大，但查閱了文檔和結構，發現下面的分庫分表面對的3個問題無法解決。
最後選擇使用sharding-jdbc，在jdbc層面做庫表關聯，更底層些。年後該框架作者去了京東，有單獨的團隊維護。
分庫分表面對的3個問題：
1.事務一致性：比如更新10張表，最後一張失敗，怎樣保證事務。
2.字典表問題：一般字典表維護在一個庫中，分庫查詢的話影響效率，每個庫都存儲一份字典表的話，上表面提到的事務一致性問題又會出現。庫之間也會過於冗餘。
3.分頁查詢：比如查詢100到110之間的數據，做法可不是每個庫取100~110間的數據，再去前10條，而是每個庫查詢0~110間的數據，比如10個庫，就會返回 10 * 110條數據，再從這裏取100~110間的數據。這裏的問題就是如果是 500000~500010的話，返回的數據量就太大了。
Atlas：不能實現分佈式分表，所有的子表必須在同一臺DB的同一個database裏且所有的子表必須事先建好，Atlas沒有自動建表的功能。Atlas參考鏈接
Cobar：必須將拆分後的表分別放入不同的庫來實現分佈式。Cobar參考鏈接
TDDL：阿里，功能強大，過於複雜，部分開源。需要評估使用情況，防止過剩。
Mycat ：國內開源，從入門到放棄。mycat參考鏈接
heisenberg：百度開源，相對簡單，易於管理。heisenberg參考鏈接
Oceanus：功能強大，開源，簡化開發和配置成功。但產品還不成熟。
vitess：google產品，集羣基於ZooKeeper管理，通過RPC方式進行數據處理，可支撐高流量，它還添加了一個連接池，具有基於行的高速緩存，重寫SQL查詢，更安全。vitess參考鏈接
OneProxy：中國廠商產品，穩定性待確認。OneProxy參考鏈接
Sharding-JDBC：噹噹最新開源，jdbc層面操作。Sharding-JDBC參考鏈接
選型考慮3點：
1.產品功能和可擴展性：mycat就是不行。就是名氣大，已經到頭了。Cobar也是可擴展性的問題放棄的
2.產品是否成熟，或者說可用，比如國內的一般就不考慮了，穩定性是個問題。百度的heisenberg其實不錯，但是代碼很久沒有維護了，社區也不積極，就放棄了。google的vitess也可以 ，但是海外的產品，也放棄了。
3.實際情況：我們公司是騰訊系的，阿里的TDDL顯然不能用了。
響應的細節就不貼了，參考鏈接都有。