twemproxy集群生产总结

转载：http://mdba.cn/2016/03/30/redis-twemproxy%E9%9B%86%E7%BE%A4%E7%94%9F%E4%BA%A7%E6%80%BB%E7%BB%93/?utm_source=tuicool&utm_medium=referral

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。

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要低很多，虽然都是单进程工作模式。简单请求（请求长度<100字节），单个twemproxy节点能够达到6w的qps。 当请求长度较大时，twemproxy跑到2w的qps，进程cpu就达到了80%+。 因而对于大流量系统，需要部署几十个twemproxy节点做负载均衡。 我们的一个实时推荐集群，使用了210个twemproxy节点，支持百万以上的请求。因为单节点性能实在是很低。

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的实现）。