CQRS模式#

Command（写）： 标准化数据库，保证一致性 Query（读）： 可用 ES/Redis/宽表，优化查询性能

配合事件溯源（Event Sourcing）： 写入事件流 → 异步构建读模型

CQRS 全称是命令查询职责分离，核心思想是把系统的读和写拆成两套独立的模型。写端用规范化的关系模型保证数据一致性，比如标准的 MySQL 表结构；读端则根据查询需求做反范式化优化，可以用 Elasticsearch 做全文检索、Redis 做缓存、或者建宽表加速复杂查询。两边通过事件或消息队列异步同步数据。它和简单的数据库读写分离不同——读写分离只是数据库层面主从复制，CQRS 是模型层面的分离，读写各自有独立的数据结构甚至不同的存储引擎。这个模式特别适合读写负载差异大的场景，比如电商商品详情页读多写少，读模型可以针对性优化。但它引入了最终一致性的复杂度，简单的 CRUD 系统不建议使用。

追问方向：

• “读写模型怎么同步？”→ 写端变更后发布领域事件到 MQ，消费者异步更新读端模型（ES/Redis/宽表）；存在秒级延迟，需要容忍最终一致性
• “增加了什么复杂度？”→ 数据最终一致性（用户写完立刻读可能读到旧数据）、事件丢失需补偿机制、读写两套模型需要同时维护和演进
• “什么场景适合？”→ 读写负载差异大（电商商品详情读多写少）、读写模型差异大（写用关系型、读用搜索引擎）、需要独立扩展读写的场景；简单 CRUD 不适合

易错点：

• ❌ 所有系统都该用 CQRS——简单 CRUD 没必要
• ❌ CQRS 就是读写分离——CQRS 是模型分离