Nginx多进程高并发、低时延、高可靠机制在缓存twemproxy代理中的应用(4)

原生twemproxy节点机器上的时延分布:

 

另一个改造后的twemproxy节点机器上的时延分布：

总结：替换线上两个proxy中的一个后，客户端时间降低了一倍，如果线上集群两个代理都替换为改造后的twemproxy，客户端监控时延预计会再降低一倍，总体时延降低3倍左右。

此外，从监控可以看出，改造后的twemproxy时延更低，更加稳定，无任何波动。

6.2 参考nginx多进程改造后的twemproxy线下压测结果(开启reuseport功能)

监听同一个端口，数据长度100字节，压测结果如下：

linux内核版本:linux-3.10

物理机机型： M10(48 cpu)

多进程监听同一个端口，数据长度150字节，压测结果如下：

linux内核版本:linux-3.10

物理机机型： TS60 (24 cpu)

7 总结

7.1 多进程、多线程机制选择

选择参照nginx多进程机制，而不选择多线程实现原因主要有:

1) 多进程机制无锁操作，实现更容易

2) 多进程的代理，整个worker进程无任何锁操作，性能更好

3) 如果是多线程方式，如果代码出现bug段错误，则整个进程挂掉，整个服务不可用。而如果是多进程方式，因为bug触发某个worker进程段错误异常，其他工作进程不会受到如何影响，20个worker进程，如果触发异常，同一时刻只有有1/20的流量受到影响。而如果是多线程模式，则100%的流量会受到影响。

4) worker进程异常退出后，master进程立马感知拉起一个新进程提供服务，可靠性更高。

5) 配置热加载、程序热升级功能实现更加容易

7.2 参照nginx改造后的twemproxy特性

支持nginx几乎所有的优秀特性，同时也根据自己实际情况新增加了自有特性:

1) master+多worker进程机制

2) 适配所有linux内核版本，内核低版本惊群问题避免支持

3) quic_ack支持

4) reuser_port适配支持

5) worker进程异常，master进程自动拉起功能支持

6) 90%、95%、98%、100%平均时延统计功能支持

7) memcache单机版、集群版支持

8) redis单机版、集群版支持

9) 二进制协议、文本协议同时支持

10) redis、memcache集群在线扩容、缩容、数据迁移支持，扩缩容、数据迁移过程对业务无任何影响。

11) 多租户支持，一个代理可以接多个memcache、redis集群，并支持混部。

12) mget、gets、sets等批量处理命令优化处理

13) 慢响应日志记录功能支持

14) 内存参数实时修改支持

15) 详细的集群监控统计功能

16) CPU亲缘性自添加

17)内存配置动态实时修改

7.3后期计划

添加如下功能:

i) 配置文件热加载支持。

ii) 代码热升级功能支持。

7.4 长远规划展望

抽象出一款类似nginx的高性能代理软件，nginx支持http协议，我们的支持tcp协议代理，覆盖nginx所有功能，包括前面提到的所有功能，同时支持模块化开发。这样，很多的tcp协议代理就无需关心网络架构底层实现，只需要根据需要开发对应的协议解析模块，和自己关心的统计、审计等功能功能，降低开发成本。现有开源的中间件，很大一部分都是tcp的，有自己的私有tcp协议，把这个抽象出来，开发成本会更低 。

【编辑推荐】

1. Redis存储总用String？你大概错过了更优的使用方法
2. Redis实现分布式锁的正确姿势
3. 一文揭秘单线程的Redis为什么这么快?
4. 面试前必须要知道的Redis面试
5. 深入了解一下Redis的内存模型！

（编辑：ASP站长网）