twemproxy集群生产总结

2017-07-26 16:53 阅读 238 views 次 评论 0 条

twemproxy最早是2014年8.14大促开始使用的,当年也是史无前例的大促活动–撒娇节。之后就开始野蛮生长历程,大规模部署。到15年12月份,这种方案不再支持上线了。
目前大约还有120个twemproxy集群(应用)在线生产,近1700个twemproxy实例(进程)。最大单个集群有210个twemproxy节点,6组lvs,240个redis节点,存储容量2T。
twemproxy架构将退出生产,将从架构、开发应用、运维三个方面进行总结。

1、生产总结
简单总结下大规模生产应用的感受:
1) twemproxy开发很简单,后端分片对开发透明。开发可以像使用单个redis一样读写twemproxy集群,除了部分redis命令不支持。
2)twemproxy架构层次多,用到的资源很多,管理起来并不是很方便。
3)不适合超大流量系统。

2、twemproxy架构

1)LVS集群:实现twemproxy的负载均衡,提高proxy的可用性和可扩张能力,使twemproxy的扩容对应用透明。

2)Twemproxy集群: 多个同构twemproxy(配置相同)同时工作,接受客户端的请求并转发请求给后端的redis。

3)Redis Master-Slave集群:redis master存储实际的数据,并处理twemproxy转发过来的数据读写请求。数据按照hash算法分布在多个redis实例上。

redis slave复制master的数据,作为数据备份。在master失效的时候,由sentinel把slave提升为master。
4)Sentinel集群:检测master主从存活状态,当redis master失效的时候,把slave提升为新master。
另外,通过调用一个notify script发送配置更改命令到每个twemproxy,twemproxy更新配置。之后的数据请求将会转发到更新后的redis master。

twemproxy-arch

3、为什么放弃twemproxy架构

3.1 单组lvs瓶颈
我们线上有2种lvs机型配置,2块千兆网卡(1Gbps)和2块万兆网卡(10Gbps)。
1) 千兆网卡存在网卡带宽有时不够用。
2)万兆网卡带宽不是问题,而pps吞吐量存在上线,约140wpps。达到140w pps时候,网卡队列绑定的cpu 100%的时间都在处理软中断。

解决方案:
1)lvs集群模式,需要交换机支持和配置。
2)使用多组lvs,前端业务绑定l不同lvs的vip,或者做dns轮询。

3.2 twemproxy节点性能瓶颈
twemproxy单节点吞吐量相比单个redis要低很多,虽然都是单进程工作模式。简单请求(请求长度

3.3 twemproxy后端redis扩容难
我们在部署的时候,分配了足够多的redis(cpu和内存)。但是业务一直在增长,总有一天满足不了需求。这个时候需要增加redis,这个时候scale-out显得特别难。
1)如果作为存储,需要迁移数据,那么需要自己开发数据迁移工具。

3.4 三层架构
lvs +twemproxy+redis三层架构,另外加上sentinel集群,整个集群很复杂。
对于codis,其实我也认为是个很复杂的系统的。组成有负载均衡节点,配置管理节点,proxy节点,redis节点。好的地方是可以在线迁移数据。

4、twemproxy替代方案
1)客户端分片。架构简单,瓶颈仅仅是redis本身。缺点是应用程序需要大量代码实现sharding逻辑,也没有HA方案。
2)redis cluster。完美的方案,但是目前各个语言的客户端实现还不够成熟(smart client的实现)。


版权声明:本文版权由木秀林网所有,转载请保留链接:twemproxy集群生产总结
分类:Redis 标签:

发表评论


表情