P.S. @kingofzihua 补充一句，actor model 里面每个 actor 其实是个状态机。差不多就是


def __init__(self):
....self.state = 0

def on_message(self, msg):
....if state == 0:
........do something with msg
........self.state = 1
....elif state == 1:
........do something with msg
........self.state = 2

核心就是这个 on_message 处理函数。你是期待框架把新的数据推送给你（或者别的专门读数据的 actor ），而不是在每个 actor 里面都调用 read 。

这个的好处在于，你可以把 IO actor 和业务 actor 切分，业务不用管太多 IO 细节，实现了解耦。单元测试的时候你可以直接对业务 actor 伪造输入进行测试。特别爽。

而且状态机可以回退，这个就可以实现很复杂的东西。

…… 不过实现一个基本的 actor framework 也不是那么困难的。。。

再比如我自己在自己的项目里面用 C++ 实现了一个。

@kingofzihua 对既然提到了 actor model ，楼主如果有兴趣可以去看看 actor model ，这个东西的思考方式会让你改变很多对并发的看法。比较成熟的 actor model 的实现大概只有 scala akka 。

actor model 的核心在于，每个 actor 只有一个工作线程。actor 尽量避免阻塞。即使你在 10 个线程的线程池上运行 10000 个 actor ，每个 actor 要同时处理其他 9999 个 actor 发来的消息，也保证只有一个线程在运行一个特定的 actor 。这个是 actor model 最重要的特性。

@2i2Re2PLMaDnghL 就我个人而言，Actor 模型和 callback / future / 协程不是一个维度的。

actor model 的优势在于 state + mailbox 。每个 actor 上面有个单独的等待队列，即便你在线程池上跑 actor model ，也不会让一个 actor 在多个线程上运行。这使得你可以很安全地编写出来双向交互的 actors ，而不用担心每个 actor 内部的数据存在竞争关系。

线程、协程、callback 、future ，数据流一般是单向的，一个 IO 线程在启动一个后台任务以后就陷入等待，不会处理任何其他事务。而 actor model 每个 actor 都有一个微型 event loop ，完全是全双工的。

你可以很容易用线程池实现 actor model ，避免阻塞调用就能实现完全非阻塞。你也可以在协程上实现 actor model 。或者你也可以在 event loop 上实现 actor model 。总之 actor model 是高于并发的一个抽象模式，核心在于数据封装。

通常一个应用程序服务器可以划分为两部分线程组：

1. IO 线程，处理网络 IO 、数据库客户端、等待后台任务、（轻量计算）汇总各种结果。
2. 计算线程，应当是固定数量的线程组成的池，这样一个计算任务丢进来可以排队。

也可以是分离的进程乃至于不同机器处理这些不同的事情。如果是不同进程，可能就会上 zmq 之类的 ipc message queue 。如果是不同机器，那么就会上 rpc 、http api 、redis 或者更重量级的 mq 。

@kingofzihua

1. 对，协程只对非阻塞 IO 起作用。
2. 但其实，所有上述的并发方法都是针对阻塞 IO 减少开销的。对于 CPU 密集型任务，如果只有 2 个核，同时跑 4 个矩阵计算是没有意义的。
3. 在实践中，通常把 IO 任务和计算任务分开。IO 靠比如 Promise/Future ，event loop ，协程搞。如果需要调用计算任务，就扔到一个固定线程数的线程池上跑，然后协程进入 await 。等计算完成 await 被唤醒，再继续做后面的 IO 。

@0o0o0o0 其实感觉 async/await 就是协程的一种（个人认为最优美的）表现形式。然这需要大量语法糖支持。

Python 和 JS 的 await 都已经上线了，用起来其实挺爽的。只是 Python 方面的支持库力度还不行。

C++20 的 coroutine 虽然语法糖标准已经发布了，但是根本没有支持的库（差评）。还得等几年。

其实这里有两条技术路线

callback => promise / future
event loop => coroutine

要理解协程就要去理解这两条技术路线的区别。

并发种类：

1. 多线程：太慢

2. callback：代表作为 Node.js 、python tornado ，boost asio 。但是会陷入 callback 地狱。

3. Promise / Future：java, scala, js, 比 callback 好多了，目前是主流技术之一。缺点是要仔细管理闭包的嵌套。

4. event loop：一般 c/c++ libev libuv ，还有 python gevent 。心智负担比上述三种都大，但是可以更精细操作、更高效。底层实现一般为 kqueue 和 linux 上的 epoll ，或者 fallback 到 select 。

大名鼎鼎 nginx 就靠 event loop 暴打同时代。

5. 协程。

协程一般用 event loop 实现，这种协程就是对 event loop 的抽象。要理解协程，建议稍微学习一下 event loop 。

“如果阻塞是系统调用阻塞，线程就会挂起，调度到其他的线程了，你协程没用”

所以协程要配合非阻塞 IO 。

原先 callback 或者 Future.map 就是非阻塞的，但是写起来心智负担太大。所以抽象了一种 IO ，形式上是阻塞的，但是实质上是非阻塞的。await non-blocking read 会把控制流立刻转向其他协程，而当这个 non-blocking read 成功以后这个协程会重新进入调度队列。

1. 虽然原则上在 mac 上开发 linux 上运行的 c++ 也不是不行。
2. 但是最方便的还是在对应平台上开发，不然断点调试麻烦。
3. 所以你可以买一台比如，联想

@3dwelcome 真没必要这么快。Typora 的渲染速度已经够了，看上去也不是纯 GPU 的亚子.

@balabalaguguji 呃，Typora 不贵吧。。。虽然不是没竞品。

MarkText 不好用，渲染性能有点问题。Milkdown 这个控件还不错，但是只有控件没有 app 。

你自己开发付出的时间成本还不如买一份授权。

如果是觉得它不够用那另说。

@xz410236056 下馆子和朋友撮一顿也要 100-200 啊这个时代。你一年不下馆子个几十回么？

99 刀一个 Xshell 确实离谱，我上面也说了，用竞品。但是 99 人民币总算不贵了吧？你电脑上常用软件、没有免费开源竞品的，能有几十个嘛？

因为现实世界中可能有突如其然的大量数据，让 es 暂时宕机。此时如果你每个客户端都自己重试，就会让这个突如其来再度翻几倍，那么你将损失一大批数据。Kafka 的写入比 es 快很多，所以相当于一个缓冲区，还是分布式的。

@IxIIxI 你这用破解版的可真恬不知耻。你自己做的软件别人如果白嫖，你自己不会生气嘛？

用不起就换一个竞品，这才是正确的回答吧。

Xshell 是太贵了没必要。

@c0xt30a 哦你说跑实验的代码？

https://github.com/haowen-xu/ml-essentials
https://github.com/haowen-xu/mlstorage-server

不过这两个相对而言没怎么写好文档。。。