摘要：具有負載均衡高可用性過濾讀寫分離可路由相關的到目標數據庫可并發請求多臺數據庫合并結果。通過你能夠完成多數據源的高可用負載均衡數據切片的功能，目前已在很多企業的生產線上面使用。

相信初創公司，剛開始的時候，一般都是單機數據庫。然而數據量上來了，你就不來不考慮數據庫集群了。
一般的話，讀都會比寫多，差不多8:2的比例，具體業務具體不同。
這里就介紹下Amoeba(變形蟲)。
Amoeba是什么呢?
Amoeba(變形蟲)項目,該開源框架于2008年 開始發布一款 Amoeba for Mysql軟件。這個軟件致力于MySQL的分布式數據庫前端代理層，它主要在應用層訪問MySQL的 時候充當SQL路由功能，專注于分布式數據庫代理層（Database Proxy）開發。座落與 Client、DB Server(s)之間,對客戶端透明。具有負載均衡、高可用性、SQL 過濾、讀寫分離、可路由相關的到目標數據庫、可并發請求多臺數據庫合并結果。 通過Amoeba你能夠完成多數據源的高可用、負載均衡、數據切片的功能，目前Amoeba已在很多 企業的生產線上面使用。
當然Amoeba也有不利的地方，所以當你設計架構的時候，應該把這些因素考慮進去。

1.目前還不支持事務；
2.暫時不支持存儲過程，官方說近期會支持；
3.不適合從Amoeba導數據的場景或者對大數據量查詢的query并不合適，比如一次請求返回10w以上甚至更多數據的場合；
4.暫時不支持分庫分表，amoeba目前只做到分數據庫實例，每個被切分的節點需要保持庫表結構一致。

若實際項目中所需要的功能正式Amoeba的短板，建議使用Mysql Proxy作為中間件，或者在應用層通過程序控制數據源，手動實現數據庫讀寫分離。
當然Amoeba除了上面的明顯的缺點外。在實際使用中，你會遇到很多問題。一個很明顯的問題就是：如何解決主從數據庫同步延遲問題？
這里我可以提供一些思路：

1、有更新數據后的 讀取相關數據動作，都從默認到主庫；
2、利用緩存；插入新的數據，會有last_id返回，組裝成數據，緩存到前端。讀取此 id 數據時，先從緩存取。
...    

當然問題提出來，有很多解決方案，具體業務具體分析。這里只做參考。
關于Amoeba環境的配置，我也不多介紹，網上一大堆教程。 這里我只簡單介紹下Amoeba，具體使用，需要自己去摸索。自己不去摸索，永遠學不會。
Amoeba使用指南（http://docs.hexnova.com/amoeba/）
其實技術問題都好解決，關鍵是要提出問題，然后怎樣合理設計架構去解決問題。我喜歡研究各種技術解決方案，然后比較之，吸取精華，設計出最佳的解決方案。
針對上面問題，大家可以提出自己的思考。歡迎留言討論。