llm chat场景下的数据同步

背景

正常的chat/im通常是有单点登录或者利用类似广播的机制做多设备间内容同步的。而且由于长连接的存在，数据同步（想起来）相对简单。而llm的chat在缺失这两个机制的情况下，没见到特别好的做到了数据同步的产品。
llm chat主要两个特点：1. chat的输出过程是耗时的，并不是正常chat的完整回复；2. 业务形态不适合跨轮长连接。

原则和场景

llm的对话历史由于会直接影响模型的下一轮推理，同时用户在流式过程中的操作和模型输出的结果会有明显时间差。故形成一个简单原则：前端无错误时以前端为准，用户看到的必须和模型看到的一致。
场景上会有两大部分：1. 前端操作，对需要对模型输出进行覆盖；2. 后端数据比前端要新，需要择机同步给前端。这部分又有几种情况：a. 多点登录的情况下，另一个设备有新聊天；b. 推理被触发，但前端没有收到数据，随后恢复。恢复可能是流中和流结束后。

解决

整体话术遵循该DDD的定义。
整体上可以认为是redis主从模式的变种，本文的数据同步已经上线，方案可以直接拿来抄，问题不大。
总体上，redis的runid与对话的thread_id对等，offset与入库时间戳对等。广义的循环不变式是数据和时间戳一一对应，前后端均根据时间戳计算出diff，相互传递数据做更新。

场景1

在发生任何前端修改消息的操作时（停止推理、修改等）。此时遵循原则前半句。前端为master，后端为slave。数据是前端在上次时间戳之后有变化的消息。这些变化可以做为run接口的额外更新数据传递到后端，或者一个独立接口。
然后转换为后端master，前端slave，要求返回后端更新和此次时间