在長期的鬥爭中，大家總結出了很多方式來擴展最底層的關系型數據庫：
1. 主從，壹主多從，雙寫，通過隊列暫存請求... 這些方案其實並沒有解決問題，寫入仍然是單點，而且對於 DBA 的挑戰比較大，今天我們暫時就不討論了。
2. 通過中間件 Sharding，常見的開源方案有： Cobar, TDDL, Vitess, Kingshard, MyCat 等，這些方案的思路是攔截 SQL 的請求通過 sharding key 和壹定規則，將請求轉發/廣播到不同的 MySQL 實例上，從而實現水平擴展的效果，這個方案基本解決了單點寫入的問題，對於業務來說整體的吞吐也上來了，看上去不錯，這個方案是大多數業務遇到性能瓶頸的解決方案，但是缺點也是有的：
1）大多中間件都沒有解決動態擴容的問題，多采用了靜態的路由策略，擴容壹般還處於人工 x2 的狀態，對 DBA 要求比較高。
2）從壹定程度上來說都放棄了事務，這是由於壹條語句有可能會涉及到多個數據庫實例，實現分布式 事務是壹個比較難的事情，我們後面會詳細的介紹。
3）對業務不透明，需要指定 sharding key， 心智負擔較大