memcached 和 mysql 結合使用的兩種實現選擇？

02-01

我們的應用已經決定採用 mysql+memcached 的方式，針對的資料庫版本是 mysql 5.1，目前已經進行了半個月的編碼實現：
1.採用的是」memcached 和mysql 獨立的實現方式，在編碼層控制讀 memcached，找不到再去資料庫讀，寫資料庫，然後再去更新 memcached，在這個過程發現邏輯複雜度比較高。
2.現在發現「Using the MySQL memcached User-Defined Functions」的實現方式，是通過觸發器解決以上複雜邏輯的，從我的感覺上來看，應該是降低了代碼複雜度。

我想諸位老師幫助我從理論上分析一下這兩種方式的利弊，當然最好從實戰角度分析兩者的利弊，或者兩者在使用上有什麼值得注意之處，哪種更好，謝謝。

@盧鈞軼老弟分析的非常不錯

1.採用的是」memcached 和mysql 獨立的實現方式，在編碼層控制讀 memcached，找不到再去資料庫讀，寫資料庫，然後再去更新 memcached，在這個過程發現邏輯複雜度比較高。

我非常好奇為啥做這個模塊需要半個月的編碼時間？難道是做的MySQL同步到MC的做法是通過MySQL的二進位日誌？？

不知道你的業務模型，若是修改量非常大的話，數據同步會存在非常大的壓力，不管是先寫資料庫再程序更新MC，還是寫完資料庫再藉助MySQL二進位更新MC，都可能存在嚴重的問題（注意前提：系統寫負載大的情況）：

1&>.方式一：有可能導致大量的任務等待，以及資料庫更新速度跟不上的話，就更可怕；

2&>.方式二：因產生大量需要解析和同步的寫事務，導致MC更新延遲而可能影響用戶的數據請求，以及數據同步解析的負載壓力非常大；

推薦做法：系統寫負載大的業務場景

1&>.數據允許存在丟失的風險，則可以考慮先寫MC直接返回給用戶，然後後台程序或隊列的方式非同步更新資料庫，不管是讀數據還是寫數據，都是先訪問MC；

2&>.數據不允許丟失的風險，則先寫資料庫，並且對MC中對應的數據標誌為過期；讀業務優先對MC請求，若是數據不存在，則對資料庫進行操作，並且把數據載入到MC中，定期清理MC過期的數據。

申明：本人以前寫過VC++，但是真不會寫Linux環境下C/C++了，但是做的設計方案，都是讓自己所帶領的C++團隊編碼實現，業務流程是先寫MC，再非同步到資料庫，通過數據中間件控制。

觸發器的開銷其實不低，加一個觸發器的開銷跟一個索引相當，我們當時測試過，單線程情況下（如果是從庫更新MC）大概資料庫響應時間會延長60%。多線程的情況下（主庫更新MC），根據線程數不同而不同，記得300個並發的時候，資料庫的響應時間是之前的300%還多，因此從performace的角度看，不是個好選擇。

另外維護資料庫存儲過程和觸發器的開銷絕對比維護應用程序代碼（java，python....）大的多。

我喜歡在應用層做，沒覺得邏輯複雜在哪裡。

幾個要點

1：memcache和mysql的鏈接時間，如果兩個鏈接同時開啟，先開啟的會影響後開啟的，比如memcache先開啟鏈接，然後開啟mysql，如memcache阻塞，程序未及時釋放，會連帶導致mysql崩潰，這種情況以前遇到過，記住鏈接必須加超時限制，防止連帶阻塞現象。或者，釋放memcache連接後，再開啟mysql鏈接（這樣不利於程序封裝）

2：memcache命中率如不高，不如不用。做memcache應用後，第一件事情是測試命中率情況，不能認為加了緩存就一定可以提高效率。

3：如果數據塊較大，放在memcache中讀取的效率或許不如mysql。

4：隨時監控swap分區佔用情況，確保內存使用合理。

5：memcached適合簡單的key-value查詢，如果涉及結構性內容，或者排名類應用，建議使用redis.

&>&>在編碼層控制讀memcached，找不到再去資料庫讀，寫資料庫，然後再去更新memcached，在這個過程發現邏輯複雜度比較高。

如果你的應用數據的粒度劃分足夠細，並且配合良好的ORM層對象緩存，那麼沒有任何邏輯複雜度，代碼根本不需要涉及這些部分，都是ORM層緩存自動處理掉了。

雖然個人沒用過memcached UDF，但是做過簡單的評估，主要有以下幾點覺得不適用於production。

1. 增加了Memcached和MySQL之間的耦合性。

試想如果UDF指向的memcached掛了，trigger方式調用的UDF是不會接收到報錯返回的，程序段自然也無法做相應處理。

2. 增加了MySQL的伺服器壓力。

MySQL本身就是一個對伺服器性能要求較高的DBMS，原本簡單的App &<--&> Memcached，現在變成了 App &<---&> MySQL &<---&> Memcached ，無形中增加了MySQL不必要的轉發壓力（網路，CPU的損耗）

3. 運維困難。
某台Memcached如需升級，分離式架構只需要修改APP配置文件。而UDF的方案就需要修改相應的trigger，trigger是很難進行版本控制和批量下發管理的，無形中對運維造成了很大的困難