第2步：数据分类的五个特征维度，决定同步方案的设计空间

[[第1步：业务分级三条标准，及标准冲突时如何取舍]]选出核心业务后，第二步要对核心业务相关的数据做特征分析，这些特征会直接决定后续同步方案怎么设计，常见维度有五个。数据量：包括总量和新增/修改/删除量，异地多活真正要同步的是变更量，变更量越大，同步延迟发生的概率越高，同步方案要针对性考虑。唯一性：指多个异地机房各自产生的同类数据是否必须全局唯一，比如用户ID如果两个机房各自注册出了同一个ID就会直接出业务错误——数据要求唯一，就要么只能在一个中心生成、要么设计一套全局唯一生成算法；数据不要求唯一，两地各自产生同类数据就没问题。实时性：指A机房修改的数据要求多长时间内必须同步到B机房，实时性要求越高，同步方案的复杂度越高。可丢失性：指数据丢了对业务有没有重大影响，比如登录产生的session数据是可丢失的（用户重新登录就能拿到新的），但用户ID数据是不可丢失的（丢了会连带丢失该用户所有关联数据，比如好友关系、账户余额）。可恢复性：指数据丢了之后能不能通过某种手段找回来，能恢复就意味着实际影响没那么大、可以相应降低架构设计的复杂度——比如用户微博丢了可以重发一条一模一样的内容（可恢复），密码丢了可以走找回密码流程重设（可恢复），但用户账号本身丢了用户直接就没法登录、系统也没有其他途径能把这个账号找回来（不可恢复）。这五个维度合在一起，构成了判断”这份数据该用什么同步策略”的分析框架，比如登录业务涉及的账号数据（要求唯一、不可丢失、不可恢复）就必然需要比session数据（可丢失、可重新生成）严格得多的同步保障。

结构图：

flowchart TB
  A["数据分类的五个特征维度"]
  A --> B["数据量：总量+变更量<br/>变更量越大，同步延迟概率越高"]
  A --> C["唯一性：是否要求全局唯一<br/>如用户ID(要求唯一)"]
  A --> D["实时性：多长时间内必须同步到位<br/>要求越高，方案越复杂"]
  A --> E["可丢失性：丢失对业务的影响大小<br/>session可丢失/用户ID不可丢失"]
  A --> F["可恢复性：丢失后能否找回<br/>密码可找回/账号本身不可恢复"]
  B --> G["共同决定该数据需要多严格的同步策略"]
  C --> G
  D --> G
  E --> G
  F --> G