原生twemporxy
twemproxy支持一个proxy实例同时代理多个分布式集群（serverpools），每个集群使用不同的网络端口实现数据流的隔离，下图中port1应用于cluster1代理，port2应用于cluster2代理：
今天要介绍的是twemproxy对redis节点高可用的支持，拿上图的其中一个分布式集群进行示例，逻辑结构如下：
客户端client流入的请求，在proxy上进行路由分片，然后转发到后端的redis节点上存储或者读取。事实上，大家已经注意到后端的redis节点只有一个点，在出现异常情况下，是很容易掉线的。按twemproxy的设计，它可以自动识别失效节点并将其剔除，同时落在原来节点上的请求会分摊到其余的节点上。这是分布式缓存系统的一种通用做法，但需要忍受这个失效节点上的数据丢失，这种情况是否可以接受？
在业内，redis虽然被定位为缓存系统，但事实上，无论哪种业务场景（我们接触过的）都不愿意接受节点掉线带来的数据丢失，因为那样对他们系统的影响实在太大了，更有甚者在压力大的时候引起后端数据库被击穿的风险。所以，我们打算改造twemproxy，前后总共有几个版本，下面分享给各位的是我们目前线上在跑的版本。
定制化改造
在上图的基础上，我们增加了与manager交互的模块、增加了与sentinel（redis-sentinel）交互的模块，修改了redis连接管理模块，图中三个红色虚线框所示：
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的内部处理逻辑，制作了如下消息流图：
绿色为业务通道，用于透传业务层数据；
紫色为命令通道（红线的细化），用于初始化和节点主从切换：
箭头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粘包）进行拆分，拷贝是无法避免的，但是有优化空间；