由于原先的appserver功能不斷增多，最近又增了兩個功能，需要不斷從后端memcached中提取數(shù)據(jù)并進行計算，由于提取數(shù)據(jù)量大且頻繁，導(dǎo)致效率很低，粗測了一下，獲取數(shù)據(jù)和格式化等操作花了90%以上的時間，由此設(shè)想將memcached改寫或重寫一個支持memcached的服務(wù)器，將計算功能和memcached做到一起，讓獲取數(shù)據(jù)的路徑最短，也就最大限度減少了數(shù)據(jù)傳輸和格式化等操作，就是類似存儲過程一樣啦，這部分可以考慮使用插件來實現(xiàn)，甚至可考慮使用腳本語言來實現(xiàn)。
網(wǎng)上搜了一下，果然發(fā)現(xiàn)早有人這么干了，正所謂英雄所見啊，呵呵。具體方法倒很多，自定義key命名，根據(jù)特殊key在get、set、replace上做特殊操作，或者根據(jù)命令中的flag等做特殊處理，或者擴充stat命令等，都是可以的，我們暫時就考慮修改特殊的鍵值做特殊處理。
要做一個完備的既支持ascii命令又支持binary命令的兼容memcached還是有一點點麻煩的，我暫時也沒有太多需求，所以就僅支持了ascii命令，其實也是考慮支持ascii的客戶端更多，各種語言的支持mc的客戶端數(shù)不勝數(shù)，但大多只支持ascii命令。由于我之前為了測試服務(wù)器框架效率，做過一個支持ascii命令的memcached兼容版本，因此拿過來直接使用太方便了，這個版本的實現(xiàn)其實很容易，如果有一個較好的框架代碼的話基本上在一天之內(nèi)可做完，當(dāng)然要做到很好可能需要多花一些時間，我現(xiàn)在做的也不是特好，要完全取代memcached使用還是有些差距，主要是一些過期機制等沒完全實現(xiàn)，雖然速度上比標準mc版本還要快一點，呵呵，因為暫時的確是不需要這些過期機制，所以也沒打算這個版本實現(xiàn)，其他功能基本上都有。
以后準備將這個memcached解碼部分作為一個單獨的解析器，和支持其他協(xié)議一樣，換上這個解析那就支持mc協(xié)議了，還是很方便的，以后有空還是要做個支持binary協(xié)議的，以便可以更高效的解決問題。
想到server能支持Memcached協(xié)議真是好啊，客戶端基本只要用個libmemcached就好了，多服務(wù)器分布，容錯，多份數(shù)據(jù)啥的都有現(xiàn)成的解決方案，只要把server做穩(wěn)定了就基本ok了，對咱這種小團隊來說再合適不過了，節(jié)省了很多開發(fā)維護成本啊，現(xiàn)在內(nèi)存這么便宜，部署幾個點實在是很easy的問題。