我消化下，感谢。

感觉第二种应该就没办法了

感谢分享，

想请教楼主一个问题：

redis 多线程了，那单个 client 的请求，redis 还能保证处理和返回的时序性吗？

就是同一个 client，发给 redis 指令顺序是什么，redis 处理的书序就应该是什么，并且以同样的顺序返回。

我在 Stack Overflow 上也问了，不过没人回我 https://stackoverflow.com/questions/62097897/will-redis-6-guarantee-client-requests-order

换个技术栈啊，比如 Go、Java 啥的。RoR 很多好玩的东西都没得玩。

信炮哥，无 bug

鉴于 Ruby GIL 的机制，上面的情况，同一个进程内，如果有重的耗费 CPU 的动作执行期间，可能会导致这段期间这个进程无法响应普通的 HTTP 请求，从而堵塞正常的 Web 服务。

这个地方没太看明白，想请教一下。

看 无人知晓的 GIL 里说， Ruby 有一个 time thread，会给其他线程标记中断，被标记中断的线程，在执行完一个方法的时候，会调用 vm_call0_body 这个方法，如果有被中断，就会让给其他人执行。

我理解像 + 执行完，都会执行 vm_call0_body 这个方法。如果一个线程想一直占着 CPU 的话，除非是调用 C 方法。

不过也有一种情况，有多个后台任务在执行，打满线程池，就会堵塞正常的 Web 服务。

我们是做 IM 开发，IM 开发还挺特殊的，也不好被完全算进 web 开发。

有些问题可以被当做算法问题，比如 N + 1，就是复杂度 + 网络传输。

我们在做一些设计的时候，也会考虑时间和空间复杂度，主要是怕把服务搞挂掉。。。当然多数的时候不需要考虑。

有些算法问题，其实也是编程能力的问题，像二叉树遍历、归并算法，如果递归掌握的好，这些算法就很好理解了。

递归 ruby 中用的比较少，但写 clojure、erlang 这种，递归写不好，真玩不转。。。

上次用到算法是节前。遍历数组，每次遍历用了 count ，担心会是 n 方的复杂度，就改了（后来发现想多了）。

上上次，是发现 redis 有个慢查询，查了下，是因为用了 HGETALL，而 HGETALL 是 O(N) 的复杂度。

可能用不着实现算法，但复杂度的分析还是经常用到的。

zoom 收费了。。。

有人来了，有的人走了，有的人不知道是走了还是没走。

感谢

broadcast 是用来给所有 channel 内的连接发消息的。

这个地方，大体做的事情，就是 encode 和 往 IO 里写。

encode 消耗的是 cpu 资源，用不用线程池意义不大。甚至不用线程池可能更快。

debug 看了下，写 io 的时候，是异步的。线程池也没有意义。

如果没同步 io 操作，线程池意义不大，或者说纯粹的 CPU 计算，线程池其实没啥意义。

整个 ActionCable 是公用一个 thread pool 的

共用线程池不是一个很好的做法。