引用：wecantstop 发表于 2020-12-21 22:23
概率是很小，但是如果发生了，不做兜底方案就意味着消息可能延迟很久才收到，甚至丢失

真要做到，还真有点不容易，我说的不容易，是指要兼顾性能、业务逻辑

引用：JackJiang 发表于 2020-12-21 20:55
从理论上来说，任何异步事件，都有可能存在时间差而出现问题。
但从实际使用来说，你说的这种情况，概率太 ...

概率是很小，但是如果发生了，不做兜底方案就意味着消息可能延迟很久才收到，甚至丢失

引用：完蛋 发表于 2020-12-21 18:16
a和b操作的数据库应该是单线程的吧，这时候拉取离线消息的时候不能存消息。那么就是存入离线消息在拉取之后 ...

我不太理解这个收到不连续的消息是什么意思。是每个会话的消息都有一个序号吗？正如我所说的情况，很有可能是这条消息系统还没存入离线消息库，客户端已经拉取完毕了，客户端拉取的消息数为0，客户端也没法校验是不是连续的啊

引用：卢小明 发表于 2020-12-21 21:17
这个可能跟异步还关系不大。
我想表达的是即使能得到一个一致性的登陆状态，也不能保证服务端推送的消息 ...

我表述有问题，我想说的是处于不同事务中的处理，顺序是肯定没办法绝对保证的，如果一定要保证，那代价会相当大，损失的必然有并发性能这些资源。

不过，就看你的产品定义了，一般性的im，没有必要太过纠结一些理论上的偏差

引用：JackJiang 发表于 2020-12-21 21:05
异步处理，很难在理论上保证百分百不出问题的，如果真的要保证，那代价不小。离线消息的读取，可以从缓存 ...

这个可能跟异步还关系不大。
我想表达的是即使能得到一个一致性的登陆状态，也不能保证服务端推送的消息一定能到达客户端。
正如你所说的，如果能容忍一定的丢消息那没必要纠结。。。

引用：卢小明 发表于 2020-12-21 20:43
既然客户端有拉取的动作，为什么不先存消息再推送消息呢？
登陆状态即使在某些场景下能保证如2楼所说的串 ...

异步处理，很难在理论上保证百分百不出问题的，如果真的要保证，那代价不小。离线消息的读取，可以从缓存中读，减小因落库这种慢io加大时间差的风险

从理论上来说，任何异步事件，都有可能存在时间差而出现问题。
但从实际使用来说，你说的这种情况，概率太小了，我认为不用太纠结。何况im并不是金融系统，极小概率的事情，假设碰到，也不会有太多影响的。

既然客户端有拉取的动作，为什么不先存消息再推送消息呢？
登陆状态即使在某些场景下能保证如2楼所说的串行，能保证推送的消息一定到达客户端吗？

a和b操作的数据库应该是单线程的吧，这时候拉取离线消息的时候不能存消息。那么就是存入离线消息在拉取之后，这样就代表客户端收到不连续的消息，那么校验之后拉取缺失的离线消息就好