做可以做，但是你这样搞，小心被说成学术不端。到时候你毕不了业才是问题

@kongkongyzt arm 服务器在国内也是有的，但是基本上都是裸金属，费用高。当然了这应该也跟 arm 虚拟化指令并不是那么完善有关。

@GYGYG 最简单的方法就是，你使用 tornado 自带的 tornado.tcpclient.TCPClient
当然你像二楼说的，你自己创建一个连接也是完全可以的，前提是你要把该连接设置成非堵塞，并把它注册到 tornado 的 IOLoop 上。

问题就是你把 socket 跟 tornado 混在一起了，tornado 已经帮你处理了底层 socket 的逻辑，包括 IO 复用。
你需要做的是在 on_message 里面写你的逻辑，并放弃使用标准库里面的 socket ，从而使用 WebSocketHandler.write_message 等方法

其实对照功能列表就知道了，如果你觉得 celery 给你带来的成本高于收益，很大程度你是对的，那么不用就好了。没有什么说一定要上 celery 的。
至于用 celery 的团队也没有错，有可能是他们首先比较熟悉。然后他们可能用到了 celery 的一些特性，比如既需要定时任务，也需要 job queue 。
没有什么选型定式，看个人需要。

@LeeReamond

1. 我的代码只能说解决 celery 能不能用 asyncio 的问题。

2. 既然你调研过 celery ，你就会明白你所说的并不是什么不可能的事情，就是需要额外提供一个基于 asyncio 的并发池，可以通过继承 celery.concurrency.base.BasePool ，并实现对应的接口。既然 gevent 能做到，这显然是可以做到的。但是你所说的共享连接池，等资源共享就未必。celery 是分布式的，worker 可以分布在多台机器上，你的需求本身就跟它的设计大方向矛盾。

3. 我理解你想要的回调应该是 rpc 式的回调，而不是在 worker 里面调用你的回调接口。你的回调是需要生产者配合的，哪怕现在 Python 绝大多数的人还是在使用基于 wsgi 的 web 框架。支持 rpc 式的回调，基本上就得在框架上面动手，不改支持不好。

4. 如果你所说的异步生产应该是指这个生产的动作会被你调用者的 IO loop 所管控的话，那么就是跟上面有着一样的问题，那么应该在很长一段时间内 celery 也不会改，这个同步异步需求可以使用线程池绕过。

5. 你的需求很好，但是这不是 celery 能解决或者解决好。这不是 celery 的问题，任何一个开源工具都没有说要对某一个人的需求负责。你如果觉得需求重要，有通用性的，那么你可以提交你的解决方案，或者提思路，又或者提供资金。我觉得退一万步讲，哪怕 celery 是个垃圾它也没有强制你使用。你完全可以选择其他方案，而不是发一个贴将它批判一番。自由软件是它已经提供源代码给你，授权你使用，修改的权利。一些个人需求，不代表就是社区的需求。

@LeeReamond https://gist.github.com/neoblackcap/98c98b3ea66553cdf77976c4f7f7b6d2

@est 不就是为了这些？什么都裸写，新写的架构做好一点都比 celery 来得强。那个代码看到头疼

@LeeReamond 不是 celery 开发者说不支持就是不行。他们不支持不代表你不能写。主要是你想要实现到什么程度，要花多大力气。你在对应任务里面开一个 io loop ，自己等待这样行不能，算不算支持？
还是说要 celery 支持对 coroutine 类任务的调度？还是说社区要做到封装好，使用者感知不到，可以随便用一个装饰器把函数直接转变为 task 才算支持？
你都没有说具体的需求，那怎么给你解决方案？

@est celery 不是还不错，是社区比较久。资料相对较多。说它是玩具过了，但是说它写得多么好，我觉得也不是。
毕竟我看过里面的代码，简直让人觉得头大。
不过它很早就写了，现在要搞一个跟它一样多功能的，怕是要下一番功夫。至于你说的失败重试不可靠是怎么一会事能说说吗？
根据我的使用经验，它的失败重试还是比较靠谱的，前提是你的消息后端一定要基于 rabbitmq 。其他 backend 有些问题，比如 redis 。这事 celery 的社区跟 redis 有过直接的联系，不知道修得如何。

@LeeReamond 是全部都可以，gevent 有比较好的支持，asyncio 没有。但理论上你都可以简单写一个 worker 类来支持。几十行代码的事情，全网网友的痛点就过了。
既然 gevent 都能做，asyncio 的支持显然不是什么问题。问题绝大多数来自于跟其他类型的 worker 结合不好。
有 IO loop 的 worker 是不能做 CPU-bound 的任务，所以此类 worker 的使用有限制，你是遇到不能扩展还是什么情况？

@tcpdump dropbox 分享过一个任务系统的设计思路。celery 玩具不至于，不过架构复杂，导致加什么功能都比较难吧。而且 celery 自身已经有任务编排聚合功能，一般的任务队列还真是不能跟它比较。
至于 asyncio ，理论上自己写一个 worker 类是完全可以支持的。只不过很多人也不看源码，也不看文档。所以就觉得不行。反正 IO 复用，我是用过 gevent 的 worker 类，效果还不错。

sublime text 卖 99USD ，这有啥可比性？
就连功能强悍的 PyCharm 也是卖 89USD ，单纯考虑使用舒适性。上 PyCharm ，不管是智能感应还是重构等编辑功能都非常厉害。
如果要考虑钱，那么 VScode 是无敌的。目前免费的综合使用就没有比它强。

@levelworm 什么样的水平不好说，反正有很多用 C++的。如果是 Java 的，可以去看看 LMAX 写的 Disruptor 框架。那可是正经八百的金融公司写的，用于解决报价问题的框架

抱歉，Django ORM 没有 Left Join

你这个报价有没有时效性的啊？据我了解，股票报价都是按时效算钱的。不同延迟的报价收费可不一样。
这行里面的很多公司的解决方案都是自研的，因为一般开源解决方案满足不了他们对时效性的追求。

你实际需要的可能是一个守护进程，以及一个与它交互的命令行客户端。

go 一整个语言就是协程框架，sanic 没法跟它比性能的。
只要是 go 生态的，那么就已经是进入了它的协程生态。python 生态却不一样，有很多同步库的。
但是如果你因为这个问题来问选什么的话，那么我建议你不用选。你自己熟悉什么语言就继续用什么语言就可以了。我还说 Rust 的 actix-web 性能更强，难道你还要去学 Rust?

一般业务的性能差异，我觉得还轮不到你来考虑这些框架的性能满足不了你。这些框架哪个不能轻松解决 C10K 问题？而且 C10K 都是 20 年前的问题了。但是你的生产环境有 C10K 问题吗？等你的业务上了 1 万并发再来考虑吧。

@maloneleo88 下次这样的活找请联系我，只要 500 人民币，你啥都不用做，有人工智能系统帮你处理好一切