恩，是的

其实这个场景，比较合适的是 compare and set，设置之前，先查，之后掉 comap and set，失败了就重试，好处就是实现简单。

或者那个服务把查询请求代理到我这。

恩，是这样的。改数据的时候，数据库，要知道两次操作的先后顺序。

比如 put(a, 1) 和 put(a, 1) 这两个操作发生的先后顺序。

如果这两个请求先后发送到两个服务器上个，server0，server1。

如果 server1 的时间比 server0 慢的话，用时间戳的话，顺序可能就反了，数据就是错的。

服务器之间需要 ntp 之类的协议同步时间，这个是不准的，有可能会差 100ms（只是打比方）之类的，还不考虑时间配错了之类的。

具体的可以看，设计数据密集型应用 里有关于时间戳的说明。

简单来说，就是分布式场景下，使用时间戳，作为顺序是不可靠的。

1. 首先，是人家怎么看的问题 大家可能对后端的理解不一样，或者 hr 不是很理解 RoR 的工作方式。可能工作内容 ok，但别人没理解。面试什么，主要还是面试官说的算。。。

2. 然后分布式个人经验来说，这个还是有用的。 我们被分布式数据库坑了两次，最后是了解了实现，才解掉。 不久前才刚跟同事扯时间戳没有办法保证时序（起因是我需要调用他的服务，我的业务需要有时序保证，他建议用时间戳，我跟他解释说时间戳帮助不大）。

   分布式会影响思考和解决问题的方式。想说的是有影响，但有没有意义，是不是好的影响，这就要看情况了。

   我们招聘对分布式没硬性要求，问到的情况也不多。

Goroutine 用的是 M:N 这个线程模型，可搜到很多介绍比如这个 User-level threads....... with threads. - Paul Turner - Google

为啥不直接用线程做并发（1:1）？因为线程切换不够高效，可以参考下这个 Measuring context switching and memory overheads for Linux threads。

一个线程只能利用一个 cpu，这个是没错的。但更重要的是，一个线程（scheduler）要跑多个 Goroutine。

1000 每秒的话，2 核 4g 这配置，es 感觉扛不住。

传说中，一个人搞定了整整一个团队的活。

哈尔滨吗？

我要努力向 Dylan 大佬看齐

好的 👌

好呀

哈哈哈，下周咋样？这周在外面

这不是想给 Martin 哥当马仔做准备吗

短链转长链，用 ws 渲染？不知道 ActionCable 性能抗的住不。

在看这个的时候，conscrypt 内存又泄露了。https://github.com/google/conscrypt/issues/835

之前漏了一次，感觉修了有一年，刚修好，又漏了。这次好在漏的比较慢。

之前 fastjson 有安全漏洞，修了 n 次。

google 的 package 有内存泄露，修了一年，没修干净。 阿里的 package 有安全问题，修了 4、5 次了，也不知道完全修好没。

然后大家都认为，java 工业化做的特别好。

感谢，已更新。

这家公司，据我所知，在广州 ruby 圈，口碑非常好。

他们用 ruby 非常早，一定程度上可以说是他们把 ruby 带到了广州。

记得在广州，茶余饭后，大家时不时会说起武师傅的传闻

声明： 以上仅个人看法，有些也是听说的，也有夸张的成分，大家要是感兴趣，还是具体了解一下比较好。

招聘一定程度也是开发者面试公司。

第二种官网有说 https://redis.io/topics/clients#in-what-order-clients-are-served

我消化下，感谢。

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

感谢分享，

想请教楼主一个问题：

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 的

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

感谢，这个 clojure 竟然表现不错，不过感觉是占代码少的便宜

然后 elixir 用内存多，感觉可以调一下 min_heap_size，那个用来缓存消息的。

ActionCable 性能渣渣，盲猜，应该是消耗在线程切换了。nio 就是为不用线程模型。然后 RoR 又在这加回来了。。。

也不能用 Fiber 解。这块加 thread pool，我猜是为了避免一次处理时间过长，卡了所有的任务。用 Fiber 没发避免这个问题。

所以还得用 thread pool，不过应该有更好的解法。

还不是很理解，为啥 broadcast 的时候要用 thread pool，因为 io 已经 异步了。如果是接收消息的时候，有线程池，还可以理解。。

请教过一个问题，有压测过 actioncable 和 phonex 的 pub/sub 吗？比价好奇两种性能的差距，搜了一下，没找到相关的对比。。。

看了你分享的压测，感觉 go 的实现，也不是很好。。。

怎样去做 benchmark

要看你们的场景是什么样了，同时在线有多少人，大约会有多少 qps。然后写脚本，模拟这些连接和请求。

至于 4 台行不行，还得压压看。