sequenceId 回拨问题

[pedrogao]

我看到客户端是通过 sequenceId 来排序展示的

服务端的 sequenceId 是根据 redis incr 指令生成的，虽然性能很好，但如果 redis 宕机或者主从切换，那么 sequenceId 就会回拨，后面产生的 sequenceId 就会有重复？这类问题有兜底解决吗？

[JamesChenX]

如果 redis 宕机或者主从切换，那么 sequenceId 就会回拨，后面产生的 sequenceId 就会有重复？

It doesn't matter. By the way, all components of Turms servers are designed to work in extreme situations, which means you can crash Turms servers/clusters or their dependencies for fun, and Turms servers will recover automatically.

For this question, sequence ID exists to find out which messages are missing in edge cases. So, if your client detects a 0 sequence ID, what you need to do is just clear/ignore existing sequence IDs and sync the messages between, for example, [timestamp of last received message - 1 minute, now + 1 minute], and deduplicate them by message IDs, and start using the new sequence IDs.

This is just a general solution. For details, I may write a doc on it later.

[summeryz]

如果 redis 宕机或者主从切换，那么 sequenceId 就会回拨，后面产生的 sequenceId 就会有重复？

It doesn't matter. By the way, all components of Turms servers are designed to work in extreme situations, which means you can crash Turms servers/clusters or their dependencies for fun, and Turms servers will recover automatically.

For this question, sequence ID exists to find out which messages are missing in edge cases. So, if your client detects a 0 sequence ID, what you need to do is just clear/ignore existing sequence IDs and sync the messages between, for example, [timestamp of last received message - 1 minute, now + 1 minute], and deduplicate them by message IDs, and start using the new sequence IDs.

This is just a general solution. For details, I may write a doc on it later.

seems to be a fantastic solution. I would be appreciated if you could provide more details about that