偽資料庫叢集設計

網路上充斥著『偽』資料庫叢集設計，只好祭出這篇說明文。

當資料庫出現效能瓶頸時，通常祭出的不是 Scale Up (硬體升級) 就是 Scale Out (向外擴展)，其中 Scale Out 又以 Sharding 及 Clustering 最常見。

Sharding 若沒有【架構】及瞭解【資料庫設計】的人，愈做會愈流淚。而且隨著 Sharding 粒度愈細，串接資料庫的工程師寫的程式架構與邏輯也會更複雜。最後可能變成一個難以維護的系統。

而 Clustering 不管是 MySQL Cluster / Galera Cluster / Pgpool，在大量的 INSERT / UPDATE / DELETE 時，依然會頻繁地出現 deadlock 問題。

然後有人開始推出奇怪的變種。

最多人推薦的是 single-write-multi-reads 架構。這種蠢架構又把【寫入】這事集中在一台機器上了，那我們建置 Clustering 是搞心酸的嗎？而且不管是 Percona 或 Severalnines 竟然都下海推薦。

• Percona XtraDB Cluster reference architecture with HaProxy
• Avoiding Deadlocks in Galera - Set up HAProxy for single-node writes and multi-node reads

於是沒辦法解決這問題的人都紛紛跑去 NoSQL 陣營了。

好樣的，只好打開沉寂一陣子的密招，這下我要連 Load balancer (HAproxy / AWS Elastic Load Balancing) 都直接摘掉，在不增加任何機器及不轉 NoSQL 的條件下，把魔鬼藏在演算法中，以函式庫的方式嵌入在原本的 Web servers。

如此，維持完美的 Sharding / Clustering 架構，也解決了 deadlock 的問題。