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

1. 开发背景

现有开源缓存代理中间件有twemproxy、codis等，其中twemproxy为单进程单线程模型，只支持memcache单机版和redis单机版，都不支持集群版功能。

由于twemproxy无法利用多核特性，因此性能低下，短连接QPS大约为3W，长连接QPS大约为13W，同时某些场景时延抖动厉害。

为了适应公有云平台上业务方的高并发需求，因此决定借助于twemproxy来做二次开发，把nginx的高性能、高可靠、高并发机制引入到twemproxy中，通过master+多worker进程来实现七层转发功能。

2 Twemproxy

2.1 Twemproxy简介

Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII协议和更新的Redis协议。它全部用C写成，使用Apache 2.0 License授权。支持以下特性：

i)速度快

ii)轻量级

iii)维护持久的服务器连接

iiii)启用请求和响应的管道

iiiii)支持代理到多个后端缓存服务器

iiiii)同时支持多个服务器池

iiiiii)多个服务器自动分享数据

iiiiiii)可同时连接后端多个缓存集群

iiiiiiii)实现了完整的 memcached ascii 和 redis 协议.

iiiiiiiii)服务器池配置简单，通过一个 YAML 文件即可

iiiiiiiiii)一致性hash

iiiiiiiiii)详细的监控统计信息

iiiiiiiiiii)支持 Linux, *BSD, OS X and Solaris (SmartOS)

iiiiiiiiiiii)支持设置HashTag

iiiiiiiiiiiiiii)连接复用，内存复用，提高效率

2.2 memcache缓存集群拓扑结构

图1 twemproxy缓存集群拓扑图

如上图所示，实际应用中业务程序通过轮询不同的twemproxy来提高qps，同时实现负载均衡。

说明:官方memcache没有集群版和持久化功能，集群版和持久化功能由我们自己内部开发完成。

2.3 推特原生twemproxy瓶颈

如今twemproxy凭借其高性能的优势, 在很多互联网公司得到了广泛的应用，已经占据了其不可动摇的地位, 然而在实际的生产环境中, 存在以下缺陷，如下：

i)单进程单线程, 无法充分发挥服务器多核cpu的性能

ii)当twemproxy qps短连接达到8000后，消耗cpu超过70%，时延陡增。

iii)大流量下造成IO阻塞，无法处理更多请求，qps上不去，业务时延飙升

iiii)维护成本高，如果想要充分发挥服务器的所有资源包括cpu、 网络io等，就必须建立多个twemproxy实例，，维护成本高

iiiii)扩容、升级不便

原生twemproxy进程呈现了下图现象：一个人干活，多个人围观。多核服务器只有一个cpu在工作，资源没有得到充分利用。

3. Nginx

nginx是俄罗斯软件工程师Igor Sysoev开发的免费开源web服务器软件，聚焦于高性能，高并发和低内存消耗问题，因此成为业界公认的高性能服务器，并逐渐成为业内主流的web服务器。主要特点有：

i)完全借助epoll机制实现异步操作，避免阻塞。

ii)重复利用现有服务器的多核资源。

iii)充分利用CPU 亲和性(affinity)，把每个进程与固定CPU绑定在一起，给定的 CPU 上尽量长时间地运行而不被迁移到其他处理器的倾向性，减少进程调度开销。

iiii)请求响应快

iiiii)支持模块化开发，扩展性好

iiiii)Master+多worker进程方式，确保worker进程可靠工作。当worker进程出错时，可以快速拉起新的worker子进程来提供服务。

iiiiii)内存池、连接池等细节设计保障低内存消耗。

iiiiii)热部署支持，master与worker进程分离设计模式，使其具有热部署功能。

iiiiiii)升级方便，升级过程不会对业务造成任何伤害。

Nginx多进程提供服务过程如下图所示：

4 Nginx master+worker多进程机制在twemproxy中的应用

4.1 为什么选择nginx多进程机制做为参考?

Twemproxy和nginx都属于网络io密集型应用，都属于七层转发应用，时延要求较高，应用场景基本相同。

Nginx充分利用了多核cpu资源，性能好，时延低。

4.2 Master-worker多进程机制原理

Master-worker进程机制采用一个master进程来管理多个worker进程。每一个worker进程都是繁忙的，它们在真正地提供服务，master进程则很“清闲”，只负责监控管理worker进程, 包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

worker进程负责处理客户端的网络请求，多个worker进程同时处理来自客户端的不同请求，worker进程数可配置。

4.3 多进程关键性能问题点

master-worker多进程模式需要解决的问题主要有：

i)linux内核低版本(2.6以下版本), “惊群”问题

ii) linux内核低版本(2.6以下版本),负载均衡问题

iii)linux内核高版本(3.9以上版本)新特性如何利用

iii)如何确保进程见高可靠通信

iiii)如何减少worker进程在不同cpu切换的开销

iiiii)master进程如何汇总各个工作进程的监控数据

iiiiii)worker进程异常，如何快速恢复

4.3.1 linux内核低版本关键技术问题

由于linux低内核版本缺陷，因此存在”惊群”、负载不均问题，解决办法完全依赖应用层代码保障。

4.3.1.1 如何解决“惊群”问题

当客户端发起连接后，由于所有的worker子进程都监听着同一个端口，内核协议栈在检测到客户端连接后，会激活所有休眠的worker子进程，最终只会有一个子进程成功建立新连接，其他子进程都会accept失败。

Accept失败的子进程是不应该被内核唤醒的，因为它们被唤醒的操作是多余的，占用本不应该被占用的系统资源，引起不必要的进程上下文切换，增加了系统开销，同时也影响了客户端连接的时延。

“惊群”问题是多个子进程同时监听同一个端口引起的，因此解决的方法是同一时刻只让一个子进程监听服务器端口，这样新连接事件只会唤醒唯一正在监听端口的子进程。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!