https://v.qq.com/x/page/v0503qz6fdw.html
同步模型
以前在并发量很低的情况下，是通过线程去收取数据并发送数据给客户端。但是当并发量和客户端连接数比较高的时候，服务器会出现明显的瓶颈。
阻塞模型比较符合人的思考逻辑，但它会有线程阻塞的问题。阻塞模型会让出CPU，不适用于高并发。
线程池或连接池只能解决一部分问题。因为线程池和连接池的本质作用并不是能直接提高QPS，而是减少或销毁线程的连接处以及开销。
我们平时调用阻塞API的一个问题就在于单机的线程数是有限的。所以如果要提高服务端性能的话，首先就要去阻塞。
异步模型异步阻塞模型处理I/O时大部分时间是非阻塞的（监听时除外），它调用的API会立即返回，这点是需要注意的。此外，处理结果的程序并不保证调用API当前的线程，这点在处理线程安全的问题上尤其要注意。
Java中很多API都是基于操作系统底层API的模型，并没有做更高层次的封装。
Java把一层阻塞异部I/O做了封装，这些就是Java或C语言异步模型的基石。
少数线程等待事件发生，再根据对应类型处理相关事件。
最近“协程”这个词比较火，看上去能解决异步模型的大部分问题。它是一个轻量级线程，可以直接当作线程来用。还能阻塞I/O API，阻塞的是协程而非线程。
协程是用户态资源，用户态调度，消耗极低，可以启动数十万个协程。
它的实现和线程不是1对1 的关系，难点在于编程语言的内部实现。
Python虽然支持协程，但是由于全局解释锁的关系，同一时刻只有单个CPU在运行。所以python选择多进程+协程的做法。
Go语言完美解决了支持不阻塞线程的I/O操作，并支持多线程。
要能像同步I/O一样编写代码，不会创造过多数量的线程。尽量让CPU处于忙碌状态而非等待，并寻找满足以上条件的Java库。但是Java由于本身语言的问题，即使是Java协程三方库也只能部分支持协程。
退而求其次，我们只能使用Java异步工具库。如果要提高并发量，可以使用异步JDBC和异步HTTP CLIENT，这个库基于NETTY。
做到服务异步化，要查看接口是否可支持异步。还可以使用Java的异步工具库，比如Java的异步数据访问方式和异步HTTP CLIENT。如果使用的是三方框架，可以修改调用方式，有的框架支持异步回调和事件监听。最重要的是要注意线程安全问题。
异步化的优势就是极大提高了I/O密集型业务的性能，保守估计有10~100倍，也就解决了线程数创建过多的问题。
而它的缺点是增加了编程难度，包括状态保存、回调处理以及线程安全等。也存在压垮下游服务的问题：)
Netty是基于原生的异步模型，封装并优化。它修复JDK中的一些BUG，提供了多种辅助类方便开发。编程模型高效简单，开发者只需关心具体实现逻辑即可，基本不用花精力做Java网络层面的优化。此外，Netty成熟稳定，业界使用多，我们能够相信，使用它不会遇到难以解决的大问题。
Netty基于事件连接，如果有数据传入以及连接上有异常事件或自定义事件，只需复写它的回调函数就能做相应的处理。
Netty所有I/O API全都是消除阻塞异步化。线程模式也非常好，它单个连接上的所有I/O事件都由同一个线程执行，避免了线程安全问题。
Netty的单个链接绑定一个线程，EVENTLOOP即一个线程，EVENTLOOPGROUP是一个线程组。
Netty任何的I/O API都是产生一个任务，放入该连接对应的线程里执行，做到局部串行化。
Netty一切操作都是以事件驱动来执行，所有I/O API都是用异步+回调监听的方式来处理消息。单一的连接处理都在一个线程里，来避免线程安全问题。
案例-饿了么数据库中间件
我们是一个实现了MYSQL协议的中间代理服务。上游至少要支持上万客户端的连接，下游要支持上千数据库连接。
为了快速实现功能，我们最早是找了一个基于GITHUB阻塞I/O开源库，首要任务是把同步改为了异步。
线程模型的上下游各有Netty的一个线程组，中间件内部还有一个处理业务的线程组。
但有一个最本质的问题在于这三个线程组之间的线程安全得不到保证。
因为这个中间件前后端都是异步的，所以按正常流程是由协议来保证顺序执行，而异常中断是并发执行的。
参考Netty，我们把每一个连接绑定到一个单线程池，保证Task串行执行。
前后端异步的好处在于模型简单，便于后续修改。
我个人认为，在程序里过多的使用WAIT/NOTIFY/LOCK不一定代表良好的多线程编程能力，却可能代表这是不够优雅的设计。
除了前后端异步和信号量控制异步，在中间件中我们还用到了日志异步、心跳异步、JOB异步和配置变更异步。
在饿了么数据库中间件开发过程中，异步化所有API以去除阻塞，局部串行化解决线程安全问题，模型简单，易于修改和理解。
