FastAPI 中的Async （并发和async/await）
引用文地址：https://fastapi.tiangolo.com/async/
前言：fastapi是一个广泛使用的高效的restful api框架，他的作者在这篇讲解框架中使用async的说明详细举例解释了异步编程、并发和并行的区别，堪称经典，于是手痒总结如下（不敢说翻译）
async使用指导：
- 如果这个请求比较慢，比如连接数据库读取数据、文件IO、rpc调用等一般加上async，我想普通项目里大部分请求都会多多少少跟数据库打交道，所以加的往往比较多；
- 比较快，稳定的使用def即可，也可以把没有上面情况调用的都按照这类处理；
- 分不清加不加就不加，放心这不是什么大的问题，我在测试中发现不加效率高一丢丢，毕竟async是要开销的，特别适合首页这种重缓存的场景；
异步编程：
Asynchronous Code是给语言层面提供一种方式描述程序在某一点等待慢操作比如慢文件读写或者需要其它资源协作，从而让计算机可以在等待中去执行其它工作。文中作者详细列举了相对于cpu和内存操作来说慢的多的慢操作如：
- 网络通信
- 文件读写
- 远程api调用如rpc调用
- 数据库操作和查询
异步是相对同步编程来说的，在执行顺序上并没有改变。实际效果就是同一台机器如果有比较多的慢操作使用异步编程可以提高吞吐率。这里再吐槽一下，大部分语言比如python、csharp、go等的async都是协程实现的，只有java是线程实现的。代价：进程>线程>协程，java不是不能用协程来实现完全是因为历史包袱，线程相对也不会丢失太多的性能。
并发和汉堡的故事
异步的描述通常称之为并发，它跟并行不是一回事，虽然他们经常都是描述在同一时间内处理不同的事情。在细节上两者大不相同，可以下面就是用汉堡的故事来理解：
你带着心爱的小妹挤进忙碌的快餐店，排队等着付钱买汉堡。
轮到你的时候，你付钱买了两个很赞的大汉堡。
付钱
收银员告诉厨房新的订单，哪怕厨房还在准备前面的汉堡
收银员告诉你取餐号码
然后你和小妹找张桌子谈谈人生谈谈理想，因为汉堡太赞需要时间慢慢做
你趁这个时间对小妹一阵猛夸，如何如何的魅力，如何如何的动人
轮到你了后去柜台取走汉堡
然后就可以和小妹一起慢慢品尝
设想一下，如果是计算机中这个故事会怎么样
排队的时候你可能需要被迫傻等，而不是做点有意义的事比如调情，因为收银员得一个个收钱
当轮到你的时候你才会忙着看菜单，点单，付钱，确认找回来的钱，就算这样你还是没有拿到汉堡，只能去找张桌子等待
直到这个时候你才可以做些有意义的事
因为你有取餐号，所以直到显示屏上通知你可以取餐都不用担心你的汉堡被偷了
最后你去柜台取餐，道谢后算是完成任务并开始任务品尝美味的汉堡。
并行汉堡
现在设想下如果不是并发，而是并行，那么你跟你的小妹来到汉堡店就不是排一个队伍了，而是并行比如8个队伍，没有收银员只有厨师。
你前面每个人都在等他们的汉堡，拿到汉堡后才能离开柜台，厨师只有交出汉堡后才会收下一位的订单。
终于等到你了，付钱，然后等待厨师去厨房做汉堡
没有取餐号，因为没人在你前面，这时你和你的小妹只能干一件事就是确保自己在第一个不让别人抢走汉堡
等待很久以后才能拿走，这里几乎没有时间给你调情，真是个悲伤的故事。
在这个并行场景中你和你的小妹是两个处理器都等待了很久。
快餐店需要8个处理器，而并发下只需要2个。
当然，这个体验肯定不好。
汉堡总结
这个场景中有非常多的等待，所以它更适合并发系统。这也是web程序遇到的问题。太多太多的用户，但是你的服务器要等待不那么快的连接，然后还要等待回应。虽然这里的等待是以毫秒记，但是加起来就很恐怖了。所以这就是为什么Web APIs都用异步。
对于大多数现有的python框架都是在异步特性出现前设计的，所以他们大多以并行的方式实现异步，性能不强。
是不是并发比并行更好？
不，使用场景不同，并发适合web程序，但不是所有。比如科学计算，图形/音频处理,机器学习，深度学习等都适合并行计算。并行计算主要解决cpu瓶颈。
