Nginx多进程高并发、低时延、高可靠机制在缓存twemproxy代理中的应用
1. 开发背景现有开源缓存代理中间件有twemproxy、codis等,其中twemproxy为单进程单线程模型,只支持memcache单机版和redis单机版,都不支持集群版功能。 由于twemproxy无法利用多核特性,因此性能低下,短连接QPS大约为3W,长连接QPS大约为13W,同时某些场景时延抖动厉害。 为了适应公有云平台上业务方的高并发需求,因此决定借助于twemproxy来做二次开发,把nginx的高性能、高可靠、高并发机制引入到twemproxy中,通过master+多worker进程来实现七层转发功能。 2 Twemproxy2.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. Nginxnginx是俄罗斯软件工程师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失败的子进程是不应该被内核唤醒的,因为它们被唤醒的操作是多余的,占用本不应该被占用的系统资源,引起不必要的进程上下文切换,增加了系统开销,同时也影响了客户端连接的时延。 “惊群”问题是多个子进程同时监听同一个端口引起的,因此解决的方法是同一时刻只让一个子进程监听服务器端口,这样新连接事件只会唤醒唯一正在监听端口的子进程。 (编辑:ASP站长网) |