CQRS命令查询分离：架构设计

可视化演示

动态演示CQRS命令查询分离的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

读写分离思想

开奶茶店最怕什么？高峰期收银台前挤成一锅粥：顾客既要问“现在有什么新品”，又要在同一张纸上登记“一杯珍珠奶茶，去冰三分糖”。前者是读，后者是写，都挤在同一本账本上。排队的顾客越多，收银员越容易算错，后厨也越难跟上节奏。

CQRS（Command Query Responsibility Segregation，命令查询职责分离）说的正是把这两件事拆开：凡是会改变业务状态的操作用户——下单、改库存、发消息——都归为命令（Command）；凡是只读取、不改变状态的操作用户——查菜单、看订单、浏览商品——都归为查询（Query）。奶茶店的解决方案是：门口挂一块只读的菜单大屏，后厨只收写好的订单小票，两边不再共用同一张纸。

形式化地看，查询集合与命令集合互不重叠：

菜单大屏永远不修改后厨配方，后厨小票也不会被顾客拿来当菜单比划。这样，高峰期的点单、出餐、补货都能各自优化，互不拖后腿。

命令侧设计

后厨最怕顾客隔着窗口喊话：“我要一杯草莓波波，等一下，改成芒果的！”乱。聪明的店设计了一张标准订单小票：每个字都写清楚，后厨只处理小票。命令侧就是这张小票，它把“想做什么”固化成一件可以传递、可以执行的事。

在代码里，一个命令是一个对象，包含这次写操作的全部信息，例如 CreateOrderCommand 里有商品 ID、数量、用户 ID。命令处理器（Handler）负责校验、执行状态变更并把结果落地。命令侧强调“动作”，而不是“查询结果”，所以它不会返回一堆用于展示的领域数据，最多返回一个订单号或成功标志。

命令执行可以看作一次状态转移：

小票一旦写好，后厨只需要按步骤执行，不会有人中途问“现在锅里的奶茶是什么状态”。命令侧把写操作做成稳定、可重放、可追溯的流水线。

查询侧设计

顾客站到菜单大屏前，只需要看图片、价格和甜度选项，不用知道珍珠是几点煮的、加糖顺序是什么。大屏就是后厨的“只读投影”。查询侧专门为读而设计，目标是让用户一眼得到答案。

查询侧的查询模型可以是独立的 DTO 或只读仓储，字段按展示需求组织，比如“商品卡片 = 名称 + 价格 + 今日销量”。它不调用命令链，不修改任何状态，还可以加缓存、加索引。这样，即使几百人同时盯着大屏，点一下也立刻出结果，不会让后厨手忙脚乱。

查询响应可以抽象为一个函数：

大屏背后的数据不是临场去后厨现问的，而是由同步机制预先摆好的只读展示数据。再多人盯着大屏看，也不会让后厨停下来答话。

事件同步机制

奶茶做好后，出餐员不会跑到大屏前亲口告诉顾客“珍珠没了”，而是对着叫号器喊一声“188号好了”。这个广播就是事件。命令侧完成写操作后，不必等着查询侧回应，只要把事实广播出去，让关心这件事的人自己去更新。

命令侧发布领域事件（Domain Event），比如 OrderCreated、StockChanged；查询侧订阅这些事件并更新自己的只读模型。两侧不直接共用数据库连接，而是通过事件流同步。由于事件传播需要时间，系统通常是最终一致，而不是强一致——就像大屏晚半秒钟显示“珍珠已售罄”，顾客并不会觉得天塌了。

事件流可以表示为若干按时间排列的事件：

叫号广播之后，即使厨房和菜单大屏中间有短暂延迟，系统依然能正常运转。事件同步让奶茶店不用把后厨和菜单绑在同一把锁上。

物化视图

展示柜里的甜品样品，是提前做好放上去的复制品。顾客看到“今天有芋泥”，但芋泥桶还在后厨；样品不会因为客人询问而变少。物化视图（Materialized View）就是这个展示柜，它是查询侧提前“做好”的数据快照。

物化视图把事件流折叠成适合查询的表结构，比如把多个订单事件聚合成“今日销量”。它是有意冗余的数据，不需要查询时再扫描原始命令数据，所以读起来特别快。由于它是从事件推导出来的，可以定期重建，也可以在事件到达时增量更新。

