首先谈几个名词： 协议设计 、IO阻塞与非阻塞、业务阻塞与非阻塞、协议处理吞吐量
首先，IO的阻塞与非阻塞其实和协议的设计没有任何关系，任何协议，包括HTTP协议其实都可以设计为IO阻塞模型和非阻塞模型，比如传统的servlet模型就是IO阻塞模型，如果抛弃servlet，用NIO的多路复用完全可以实现一个IO非阻塞的HTTP协议模型。
业务的阻塞非阻塞指的是业务层面上是不是需要用户等待结果的产生。
本篇，我要强调的是：
协议的设计和协议处理的吞吐量有必然的联系！（换种哲学思路来说：协议的设计和业务阻塞有必然关系！）
协议的设计有哪些方面呢？
1 协议的封包设计，即协议的格式，主要是包头设计，可以包括请求包格式和响应包格式
2 协议的时序，即在同一个TCP连接上，请求和响应的时序通常有两种设计：
# 请求发出的顺序必须和请求响应的顺序严格一致，即先发出的请求，必须先得到响应的时序模型，典型的协议是HTTP1.x
# 响应的顺序不要求和请求顺序一致，即，先发出的请求可以后得到响应，后发出的请求可以先得到响应，典型的协议是MQ协议
吞吐量指的啥？
吞吐量指的是服务端甚至客户端单位时间内处理协议包的数量多少，单位时间内处理的协议包越多，吞吐量越高。
下面都是以服务端吞吐量做的说明：
对于上面1中提到的协议时序，由于在同一个连接上，要求首先到达的请求必须首先响应，但是由于不同请求对应的业务处理不一样，服务端处理每个请求后发出响应的时间是不确定的，假设同一个连接上接到的多个请求都同时交给业务端线程群去处理，很有可能发生后处理的请求先响应导致协议时序出错，所以我们程序是无法避免这种情况发生的（不管业务端采用单线程模型还是多线程模型），为了保证协议时序的正确，我们程序只能设计为在同一个连接上处理完一个请求，并且该请求完全响应完毕后，才能处理下一个请求，这里就导致了吞吐量的下降！为了提高吞吐量，我们必须采用多开连接的方式！
对于上面2中提到的时序，由于不要求先到的请求先响应，我们完全可以在一个连接上不停的接请求，业务端线程群有响应就写出去，对于有请求响应模型的业务需求，我们可以在设计协议格式的时候，给每个协议包带上一个会话ID来识别请求和响应，业务的时序由业务层保证（通过会话ID关联请求和响应），这种设计方式的特点是：业务时序和协议时序分离，保证了协议的高吞吐量处理。通过这种协议的设计，单连接上的吞吐量大大提高！
总结：
对于吞吐量的提高，任何系统，大部分情况下，排队都要比加资源好！因为资源是有限的，通过加资源设计出的系统是不可以伸缩的 ！排队虽然也会影响业务处理时间或者说用户体验，但是不会导致因为资源不足导致的服务长时间不可用或者系统崩溃！
（完）
