是的，你这个余额检测、扣费动作，跟钱有关，所以需要很谨慎的实现。

我引导你正确理解一下im：

1）不管你的im如何设计，一定不要把im做重了：也就是能不要im做的尽可能不要im做，比如能用http接口实现的，就不需要动用im的长连接通道。原因是http的实现，无论是高可用、性能负载还是什么，做起来都有标准成熟的方案，比im这种不标准的东西实现起来要简单多了；

2）记住一点：IM永远只是一个实时的消息收、发“通道”：记住，它只是个通道，说白了，谁要发什么消息，收到消息要怎么处理，im只负责调度，具体逻辑由你的别的业务服务去处理。im只需要从你给他的列队中取消息并发给你指定的人，或它从用户实时收到的消息放到队列中（由你业务服务来取并决定怎么后绪处理）。

以上，你多体会一下我说的。一般im做的比较久了，很容易理解我说的。你如果对im没有太多经验，多理解一下我说的，回头你就会发现，确实该这样，不然越往 后做，你就越没法做，因为im越来越复杂，随之而来的：优化、扩展、重用都是大问题，因为复杂性增加，已经没有改进的空间了，或者说一团乱麻。

引用：ykpeng 发表于 2020-07-28 15:27
我想知道，我两种 方案怎么样。 哪种好点，或者说不可行。 另外，大大有什么好的 方法么

第一种从技术上来说，成本太高了，请求太多。尽量考虑第二种，但需要你根据你的业务场景，深入的理清逻辑，把未来的扩展点都想清楚再动。

引用：ykpeng 发表于 2020-07-29 16:01
顺便问下大大，这个问题这么优化：就是我推送消息，由于网络原因丢了，然后很长一段时间没有新消息来，这 ...

如果要确切知道推送有没有被收到，那就要加应答机制了，服务端在超时时间后，没有收到客户端应答的话，就再次推。