Grouk同步协议的优缺点与版本号设计取舍

[[Grouk同步协议的Folder加ChangeSet数据结构]]带来的优点相当明确：用户在线时大多数变更是直接推送下去的，比”通知后再拉取”的模式和服务器交互更少、更省资源；离线缓存容易实现，离线浏览体验较好；能保证终端和服务器的数据一致性；机制比较通用，可以适用于多个业务场景。但缺点也同样直接：本地客户端的实现逻辑比较重——这里有一个和微信思路的对照，微信走的是”轻客户端、重服务器”路线，而Grouk这套方案把更多状态维护和重放逻辑放在了客户端，团队自己也预估”估计我们在这里还得踩些坑”；另外这套机制只能保证同一个Folder内部的最终一致性，跨Folder的一致性不在保证范围内。版本号的设计上有一个刻意的取舍：客户端所在方案里版本号必须严格有序递增，因为要靠它来判断本地是否丢失了消息——如果版本号不连续，立刻能判断出中间缺了哪些变更、需要补拉取哪一段；相比之下Git采用的是”随机字符加链表”的哈希方案，那是因为Git本身要支持离线写操作（多个开发者可以在断网状态下各自提交、之后再合并），而Grouk当前没有这个需求，所有写操作都是通过服务器中心化完成的，不存在多点并发生成版本号需要事后合并的问题——这个对比说明版本号方案的选择不是”哪种更先进”的问题，而是完全取决于系统是否需要支持离线写：需要离线写、多点并发产生版本，就得用哈希+链表这类去中心化方案；不需要离线写、写操作统一走服务器，严格递增的整数版本号显然更简单、也更容易判断”是否丢失”。