Grouk同步协议的五个设计目标

在理清了[[多终端同步与传统IM投递的本质差异]]之后，Grouk团队没有直接采用XMPP等现成协议，而是自己设计了一套同步协议，设计之初就明确了五个目标，每个目标都对应一个具体要规避的问题。一，设计一种统一的客户端缓存数据机制，解决”接口数据做本地缓存需要针对每个接口单独设计”这个几乎所有App类应用都会遇到的重复劳动问题。二，实现消息的多终端增量同步、通过同步机制确保不丢消息，且必须避免流量浪费，所以要做增量而不是全量。三，消息同步和联系人/群组等数据的同步使用同一套机制——这不只是为了省事，更是为将来业务数据类型扩充做准备，一套机制能覆盖的数据类型越多，未来加新的数据类型时改造成本就越低。四，客户端数据能自修复，达到最终一致性——呼应了传统IM投递机制”客户端无法自修复、只能靠用户手动刷新”这个痛点。五，不解决冲突合并问题——因为Grouk的消息比较轻量，不需要像多人协作文档那样处理复杂的冲突合并，主动放弃这个能力是为了降低整体设计复杂度。这五个目标里最值得注意的是第五条：一份好的设计目标清单不只列出”要做什么”，同样要明确列出”不做什么”，主动划定能力边界——如果不设”不解决冲突合并”这条边界，整个协议的复杂度会因为要兼顾”轻量消息场景”和”重度协作编辑场景”两种截然不同的需求而大幅膨胀，最终可能哪个场景都做不好。