技術選型
既然要分庫分表那數據庫集羣是少不了的，那我們的項目怎樣和這些集羣打交道呢？我調研了大概分爲以下幾種來完成這個功能（僅僅針對java項目）
|
中間件 |
例如淘寶開源的cobar，以及後來開源社區根據cobar做二次開發的Mycat（個人建議如果使用中間件的話可以考慮Mycat） |
|
Jar形式的開源工具 |
例如淘寶的TDDL，以及噹噹開源出來的，Sharding-JDBC等 |
|
動態數據源 |
根據自己的業務來指定數據源來完成不同庫和表的操作 |
主鍵生成策略
既然要分庫分表那麼全局唯一主鍵也是我們需要考慮的問題，我所知道的和有使用經驗的有如下幾種技術：
|
|
問題 |
可行性 |
|
基於redis |
單點問題，redis重啓問題等 |
較高，公司有項目使用 |
|
給予DB（每次生成多個使用時去取出來） |
單點問題，併發量問題 |
低併發，數據量較小的可以使用 |
|
UUID |
暫用存儲空間比較大，非可排序的，體現不出增長的趨勢 |
較高 |
|
twitter snowflake |
Xx年以後可能存在重複問題，需要配置生產參數 |
高，分佈式的沒單點故障問題，時間上是遞增的。推薦 |
|
基於DB步長的方式 |
不是所有數據庫都支持 |
低 |
分庫分表後能解決我們的性能問題，但是也帶來了很多其他的問題：
1.分完之後只能直接按分片鍵查詢，爲了避免掃所有分片，如果按非分片鍵查詢，在OLTP環境中得走搜索引擎。數據庫和搜索引擎同步數據靠binlog
2.按不同維度查詢，比如買家維度和賣家維度查訂單。除了走搜索引擎之外，還可以在不同的系統中各寫一條訂單數據。
3.ID得通過ID生成器。
4.有熱點數據問題，比如一個超級買家，買了好多種商品，然而還有不怎麼熱的買家，沒什麼訂單。解決方法兩種，熱點數據拿出來放到單獨的系統。或者按數據塊分片，比如十種商品算一個塊，但這種方法具體細節我忘了，只是聽人分享過。
5.跨庫事務問題，NPC一般不用，補償是一種方法，TCC是一種方法，TCC的變種，比如SAGA比如XTS，努力送達是一種方法
6.數據擴展問題，可以看看阿里的愚公。我個人覺得還半夜停機維護比較靠譜。
7.分頁的坑，前期可以用中間件Limit，中期得走搜索引擎，後期OLAP
8.可用性問題，依賴數據庫高可用方案。據說會出現 sharding 算法 會因爲網絡抖動 造成部分分區錯誤 導致片出問題
9.配置中心問題。儘量使用配置中心，不要用zookeeper
10.非代理模式，就是JDBC路由模式 每個client都會對 db開啓pool ，數據庫可能會死在數據庫連接上，一種方法是定製
Mysql，設置高低水位，讓超過數據庫處理能力的數據庫連接排隊。第二種方法是在JDBC路由模式之上做Mysql的Proxy