简单记录一下吧。

以前做的时候，针对 tcp 连接，想要玩家闪退闪连的时候，可以无缝的重连，所以用了消息 cache 的方案。这种方案的优点是短时间内重连的话，体验会比较好，比如下发一个奖励通知，必然是可以被前端收到的，运营很喜欢这种体验。

但基于 cache 的方案有个明显的缺陷是 cache 消息量不能太大，否则对于后端是个比较大的负担。特别是我现在做的游戏，会一直推一些增量的 aoiobj 数据变更消息，这种增量消息没法裁剪掉，也只能 cache 起来。结果就是我做的这个 cache 方案顶多就缓存 400 条消息，差不多是 60~90 秒的消息量。

最近，他们想要 30 分钟内的断线重连，我这个方案就不行了。于是引出另一种方案：重连的时候，各个模块促发 reconnect 函数，允许客户端拉某种全量数据，去恢复场景。这种方案的适用方案就更广了。唯一的缺点是解决不了（或者说难以解决）丢失一些下行的关键通知：比如一些奖励通知。也不是完全解决不了，但解决的成本会特别特别高。

总结起来：如果 cache 消息量不大，且断线重连容忍时间比较短，可以用消息 cache 的方案，否则都用 reconnect 拉全量数据的方案。