看了 Django4.0 发行说明 感觉有点失望

[wuwukai007]

• https://docs.djangoproject.com/en/dev/releases/4.0/
• 异步 ORM 还是不支持
• ORM 添加表注释也没有上
• ORM join 语法 支持还是没有
• django-admin 样式万年不变

[JoeBreeze]

待解放的姜戈

[qW7bo2FbzbC0]

@neoblackcap #18 https://mysqlconnector.net/

[princelai]

@abersheeran #12 NBA 火箭队老板就是以个人名义发布的涉港言论，NBA 总裁肖华也只是说支持言论 free,最后呢？国家带头抵制啊，所以你说的个人名义啊，政治正确我觉得都是扯淡，国家层面就不支持你这东西。

[wamson]

@neoblackcap 异步 IO 和线程池差别大多了，线程切换的消耗比异步大多了。协程就是为了减少切换消耗同时又写得爽的，个人认为后端业务无论如何都不能有阻塞，所有的资源等待操作都应该是异步的。

[neoblackcap]

@hjahgdthab750 单单官网底下就说明了该数据库驱动是有连接池在底层的。异步调用的需求肯定是有的，但是这不是必须的，python 还有 asyncpg 。

@wamson 你做过 benchmark 吗？你大量的数据库查询请求是怎么发给数据库的？如果多了要排队，那么跟同步有什么区别？纯粹只是调用的区别嘛，你现在也可以自己简单封装一下，标准库已经有这样的组件可以让你将同步的函数封装成异步的

[sudoy]

我记得 nodejs 也支持“黑命贵”

[wamson]

@neoblackcap 你的观点是数据库操作异步并不能提高并发量。我的论据是，线程切换消耗比较大，异步就不用阻塞了。你想一下，如果我发起了一个数据库查询操作，接着要调用一个 rpc 接口。如果数据操作阻塞了，那 rpc 要等 sql 执行完了才能执行，这就慢了。就算数据库查询在排队，那我 cpu 可以空出来去做别的呀。要明确一点的是，异步肯定是能提高并发量的，不然，也不会还要发明异步 io 了，你说是吧？

[neoblackcap]

@wamson 你这样说的前提是你的数据库顶得住那么多请求啊，你的数据库明明就只能接收 10 个请求，你这边应用端发 100 个过去，那么你是不是应该有 90 个请求快速返回了，然后报错？切出去 CPU，不就变成用于回来处理这些问题？并不能合理利用 CPU 等待 IO 的时间嘛。要不你说说这个情况如何解决。
我并不排斥异步，但是我觉得异步要分开场景。数据库请求对于异步的要求我觉得不是那么大。很多数据库顶不住你的大量查询请求。

[haoliang]

@neoblackcap 你似乎搞混了 “线程池”跟“连接池”，异步程序也可以利用“连接池”

[neoblackcap]

@haoliang 请看我 25 楼的回答，我早以指出所谓的异步调用可以用现有的标准库封装线程池实现。
同时本帖的重点并不是什么异步同步之争，本身问题是基于 Python 环境的。一个底层是线程池封装的异步调用真的会比同步的多线程更高效吗？我表示怀疑

[wamson]

@neoblackcap “你想一下，如果我发起了一个数据库查询操作，接着要调用一个 rpc 接口。如果数据操作阻塞了，那 rpc 要等 sql 执行完了才能执行，这就慢了。“

你看看我这个例子，等待 sql 的同时，我可以去做 rpc 调用。同理还可以操作 redis，或者做一些别的 cpu 操作。

一般来说数据库的总处理能力是要高于需求的，这个是在架构的时候必须要保证的。然后你说的数据库只能接收 10 个请求，但是有 100 个请求发过去的问题。我可以理解成是一个突然的 sql 请求波峰？我在做异步数据库请求时，一般是放到请求队列中，由单独的线程去处理请求队列。具体来说是，主线程异步发起 sql，其实就是放置 sql 请求消息到队列中，子线程消费队列中的 sql 请求消息，然后执行 sql 。此时主线程继续执行下一条代码，sql 执行完毕，子线程回调主线程的 callback 。