写入取号与提交的判定边界
◆ 写入先向服务端取号，取号成功即视为已提交，此后各端的可见时刻差异不算故障。◆
如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 相关的坑WhatsApp网页版 里列得比较细，可以对照看看。 如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 相关的坑WhatsApp网页版 里列得比较细，可以对照看看。
各端不共享内存状态,一致性靠两条线索维系。
写入先到服务端排队取号,取号成功即视为具体提交完成。
其余各端通过增量拉取感知新序号,感知间隔决定观感延迟。
因此同一操作在不同设备上的出现时刻,本就允许有先后。
把这种先后当成故障,是最常见的误判来源。
判断是否正常,只需观察各端最终是否收敛到同一状态。
状态一致而时刻不同属正常,状态长期分歧才算异常。
增量感知的间隔与代价
◆ 感知间隔越短实时性越好，但握手往返与电量开销同步上升，两者是直接的对价关系。◆
增量拉取按游标推进,每轮请求只取尚未确认的区段。
间隔设为秒级时,观感接近实时,代价是长期占用连接。
间隔拉到分钟级可显著省电,但消息会成批抵达。
后台标签的间隔由浏览器决定,页面无法强制缩短。
这也是为什么切回前台时,常会看到一串消息同时出现。
这一取舍没有统一答案,取决于更在意即时性还是常驻开销。
设备常年在线时保留常驻更划算,偶尔查看则重载更省资源。
主从设备的职责切分
◆ 主设备独占密钥管理、名额分配与备份三项能力，从设备只做读写与展示，边界不随版本变。◆
密钥在主设备内生成,从设备只持有派生凭证。
从设备无法新增席位,也无法发起备份或恢复。
主设备离线不影响从设备读写,但席位操作会挂起。
这一职责切分解释了为什么设备管理入口只在手机端出现。
| 能力项 | 主设备 | 从设备 |
|---|---|---|
| 密钥生成 | 可用 | 不可 |
| 席位分配 | 可用 | 不可 |
| 会话读写 | 可用 | 可用 |
| 备份恢复 | 可用 | 不可 |
| 设备审计 | 可用 | 仅查看 |
冲突消解与迁移成本
◆ 冲突不做合并只按序号取后者，被覆盖的写入会在其余端短暂闪现，那不是串台。◆
两端同时修改同一条目时,服务端不做字段级合并。
后到者取得更高序号,先到者的修改被整体覆盖。
被覆盖的修改会在其余端短暂呈现,随后被新序号替换。
迁移成本取决于游标起点,新设备必然要经历一次回填。
- 记录两端操作时间,确认是否落在同一秒内。
- 比对该条目的服务端序号,高者为最终结果。
- 序号相同时,检查两端是否用了同一凭证副本。
- 凭证副本并存属配置错误,应收敛为单凭证。
- 最终一致
- 允许短暂分歧、由序号收敛到同一结果的一致性模型。
- 取号
- 写入前向服务端申请全局序号的动作，成功即视为提交。
- 分片上限
- 单次补齐可回传的最大区段数，超出部分不自动回填。
两台电脑同时登录会不会互相挤掉
[核心疑难] 并行登录本身合法，冲突只出现在席位耗尽时。
[底层诊断] 席位池容量固定，第三台以后进入排队，前两台不受影响。
手机上撤回的消息电脑还显示
[核心疑难] 撤回以增量指令下发，未拉取到指令前本地副本保留。
[底层诊断] 补齐完成后指令生效，副本被移除，重载可提前触发。
新电脑看不到半年前的记录
[核心疑难] 新设备按分片回填，超出上限的区段不会自动补齐。
[底层诊断] 需在界面上滑触发按需加载，或由旧设备导出另行保存。
一致性侧本日记录
◆ 10月23日 最终一致模型未变，同秒两处操作仍由序号裁定
◆ 10月23日 主设备独占密钥与席位，从设备仅读写与展示
◆ 10月23日 席位池容量固定，超额接入进入排队而非拒绝
◆ 10月23日 新设备按倒序分片回填，超限区段需手动触发
◆ 10月23日 旧设备在线时与新设备重复拉取，迁移后应登出
◆ 10月23日 并发写入不做字段合并，后到者整体覆盖
◆ 10月23日 被覆盖内容短暂闪现属替换过程，并非串台
◆ 10月23日 凭证副本并存会造成序号相同，属配置错误