twemproxy集群生产总结

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要低很多,虽然都是单进程工作模式。简单请求(请求长度<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的实现)。

此条目发表在redis分类目录,贴了, 标签。将固定链接加入收藏夹。

twemproxy集群生产总结》有 5 条评论

  1. sel-fish说:

    hi,陈群,这篇博客干货很多,很赞。另外有几个问题想请教下:
    1. sentinel cluster的节点数一般配置的多少?单个sentinel cluster线上是监听多少组redis group的呢?如果监听更多组redis group,遇到过什么问题么?
    2. 对于业务量比较小的应用也是这样部署的么?如果不是,业务量比较小的应用采取的是什么方式呢?

    • sylar说:

      sentinel节点数3个以上就可以(计数个),”一个集群多少个sentinel最佳“这个问题这个我也没有答案。根据实际的sentinel的性能决定即可。
      sentinel监听的redis group,我是从方便管理角度考虑和我的架构相关的,sentinel 和 Twemproxy部署在一起,监控Twemproxy后连接的master。一般10个左右的group,100-300个(master+slave)节点不等。
      你的第二问题,是指redis么? 我的建议是不同的业务不同的redis/twemproxy集群。redis已经是schema-less,很难区分key是那个业务的。除非强制开发加上前缀,或者使用keyspace(开发繁琐),我都不认为是很好的方案(大量select)。不容的集群能隔离相互影响,也方便排查问题。

      • sel-fish说:

        1. “一般10个左右的group,100-300个(master+slave)节点不等”,这个不太理解,是说平均一组redis group会有10-30个master+slave节点?
        2. 按照官方文档,http://redis.io/topics/sentinel#consistency-under-partitions,sentinel在网络分区下会有一致性问题,导致网络故障期间的写丢失(redis cluster也会有这种情况,只是时间会控制在cluster-node-timeout内)。请问,有遇到到真实环境里面的这种情况么,或者之前有做什么相关的应对措施么?

        • sylar说:

          第二个问题: sentinel和cluster投票的需要大于一半以上的节点同意,才会产生选举。
          一致性和写丢失是两个问题,写丢失可以理解为可用性。nosql分布式系统会提到,CP和AP两个概念,一致性和可用性的抉择。
          如果系统故障了,总有故障恢复时间,哪怕是几秒时间,我们要尽量减小故障恢复时间。
          提供系统的可用时间,需要整个架构的完善。

          • sel-fish说:

            @sylar 非常感谢详细的解答,受益匪浅。
            目前生产环境使用的sentinel的配置里面,down-after-milliseconds(默认30s)和failover-timeout(默认3分钟)都是配置的什么值呢?除了down-after-milliseconds、failover-timeout、parallel-syncs,对于一个监控的redis group,还有其它参数需要注意的么?

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>