核心原理就是协程+epoll事件循环，再使用协程之后，开销是特别的小，那具体如何提供高并发的呢？
异步非阻塞IO
这意味我们整套开发的模式不在与原来一样，正因为不再一样，所以有时我们在理解代码时就有可能会比较困难。之前我们是报耗时的操作交给了系统去调度，也就降低了我们的使用难度，因为如果让我们程序去调度是比较困难的。但协程系统是控制不了，所以说就需要程序员来做，一般是由框架完成，就比如说asyncio。所以说我需要了解的他的原理。不然出了问题，不好调整
基于epoll事件循环
底层是基于事件循环的，从线程到协程到高并发，实际是功能上就是个事件循环。
即使是nginx实现并发也是使用的epoll(Linux)的事件循环，所以推荐使用时，使用linux系统，那样才能充分体现性能。
协程提高了代码的可读性
对于实现协程的肯定一步步从无到有的，慢慢技术的迭代。之前写协程还要写回调，调试还是比叫恶心的。
后来慢慢改善成写成类似同步的代码那样实现异步。但即使这样它的还是提高了难度
Tornado提供的不只是web框架
异步编码的一整套方案,包含了框架与，也提供了事件循环的功能，也就是服务器功能，在部署时也可以直接部署。
使用了Tornado不一定就是高并发
如果在代码中使用了同步的IO后，效果也是比较低，甚至会比Flask与Django还要低。所以在使用Tornado时，我们需要了解什么是事件循环什么是协程。事件循环的模式是单线程完成的，那就意外着，有一个地方使用了同步IO操作，那整个所有消息都会被堵塞住。
Tornado中尽量不要使用的同步IO
根据什么之前说的，我们再使用Tornado时，尽量不要使用同步IO，这也就是有的小伙伴在测试Tornado时发现效率没有Flask、Django高的主要原因。
甚至有的小伙伴都不清楚什么样的操作是异步的，什么样的操作是同步的。所以以后我们在使用时，要多加注意
Tronado只需要把耗时的操作放到线程池中就可以达到高并发？？
这个也是不对的。在实际写代码时，遇到耗时比较多，也或者使用别人的库耗时比较多。
他们放到线程池中能否提高效率取决于是否是异步的。如果不是异步只能考虑换库，或者自己写一个。
