• 请问 怎么理解 目的很明确

  • 建议换 Phoenix Channel AC 实在是不适合做稳定性高的项目

  • 高级黑

  • ShowMeBug 核心技术内幕 at 2019年10月30日

    1 无脑堆机器 不行

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

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

  • ShowMeBug 核心技术内幕 at 2019年10月30日

    AC 不知道客户端死活,可重复进入,并发差 这看起很可靠吗?

    我的意思就是 Pheonix Channel 一开始就解决了这些问题。

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

    因为我用 AC 和 PC 分别实现了一个聊天程序,这是我的一些直观感受。

  • ShowMeBug 核心技术内幕 at 2019年10月30日

    1.ActionCable 只有服务端到客户端的心跳,客户端掉线不知道。这点 Phoenix Channel 自带。

    2.ActionCable 存在重复进入问题,同一个用户可以多次进入同一个频道.这点 Phoenix Channel 自带去重。

    3.ActionCable 的订阅机制是基于 Redis Pub/Sub, 无法平行扩展,必须要连同一个的 Redis 存 Session。这点 Phoenix Channel 也是自带的,基于 PG2。

    4.Phoenix Channel 可以回复给单独一个用户,这点 ActionCable 做不到,除非单独给用户一个频道。

    5.Phoenix Channel 可以支持单机 200 万并发 可以 Google,虽然用的硬件很好,但是也很厉害。据说 Ruby 2.7 可以提升 ws 的并发性能。

    6.Phoenix Channel 自带用户在线列表,不需要自己维护,可以在一个集群内监控用户的上下线。

    你一定要说 Actioncable 有一点好,就是太 TM 简单了,快速出效果还是极好的,真的上线还是推荐 Phoenix Channel!!!

  • ShowMeBug 核心技术内幕 at 2019年10月29日
  • ShowMeBug 核心技术内幕 at 2019年10月29日

    其实 Phoenix LiveView 也可以实现

  • ShowMeBug 核心技术内幕 at 2019年10月29日

    一说到可靠性 就不得不吹一波 Phoenix Channel

  • httparty