Messenger System的guarrentee delivery & scale out problem

系统设计
1

老师，

你第二节课，上课的内容挺不错， 不过据我之前的部分经验， Messenger System 主要还有两个tricky的地方. 如果一些面试官做过类似项目的话，涉及到这些follow up深挖的话，可能会涉及到。 您是否能帮助分析一下，这两个方面对课上的设计有没有影响

  1. Guarrentee delivery

据我了解即便client和server 保持了双通道链接，但是ws在实现方面做了取舍，也就说是server是不能够保证client能够Guarrentee delivery。如果在consistency这一块有很高的要求要确保消息deliver，对课上的设计是否有影响。

我目前能想到的思路是类似于你课上提到的，在client和server直接通信 不直接用裸websocket， 用MQTT protocal over websocket，或者decouple 通信这一块，直接用亚麻aws IOT + MQTT 或者azure 的iot, MQTT 用它的 QoS level 1, At least once delivery 。
您觉得如何？ 不过， 它具体实现的原理是怎么样的，我一直没搞明白，能否讲讲或者有比较好的资料

  1. Scale out
    websocket的优点很明显，缺点也很鲜明，就是client只和一台server node保持长连接，那么等有新消息或者更新的时候，系统如何找到对应的server node来进行投递消息或者 pub sub 通知 呢？ 或者系统如何能广播通知到其他server nodes的对应的 target client/clients 呢？

我目前能想到的思路是 利用distributed message queue 或者redis的pub sub 在server nodes 之间 同步， 您觉得如何？

这对我们课上的设计有没用影响，还是说我们课上的queue已经是distributed 能够通知到对应的node?

感谢！

2

Guarantee delivery

Websocket 是基于 TCP 的。 TCP provides reliable message delivery. 这个 reliable 跟 guaranteed delivery 是不一样的，Reliable 只保证在连接正常的情况下能够发送信息，如果发送失败会返回失败。但是 Websocket 的场景下可能因为连接中断而无法递送。就像你说的，要做到更强的保证，需要在 Websocket 上一层加一些逻辑，MQTT QoS 是一种可行的方法，可以保证如果连接短时间内有问题可以暂存一下然后递送，起到 Guaranteed delivery 的效果。QoS 实现原理归根结底还是怎么处理异常情况，如果消息没有成功发送，怎么应对。At least once 如果出现异常，可以重新递送，直到确认成功为止。

延伸阅读：

1 个赞
3

Scale Out

系统要找对应的 Server Node 就需要知道一个 Mapping - 哪些用户对应哪个节点。这是一个很普遍的问题，任何一个有状态的分布式系统都需要解决这个问题。Hash 是一个比较简单的解决方法。处理节点宕机问题的话可以使用 Consistent Hashing。

当然使用现成的 distributed message queue 也可以，其内部也会采用一些类似的方法来做分布式。

1 个赞