Redis 3.0.0 stable發布了，最引入注目的特性可能就是cluster了。
對很多早已使用Twemproxy的項目，這個特性有什麼特殊意義嗎? 或者說，Redis cluster相比Twemproxy有什麼優勢?
学习是最好的投资！
都是Redis分散式叢集的解決方案，中午透過微信剛看到一篇InfoQ推送的文章-《高效運維最佳實踐（03）：Redis集群技術與Codis實踐》，講的還比較細，有針對性，裡面提高了Redis Cluster比較“重”，又提出了twemproxy的不足之處。可惜InfoQ網站上並未發現這篇文章，不知道是不是沒有及時更新的緣故，所以無法貼出鏈接，可以去關注下。
說下twemproxy的幾個問題,就知道redis cluster的優勢了
(1)全非同步實現,理解起來比較複雜 (2)坑爹的auto_eject_hosts (3)不支援動態添加server (4)mget 會自動拆分,影響效能
redis cluster透過客戶端和服務端, 服務端和服務端的通訊,更新客戶端的節點路由規則,保證客戶端的請求總發往正確的服務端節點.絕大多數情況下,客戶端到服務端只需要一次通信.
而Twemproxy作為代理分發請求到節點,中間多了層通訊.
從理論上.redis cluster性能高效.當然實現更為複雜的多,還需要實踐檢驗.
個人覺得redis cluster的方式是未來的主流.
都是Redis分散式叢集的解決方案，中午透過微信剛看到一篇InfoQ推送的文章-《高效運維最佳實踐（03）：Redis集群技術與Codis實踐》，講的還比較細，有針對性，裡面提高了Redis Cluster比較“重”，又提出了twemproxy的不足之處。可惜InfoQ網站上並未發現這篇文章，不知道是不是沒有及時更新的緣故，所以無法貼出鏈接，可以去關注下。
說下twemproxy的幾個問題,就知道redis cluster的優勢了
(1)全非同步實現,理解起來比較複雜
(2)坑爹的auto_eject_hosts
(3)不支援動態添加server
(4)mget 會自動拆分,影響效能
redis cluster透過客戶端和服務端, 服務端和服務端的通訊,更新客戶端的節點路由規則,保證客戶端的請求總發往正確的服務端節點.絕大多數情況下,客戶端到服務端只需要一次通信.
而Twemproxy作為代理分發請求到節點,中間多了層通訊.
從理論上.redis cluster性能高效.
當然實現更為複雜的多,還需要實踐檢驗.
個人覺得redis cluster的方式是未來的主流.