物化视图是事件流经过投影函数后的结果：

样品柜放久了可能不新鲜，所以要有刷新策略；物化视图也可能短暂落后，所以要有重建和补偿机制。展示柜让顾客一秒钟得到答案，这正是它的价值。

传统CRUD对比

老式奶茶店，收银台上一本厚账，顾客问一句、点一杯，收银员都翻同一本账。单量少时方便，单量一大就排队。传统 CRUD 也一样，把同一个实体模型同时用来读写：Order 既要被 create/update 修改，又要在列表页被 read 查询。

读写逻辑揉在一个类里，查询要防写锁，写要防读堵，系统越往后越卡。CQRS 则不共用模型：一个写模型负责事务，一个读模型负责展示，互不牵制。当然，代价是多了一套模型和一套同步机制，所以不是所有系统都适合。

用读写比判断是否值得分离：

小奶茶店没必要上两套系统，一本账就够了；但到了写字楼楼下，每天几千人看菜单，菜单大屏和厨房小票就必须分开。CQRS 不是银弹，而是取舍：用多一套模型，换独立扩展和互不阻塞。

AI系统实践

分店开张后，白天客流全挤在菜单大屏前，晚上研发才在后厨试新品。大屏和后厨的节奏完全不同——这正是 AI 系统的日常。在 AI 系统中，模型训练、特征更新、数据回填是命令侧，它们重、慢、要资源；在线推理、推荐查询、用户画像读取是查询侧，它们轻、快、要低延迟。

CQRS 的思路是把两者拆开：训练集群专心写模型版本，推理服务从物化好的特征视图和模型索引中读。特征工程的结果可以做成物化视图，用户每一次点击行为作为事件发布，查询侧只读“特征视图 + 模型快照”，避免在推理链路里现场做复杂清洗。

查询侧的扩展能力可以简单表示为：

就像分店只扩建菜单大屏和展示柜，后厨保持原来的节奏。AI 平台上，模型训练慢慢跑，线上推理随时顶住流量洪峰，这就是 CQRS 带来的架构韧性。

AI 应用场景

Python 演示

# 简化 CQRS: 命令侧写库存, 查询侧维护物化视图import time class EventStore:    def __init__(self):        self.events = []     def append(self, event):        self.events.append(event)     def since(self, seq):        return self.events[seq:] class ProductCommandService:    def __init__(self, event_store):        self._event_store = event_store        self._db = {"apple": 10, "milk": 5}     def restock(self, sku, qty):        if sku not in self._db:            self._db[sku] = 0        self._db[sku] += qty        event = {"type": "restock", "sku": sku, "qty": qty, "ts": time.time()}        self._event_store.append(event)     def get_state(self):        return dict(self._db) class ProductQueryService:    def __init__(self, event_store):        self._view = {}        self._seq = 0     def sync(self):        for event in self._event_store.since(self._seq):            sku = event["sku"]            self._view[sku] = self._view.get(sku, 0) + event["qty"]            self._seq += 1     def get_stock(self, sku):        self.sync()        return self._view.get(sku, 0) if __name__ == "__main__":    store = EventStore()    cmd = ProductCommandService(store)    query = ProductQueryService(store)     cmd.restock("apple", 20)    cmd.restock("milk", 10)     print("查询视图:", query.get_stock("apple"), query.get_stock("milk"))    print("命令侧状态:", cmd.get_state())

1. event = {"type": "restock", "sku": sku, "qty": qty, "ts": time.time()}命令完成后发布一个事件，记录“发生了什么”。
2. self._event_store.append(event)事件写入事件流，命令侧不需要关心查询侧怎么读。
3. ProductQueryService查询侧只依赖事件流，不直接访问命令侧的 _db。
4. for event in self._event_store.since(self._seq)按序号拉取增量事件，避免重复处理。
5. self._view[sku] = self._view.get(sku, 0) + event["qty"]把事件投影成物化视图。
6. cmd.restock("apple", 20)模拟一次写操作，走命令侧。
7. query.get_stock("apple")模拟一次读操作，走查询侧物化视图。

常见误区

面试题