版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zg_hover/article/details/85112303
概述
本文描述twemproxy0.4的消息处理机制的概览。
twemproxy0.4会通过FIFO（先进先出）队列的方式来对消息进行排队。本文先介绍一个消息处理的概要框架，后续会详细讲解该消息框架的实现。
消息处理框架总述
在创建后台网络服务程序时，后台服务的个数是有限的。而来自客户端的请求可能是无限的，但我们需要尽可能的满足客户端的请求，让客户端的体验不至于太差。这样我们就需要对客户端的请求进行控制。
twemproxy0.4中在处理消息时会使用两个FIFO(first in first out)个队列，一个输出队列，一个输入队列来实现对消息的控制。如下图所示：
- 消息输入队列：接收到的请求会放入到消息输入队列中。
- 消息输出队列：输出的请求会放到消息输出队列中。
从客户端连接接收到的请求，会放到服务端的消息输入连接请求队列中，该队列被称为：in_q。一旦消息被转发，从客户端的角度来看，它是未完成的并且在客户端的out_q中被跟踪（除非请求被标记为noreply）。
服务器依次从它自己的in_q中获取请求，并处理它们上。一旦请求的处理未完成，并且请求希望得到期望的消息回复，服务器就会在其自己的out_q中跟踪未完成的请求。
在服务器端，out_q让请求与响应能够配对，在客户端out_q能够让客户端接收请求的顺序和响应配对。
实例分析
*
* Clients Servers
* .
* in_q: <empty> .
* out_q: req11 -> req12 . in_q: req22
* (client1) . out_q: req11 -> req21 -> req12
* . (server1)
* in_q: <empty> .
* out_q: req21 -> req22 -> req23 .
* (client2) .
* . in_q: req23
* . out_q: <empty>
* . (server2)
*
上面的例子写在源码中的注释中，说明如下：
- 客户端client1有两个请求：req11和req12正在和server1的连接上排队
- 客户端client2有三个请求：req21, req22和req23，其中req21正在server1的连接上排队，而req22和req23正分别等待server1和server2接收。
- 客户端out_q的fifo(先进先出性质)特性，确保在发送队列中其他已完成请求的响应之前，始终在队列头部发回请求响应。
输入和输出队列数据结构
struct conn {
...
struct msg_tqh imsg_q; /* incoming request Q */
struct msg_tqh omsg_q; /* outstanding request Q */
...
}
其中imsg_q是输入请求的队列头结构，而omsg_q是输出队列的头结构。
总结
本文从总体上介绍了twemproxy0.4的消息处理机制和实现。后面会介绍更加详细的消息处理机制。