UDN-企业互联网技术人气社区

板块导航

浏览  : 1365
回复  : 0

[讨论交流] 支持redis节点高可用的twemproxy

[复制链接]
杀马特的忧伤的头像 楼主
发表于 2016-4-7 09:21:54 | 显示全部楼层 |阅读模式
  来源:比特科技

  原生twemporxy

  twemproxy支持一个proxy实例同时代理多个分布式集群(serverpools),每个集群使用不同的网络端口实现数据流的隔离,下图中port1应用于cluster1代理,port2应用于cluster2代理:

eb22c4db-c3f7-42dd-8852-e286c5634027.png


  今天要介绍的是twemproxy对redis节点高可用的支持,拿上图的其中一个分布式集群进行示例,逻辑结构如下:

29aa5983-b9d0-4493-bfbc-d7fe3d90e789.png


  客户端client流入的请求,在proxy上进行路由分片,然后转发到后端的redis节点上存储或者读取。事实上,大家已经注意到后端的redis节点只有一个点,在出现异常情况下,是很容易掉线的。按twemproxy的设计,它可以自动识别失效节点并将其剔除,同时落在原来节点上的请求会分摊到其余的节点上。这是分布式缓存系统的一种通用做法,但需要忍受这个失效节点上的数据丢失,这种情况是否可以接受?

  在业内,redis虽然被定位为缓存系统,但事实上,无论哪种业务场景(我们接触过的)都不愿意接受节点掉线带来的数据丢失,因为那样对他们系统的影响实在太大了,更有甚者在压力大的时候引起后端数据库被击穿的风险。所以,我们打算改造twemproxy,前后总共有几个版本,下面分享给各位的是我们目前线上在跑的版本。

  定制化改造

  在上图的基础上,我们增加了与manager交互的模块、增加了与sentinel(redis-sentinel)交互的模块,修改了redis连接管理模块,图中三个红色虚线框所示:

7208e2f0-59c0-453f-8b15-8aac66eddd15.png


  manager交互模块

  增加连接manager的客户端交互模块,用于发送心跳消息,从心跳应答包里获取group名称列表和sentinel列表(IP/PORT信息),即整个分布式集群的配置信息,其中心跳消息带有版本信息,发送间隔可配置。

  sentinel交互模块

  增加与sentinel客户端交互模块(IP/PORT信息来自于manager),发送group名称给sentinel获取redis主节点的IP/PORT信息,一个group对应一个主节点。取到所有主节点后,订阅主从切换频道,获取切换消息用于触发proxy和主节点间的连接切换。这里需要解析sentinel的响应消息,会比较繁琐一些。当proxy开始与sentinel节点的交互过程,需要启动定时器,用以控制交互结果,当定时器超时交互未结束(或者proxy未正常工作),proxy将主动切换到下一个sentinel节点,并启动新的交互过程。考虑到proxy与sentinel之间网络连接的重要性(连接假死,proxy收不到主从切换消息,不能正常切换),增加了定时心跳机制,确保这条TCP链路的可用性。

  redis连接管理模块

  原先redis节点的IP/PORT信息来自于静态配置文件,是固定的,而改造以后这些信息是从sentinel节点获取。为了确保获取到的IP/PORT信息的准确性,需要向IP/PORT对应的节点验证是否是主节点的逻辑,只有返回确认是主节点,才认为是合法的。整个过程,按官方指导实现,不存在漏洞。

  详细消息流

  为了清晰的描述proxy的内部处理逻辑,制作了如下消息流图:

d57f0c99-db85-41a2-835f-d55096f77a69.png


  绿色为业务通道,用于透传业务层数据;

  紫色为命令通道(红线的细化),用于初始化和节点主从切换:

  箭头1:managerheartbeatreq;

  箭头2:managerheartbeatrsp;

  箭头3:sentinelget-master-addr-by-namereq;

  箭头4:sentinelget-master-addr-by-namersp;

  箭头5:redisauth&rolereq;

  箭头6:redisauth&rolersp;

  箭头7:sentinelpsubscribe+switch-masterreq;

  箭头8:sentinelpsubscribe+switch-masterrsp;

  箭头9:sentinelpmessage;

  命令通道命令顺序按数字1-8进行,7/8是proxy与sentinel的心跳消息,9是主从切换消息;

  高可用影响面分析

  在sentinel节点切换的过程中,存在proxy正在对外提供业务服务的状态,这时候正在处理的数据将继续处理,不会受到影响,而新接入的客户端连接将会被拒绝,已有的客户端连接上的新的业务请求数据也会被拒绝。sentinel节点切换,对系统的影响是毫秒级别,前面的设计对业务系统来讲会显得比较友好、不那么粗鲁;

  而redis节点的主从切换对系统的影响,主要集中在proxy发现主节点异常到sentinel集群做出主从切换这个过程,这段时间内落在该节点上的业务都将失败,而该时间段的长度主要依赖在sentinel节点上的down-after-milliseconds配置字段;

  经验总结

  作为代理中间件,支持pipeline的能力有限,容易产生消息积压,导致客户端大量超时,所以慎用pipeline功能;

  高负荷下容易吃内存,structmsg和structmbuf对象会被大量缓存在进程内(内存池化);

  zerocopy,对于多个连续请求(TCP粘包)进行拆分,拷贝是无法避免的,但是有优化空间;

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部