twemproxy消息转发机制分析

twemproxy作为代理,最核心的功能就是消息的转发,特别是在高并发的环境下如何高效的进行消息的转发至关重要,根据twemproxy官方的测试结果号称单点40w并发,在实际生产环境中,很多关键因素的影响远没有达到官方的性能,主要的因素: twemproxy本身的配置:后端连接数,mbuf的块大小,还有twemproxy本身所能利用的机器资源的性能,还有最重要的一点是后端存储的响应能力,如果后端拖后腿了,可能会导致twemproxy的任务积压,又因为twemproxy在内存管理上有一个问题就是它不会释放内存,除非准备停掉本次服务了,我们就曾出现过,因为后端存储节点的问题,导致twenproxy内存从常规110MB在1分钟内迅速飙升至17GB,最后不得不重启twemproxy,在测试的时候哦发现如果后端存储节点的压力大的话,本身的能力上不去会影响twemproxy的性能结果且twemproxy的内存并没有上涨,CPU利用率也不高,为什么呢?,twemproxy的消息转发不是基于事件的吗,哦,这个还是因为测试情景并不能完全等同于线上真实的并发,因为在测试上,使用了redis-benchmarck的程序,原理是通过批量发送请求测试的,那所开的任务数量是有限的,我们使用了50个线程,在每个线程中,请求是同步阻塞的,所以会出现twemproxy性能上的奇怪现象,改进的方法就是改在测试程序为同步非阻塞的,或者搭建集群测试环境,那twemproxy是如何在高并发的环境下漂亮的完成消息的转发的呢它在这个转发的过程中又有哪些亮点呢? 先看个模型:

上图一目了然,简单的描述就是:

1.client和twemproxy建立连接,我们称为client_conn

2.client发起请求,twemproxy读取数据,生成req_msg,并设置该消息的owner为client_conn, 这个owner让使用该消息的任何环节找到它所属的连接,这个是zero copy的关键因素之一

3.proxy根据配置的distribution策略选择存活的后端节点(我们使用了hashslot算法,具体的请看后端存储server的选取策略)

4.与选择的后端节点建立连接(可能已经建立连接),我们称为server_conn

5.转发req_msg:将req_msg指针放入client_conn的out_que(消息输出)队( req_msg => client_conn.outputq)列,同时放入server_conn的in_que(消息接入)队列(req_msg => server_conn.inputq)

6.触发server_conn的写事件

7.通过server_conn的写回调接口从自己的server_conn的in_que队列中拿取req_msg发送到后端节点(server_conn.inputq => req_msg)

8.将req_msg放入server_conn的out_que队列(req_msg => server_conn.outputq)

9.当req_msg的rsp_msg出现后,调用rsp_filter进行消息过滤,rsp_forward将消息从server_conn的out_que中取出来( server_conn.outputq => req_msg)

10.建立rsp_msg和req_msg的关联,通过messag的peer字段

11.通过req_msg的owner找到client_conn,触发它的写事件

12.client_conn从out_que中取出req_msg(client_conn.outputq => req_msg)

13.通过req_msg的peer找到rsp_msg并发送出去

END....

转载于:https://juejin.im/post/5bef615de51d45773720207f