第3步：数据同步三种方案——存储系统同步、消息队列同步与重复生成

按[[第2步：数据分类的五个特征维度，决定同步方案的设计空间]]分析清楚每类数据的特征后，就能针对性设计同步方案，常见有三种。存储系统同步是最常用也最简单的方式（如MySQL的主从/主主同步），优点是几乎主流存储系统都自带这套能力、用起来简单，缺点是这类同步是通用设计、无法针对具体业务数据特点做定制——比如MySQL不管要同步的数据量多大，通常只有一个同步通道，为了保证事务性，一旦数据量大或网络有延迟，同步延迟就会比较严重。消息队列同步靠独立的消息队列（Kafka、ActiveMQ、RocketMQ等）来做，适合无事务性、无时序性要求的数据——比如两个用户先后注册了账号A和B，即使异地同步时先同步了B再同步A，业务上也没问题，这类数据适合走消息队列；但如果是用户密码，用户先把密码改成m、又改成n，同步时必须严格保证先同步m再同步n，一旦顺序反了，最终同步过去的密码就是错的，这类对顺序敏感的数据就不适合用消息队列同步。重复生成则是完全不做数据同步，让每个机房各自独立生成数据，适合那些可以重复生成的数据，比如登录产生的cookie、session数据、缓存数据这类——反正每个机房都能按自己的逻辑重新造一份出来，没必要专门同步。三种方案的选择本质上是根据[[第2步：数据分类的五个特征维度，决定同步方案的设计空间]]分析出的数据特征来匹配：数据要求强顺序性/事务性就走存储系统同步，只要求最终到达、不要求顺序就走消息队列同步，能随时重新生成就干脆不同步、走重复生成。

结构图：

flowchart TB
  A["数据同步三种方案"]
  A --> B["存储系统同步(如MySQL主从/主主)"]
  B --> B1["优点：几乎主流存储系统自带，简单"]
  B --> B2["缺点：通用方案无法定制<br/>单一通道，数据量大或网络延迟时同步延迟明显"]
  A --> C["消息队列同步(Kafka/ActiveMQ/RocketMQ)"]
  C --> C1["适合：无事务性/无顺序要求的数据<br/>如新注册账号(先后同步顺序不影响正确性)"]
  C --> C2["不适合：顺序敏感数据<br/>如密码修改m→n，顺序反了结果就错"]
  A --> D["重复生成：各机房独立生成，不做同步"]
  D --> D1["适合：可重复生成的数据<br/>如cookie/session/缓存"]