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

    這是我在知乎上拋出的一個問題"咱們的應用已經決定採mysql+memcached 的方式,針對的數據庫版本是 mysql 5.1,目前已經進行了半個月的編碼實現:
    1.採用的是 」memcached 和mysql 獨立的實現方式,在編碼層控制讀 memcached,找不到再去數據庫讀,寫數據庫,而後再去更新 memcached,在這個過程發現邏輯複雜度比較高。
    2.如今發現 「Using the MySQL memcached User-Defined Functions」 的實現方式,是經過觸發器解決以上覆雜邏輯的,從個人感受上來看,應該是下降了代碼複雜度。
    我想諸位老師幫助我從理論上分析一下這兩種方式的利弊,固然最好從實戰角度分析二者的利弊,或者二者在使用上有什麼值得注意之處,哪一種更好,謝謝"

各位老師的回答以下:
1.建議在應用層直接處理,而不要使用MySQL memcached User-Defined Functions


盧鈞軼,MySQL DBA
雖然我的沒用過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是很難進行版本控制和批量下發管理的,無形中對運維形成了很大的困難


結合這位老師的思路通過本身的進一步考察,單單對於第一點,我以爲就能夠拋棄使用memcached UDF了,做爲一個爲上萬客戶提供服務的後臺程序,容錯,單點故障是必需要考慮並處理的,若是沒法準確知道錯誤的發生,就很難迅速進行補救;

2.給出在應用層簡化處理memcached邏輯的思路


範凱,互聯網創業者,JavaEye網站創始人
>>在編碼層控制讀memcached,找不到再去數據庫讀,寫數據庫,而後再去更新memcached,在這個過程發現邏輯複雜度比較高。
若是你的應用數據的粒度劃分足夠細,而且配合良好的ORM層對象緩存,那麼沒有任何邏輯複雜度,代碼根本不須要涉及這些部分,都是ORM層緩存自動處理掉了。


通過個人進一步考察,相關的ORM框架有基於java的,C#的,因爲咱們的項目是使用C++語言實現,目前我尚未找到與之對應的相關ORM框架。

3.給出在應用層作memcached和mysql結合的使用建議


曹政
我喜歡在應用層作,沒以爲邏輯複雜在哪裏。
幾個要點
1:memcache和mysql的連接時間,若是兩個連接同時開啓,先開啓的會影響後開啓的,好比memcache先開啓連接,而後開啓mysql,如memcache阻塞,程序未及時釋放,會連帶致使mysql崩潰,這種狀況之前遇到過,記住連接必須加超時限制,防止連帶阻塞現象。或者,釋放memcache鏈接後,再開啓mysql連接(這樣不利於程序封裝)
2:memcache命中率如不高,不如不用。作memcache應用後,第一件事情是測試命中率狀況,不能認爲加了緩存就必定能夠提升效率。
3:若是數據塊較大,放在memcache中讀取的效率或許不如mysql。
4:隨時監控swap分區佔用狀況,確保內存使用合理。
5:memcached適合簡單的key-value查詢,若是涉及結構性內容,或者排名類應用,建議使用redis.
相關文章
相關標籤/搜索