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的方式是未来的主流.