信息流聚合类系统（如RSS阅读器）中数据同步的架构设计

需求

• 要求支持用户能够用一个账号在多台设备上同步数据（这要求同步状态存储在服务器上）
  1. 凡是需要在服务器存储用户状态数据的，需要评估存储容量的限制
• 要求用户标记为已阅的信息下次刷新不会再从服务器重复刷新
• 要求能够支持书签（或网盘类应用）的双向同步问题

基于时间戳的设计

主要思想：

1. 将信息拆分为基本的item单位，以每个用户可自定义的最小时间间隔作为桶
2. 每个桶里的item要么全部读完，否则下次还会重复更新下来
3. 优点：不需要额外的存储，但是每次会有计算开销
4. 要点：保证各个桶是整个数据集的disjoint的子集的union

基于每个用户消息队列的设计

1. 每个信息源里的item有按照时间顺序的唯一id编号，不要使用数据库生成id，使用领域自然id或对象hash id
2. 信息流的聚合相当于多队列聚合为一个队列，考虑某些支持消息序列持久化的中间件？
3. 优点：稳定可靠
4. 缺点：每个用户的聚合队列可能是一笔不小的存储开销
5. 要点：
   1. 当用户长时间不使用系统时，要求没有额外的存储开销，也就是说，每个用户的聚合队列可以JIT生成
   2. 可通过某种算法生成一个同步Token，相当于标记聚合后的信息流阅读位置的一个“书签”

书签（或网盘类应用）的双向同步问题

1. 在这类使用场景下，用户可用多个设备上传item（信息最小单位），（每个设备可视为一个信息源）
   1. 同时多台设备可获得一致的视图（或者叫“最终一致”）
2. 同样，服务器端需要给这些item生成id以便引用，不要使用数据库生成id
   1. 但是又可能需要这些item以更新顺序排序，因此需要持久化消息队列中间件
   2. 关系数据库不能解决这个问题，关系数据库里要对item进行排序必须增加事件戳列（不要混淆对象id和对象的更新顺序key 2个概念）
3. 如果客户端视图需要某种用户自定义的UI排序，不要把它作为一个整体XML文件进行更新；
   1. 相反的，每个信息item项增加一个“手工order_num”属性，将它与“对象的更新顺序key”相区别开来
   2. 如果设计时图简单，将所有的书签作为一个XML文件存储，则在多台设备上可能会遇到写操作的版本冲突
4. 引入“版本号”的概念，每次本地更新的上传均需要递增版本号，使用update_if_prev_version_match，许多Nosql类数据库均有这个设计