snap 很多 bug，又不修。安装完系统第一件事就是卸装它

这服务是有的，亚马逊的邮件服务加 lambda 即可。不过需要编程

可以用 input 函数实现你这样的功能。
实际上我是在想为什么要这样做？如果要保留结果以便观察，你可以通过输出内容到文件。又或者写日志的方式。
手动让程序结束，并不是必要的吧

干掉 like 查询

虽然 panic 是可以做到，但是这不是应该通用化的做法。
最好还是有错就返回 error，如果有可能的话，请改这个函数接口

几千条记录，你们的机器性能真高

@systemcall wsl2 跟 windows 是同一个级别的，因为 wsl 是用 hyper-v 的技术。最底下才是 hypersivor，他们两个都是在 hypersivor 上面的。

@LeeReamond 因为是协程，如果并发 10 个请求过来，你每个请求都需要进行计算密集型操作 10s，那么这批请求的总耗时将达到 100s （单进程）。协程不会自动进行调度。

@LeeReamond
你这个问题有试验吗？每次的请求都是建立 TCP 连接，到解析请求内容，你这个 asyncio 怎么就让通讯消耗的时间少一些呢？
IO 复用不是银弹，asyncio 在 linux 下基本上是 epoll 的封装。它只能解决并发的问题。但是如果你一个请求需要进行 10s 钟的计算，那么每个请求的耗时并不会降低。
所以你如果认为 asyncio 能帮你降低单次请求耗时，我认为你的实验是有问题。
fastapi 之所以看起来比一般的框架快，只不过是它的 asgi server 实现得更加高效罢了。同样的道理，如果去掉所有中间件的并使用一样的 asgi server 实现，它们也不会相差很大。类似的结果，你自己之前也有说明。没有数量级的差别(aiohttp vs fastapi)

你也不说具体的设计指标。我现在就只看到数万的 qps benchmark 。要知道现实往往没有那么高的并发，而且 TechEmpower 那个 benchmark 我都无力吐槽了。要想往前排，大家都是各种 hack，看看就好。认真你就输。

而且你了解 fastapi 跟你之后 cython 计算模块整合的详情吗？所有这些 IO 复用的框架都不能在处理请求的时候进行 CPU 密集型操作，你知道不？

PS：你要讲究压榨机器性能，Python 想都不用想就排除了。单单线程残废就是一个死结。寄希望于框架帮你实现大并发，我只能说一句“没有银弹”。任何的高并发都建立于你对系统、程序等等多方面的了解。

@LeeReamond 我觉得你说的都没有问题，我只是作为一个旁观者问一下你的想法。
打个比方，你认为一个技术一定能解决你的问题。你总能说出具体的原因吧。
比如 go 写的程序效率很有可能比 Python 写的性能高。因为 go 不是解释语言。对不对？

我看你写的话感觉你是被潮流所迷惑了。自我写 Python 以来，Django 日常被喷。然而它却一直在更新。还引入了新的技术，制定了了新的协议。潮流并非一定是潮流。好比 Django 有 instagram 这样的成功案例，其他的都没有。你的业务还比 instagram 的并发高么？

至于你回答的 SPA 就很好了。你显然可以按这样的方式回去思考相关的点。不过我要提一句，真的是没有区别吗？其实我认为无论是性能还是维护都有很大的区别。这就看你的需求。我不知道，所以只能由你自己回答。

第六点恰恰是我想提个醒，程序员总是高估自己，低估问题的复杂度

我提问题并不是抬杠，毕竟我直接跟你讲“小黄鸭调试法”你也不知道我想表达什么吧？如果你作为一个决策人，你自己都搞不懂为什么要选这个技术栈，这个技术栈有什么优势劣势。那么如何说服其他人呢？当然如果你是全干的那就随你吧。

其实网上的很多回答并不能直接采用，你不懂，我跟你讲 fastapi 坑很多，无脑上 Django/Flask/Tornado/Bottle，你怎么知道对还是不对？

鉴于你的需求，我提几个问题
1. 高可用跟异步特性有什么关系？
2. 高可用跟必须使用异步特性有什么关系？
3. 你对 fastapi 有多了解？
4. 你对 Python asyncio 有多了解？
5. SPA 程序为什么还需要后端提供服务？ single page application 一般特指使用前端框架或者类似技术实现的程序，此类应用恰恰需要前后端分离。后端单纯提供接口。如果需要提供页面访问能力的，恰恰是传统的服务器渲染架构。
6. 为什么你认为用一个你自己都不是很熟悉的框架可以快速保质不超工期完成你的需求？

不管你最后使用什么框架，但是我觉得你如果思考清楚了以上几点之后。你可以得到更好技术评估结果

@rogwan 是能支持大规模的用户，以及扩展好。whatsapp 没记错好像是 yahoo 出来的人搞的，复用以前的经验罢了

@scr node 跟 Java 都是一样有强大 JIT 的语言，性能高没啥奇怪

要不你试试多放几个核给你的容器试试？

@salmon5
mark 好像是第六版才才加入的

@levelworm
你看看作者之一的 mark 是 azure 的 cto 就知道这书不是一般的厉害。mark 不仅仅是微软的 azure 的 cto，还是 fellow 。

PS：这书国内是有引进的，叫《深入解析 Windows 操作系统》，同类的也有潘爱民博士写的《 Windows 内核原理与实现》。

@DejaVud Windows 上面很多研究都是逆向的。最厉害的莫过于《 Windows Internals 》一书里面的东西，作者不是微软的人，却请出给 Windows 开发组培训
PS：sandboxie 现在好像是开源了

@no1xsyzy SCTP 据我了解，也就是运营商在自己内部的一些网里面用。广义的网络，各种设备是针对 TCP 以及 UDP 来设计的，设备里面是有 ASIC 去处理 TCP/UDP，SCTP 没有这些硬件加成，速度立马下降。
这也是为啥 QUIC 会设计在 UDP 之上，而不是另起炉灶。

原理就不讲了，我说说历史吧
socket 这套东西呢，其实本质上是历史物理过程的模拟。TCP 就是模拟电话而出现的，UDP 就是模拟电报。
我们当然可以说拍了“一个电报”给别人，而且说明一件事情的时候，我们往往可能要用到“多个电报”。
然而当用电话的时候则不同，我们也可以说打了“一个电话”给别人，然而往往说明一件事情的时候，我们用“一个电话”就可以搞定了。
为啥打电话的时候不会出现“粘包”而 socket 编程又会出现“粘包”呢？当大家回忆自己是怎么打电话的时候，大概就明白了为啥不“粘包”了

RPC 不稳定能不能通过重试来解决？如果可以的话，通过分批写入，同时增加重试机制是不是改动成本会更低一点？
换存储看似简单，但是你要考虑跟你们现有的技术栈合不合适