最靠谱的 seq 生成者，应该是客户端直接连接的接入层服务（暂且叫 gateway 服务），gateway 服务生成 seq 并严格递增，按照下行消息的推送顺序进行标记。客户端发现收到的消息 seq 断开的情况，直接在长连接通道向自己的接入层服务发送请求某个 seq 消息重新投递的消息体，接入层收到后重新投递指定 seq 的消息。这个方案优点是不会存在 seq 和实际投递顺序不一致的问题，但是缺点就是如果长连接断开重新连接，会连接到新的 gateway 重新计算 seq，不过断网重连的场景可以要求上游业务重新拉取消息。当然也可以让 gateway 写缓存来实现切换 gateway 时 seq 继续有效，不过这个看个人取舍，我是不喜欢让 gatewat 做任何数据 io 操作。

最靠谱的 seq 生成者，应该是客户端直接连接的接入层服务（暂且叫 gateway 服务），gateway 服务生成 seq 并严格递增，按照下行消息的推送顺序进行标记。客户端发现收到的消息 seq 断开的情况，直接在长连接通道向自己的接入层服务发送请求某个 seq 消息重新投递的消息体，接入层收到后重新投递指定 seq 的消息。这个方案优点是不会存在 seq 和实际投递顺序不一致的问题，但是缺点就是如果长连接断开重新连接，会连接到新的 gateway 重新计算 seq，不过断网重连的场景可以要求上游业务重新拉取消息。当然也可以让 gateway 写缓存来实现切换 gateway 时 seq 继续有效，不过这个看个人取舍，我是不喜欢让 gatewat 做任何数据 io 操作。