@WalkPhoneGo 功能、性能、可靠性，这些是不同的东西？为啥跟你讨论可靠性，你为什么非要说功能和性能呢？

至于为什么，不好意思我没研究过。

其实挺期待你说说原因的。

那按照你的逻辑，我试着回复一下哈。

1 无脑堆机器 不行

行

大量用户 是多少 稍微多一点人 AC就是一具尸体了

没事

这个不是框架能保证的 需要自己实现

1、2、4、6 都是功能，需要自己实现。

如果这么理解可靠性，也不是不可以。

关于这个模块，我说下我理解的可靠性吧。

坦白的讲，我不是很介意性能差一点，但 AC 似乎是很不怎么好。更在乎这个模块可不可以横向扩展。能横向能扩展，就可以无脑堆机器。

再就是，在一些奇奇怪怪的场景下，这个服务还可以健康的活着。比如大量用户重连的情况下、流量激增、一台机器突然挂掉，剩下的节点是不是能正常工作。

以及，用户断连到重连，这段时间内的消息，要怎么处理（有单独服务处理会更好）。能不能确认消息已经传到客户端有单独服务处理会更好）。再复杂一点，有序。

是一台物理机，记得没错是 120g 的内存。

但这个是性能吧？还看过 go 可以几个G 百万并发。。。

虽然 go 性能看起来更好，但 erlang 在这个场景更合适。

因为 erlang 有抢占式调度，go 没有。erlang 有并发模型，go 的 channel 相对来讲太简单了。很多东西做不了，或者不好做。

我问的不是 phoenix 性能好不好好，也不是想跟你讨论，phoenix 和 rails 相比，哪个好。

我就是想问。

1. 可靠性指的是什么？
2. phoenix 怎么保证的？

我理解，你回答的 1、2、4、6 都是功能的问题。 3、5 是性能的问题。

大体上（看起来都没问题，不过没仔细看），暂时都同意你的说法。

最后再强调下

1. 我不想跟你讨论哪个更好的这个问题。 我更好奇的是，背后的原因是什么？ 就是
2. 可靠性具体指的是什么？
3. 既然你说，phoenix 更可好，那 phoenix 怎么做到的？

从服务端，发出去的消息，客户端一定能收到。

这个 phoenix 是怎么做到的？还是说，可靠性不考虑这一点？

@WalkPhoneGo @lyfi2003

可靠性 具体指的什么？

要是说，从服务端，发出去的消息，客户端一定能收到。这个 phoenix 也做不到吧？这个应该考回执来做？

@WalkPhoneGo 求具体介绍下。

ActionCable 好像没有特别出名的使用案例。

ActionCable 里的操作，如果复杂或者耗时长了，感觉并发不太容易上来。。。

怎么样让某个客户端的多次请求 让一个线程内处理 用 nio，nio https://ruby-china.org/topics/38404 或者看 AnctionCable 的源码。

client.puts resp + headers

puts 应该事加 "\n"，导致 length 是错的，客户端发了 close 帧，服务端还要再写一次，就报 broken 那个错了。

具体的楼主还是用 tcpdump 看一下。

curl 也能重现。

主要 mnesia 是 Erlang 自带的，不过大家对 mnesia 都不熟，这个东西学习成本还不低。。。

类似的产品有多。同样是 Erlang 实现，倒是 RabbitMQ 很有市场。

除了特殊场景，性能一般不会是瓶颈。。。

我打脸了，本地（4 core）测了一下，mnesia 本地压测。和 redis 速度差不多。。。只是快了几倍。。。

除非 cpu 核心数特别多，或者几点特别多（也可能有问题），或者不需要好正一致性的情况，mnesia 在性能上才会有明显的优势。。。