CQRS架构中如何处理会改变系统状态的查询请求？

首先要明确CQRS的核心边界：命令负责修改核心业务状态，查询负责读取状态。你提到的缓存更新、后台任务调度属于基础设施/辅助业务状态的变更，并非核心业务状态（比如用户的订单、账户信息），这类场景完全可以在不破坏CQRS原则的前提下处理，关键是把状态变更逻辑从查询Handler中彻底剥离。

以下是几种通用且实用的解决方案：

1. 装饰器/拦截器模式：隔离查询与副作用 #

让查询Handler只做纯读取逻辑，把所有状态变更逻辑放到查询流程的前置/后置拦截器（或装饰器）中，保持查询的纯粹性：

• 缓存更新逻辑：在查询返回数据后，用后置拦截器对比缓存中的现有数据，如果返回的是新数据（比如通过哈希值、时间戳判断），则触发缓存写入操作。这属于基础设施优化，和核心业务逻辑解耦。
• 每日任务调度：在查询执行前，用前置拦截器检查用户当日是否首次调用（可以用Redis的过期key实现），如果是，则异步向任务队列发送调度指令，再继续执行查询。异步处理避免拖慢查询接口的响应速度。

伪代码示例（Python） #

# 纯查询Handler：只负责读取数据，无任何副作用
class GetStuffQueryHandler:
    def handle(self, query):
        return db.fetch_stuff_by_user_id(query.user_id)

# 缓存更新装饰器
class CacheUpdaterDecorator:
    def __init__(self, inner_handler, cache_client):
        self.inner_handler = inner_handler
        self.cache_client = cache_client

    def handle(self, query):
        data = self.inner_handler.handle(query)
        # 对比缓存数据，更新差异
        cached_data = self.cache_client.get(f"stuff:{query.user_id}")
        if cached_data != data:
            self.cache_client.set(f"stuff:{query.user_id}", data, ttl=3600)
        return data

# 每日任务调度装饰器
class DailyTaskSchedulerDecorator:
    def __init__(self, inner_handler, task_queue, redis_client):
        self.inner_handler = inner_handler
        self.task_queue = task_queue
        self.redis_client = redis_client

    def handle(self, query):
        today = datetime.date.today().isoformat()
        call_key = f"daily_stuff_call:{query.user_id}:{today}"
        # 原子性判断是否首次调用
        if self.redis_client.set(call_key, "1", nx=True, ex=86400):
            # 异步发送任务到队列
            self.task_queue.publish("daily_stuff_task", {"user_id": query.user_id})
        return self.inner_handler.handle(query)

# 组装使用：将装饰器叠加到纯查询Handler上
query_handler = DailyTaskSchedulerDecorator(
    CacheUpdaterDecorator(GetStuffQueryHandler(), cache),
    task_queue,
    redis
)

2. 事件驱动模式：查询结果触发异步处理 #

查询Handler完成纯读取后，发布一个查询完成事件（比如StuffQueriedEvent），由独立的事件消费者处理所有副作用：

• 缓存更新消费者：监听StuffQueriedEvent，负责将新数据写入缓存。
• 任务调度消费者：监听StuffQueriedEvent，检查用户当日调用记录，触发后台任务。

这种方式完全隔离了查询与状态变更逻辑，查询Handler不需要知道任何副作用的存在，完全符合CQRS的职责分离原则。异步事件处理还能避免查询接口因副作用操作超时。

3. 基础设施命令：显式触发非业务状态变更 #

如果某些副作用需要同步执行（比如必须确保缓存更新后再返回数据），可以先触发一个基础设施命令（注意：这不是核心业务命令，只是维护基础设施状态的命令），再执行查询：

比如API Handler收到get-stuff请求时：

1. 发送CheckDailyStuffTaskCommand，由命令Handler检查并调度后台任务（若符合条件）。
2. 调用GetStuffQueryHandler获取数据。
3. 发送UpdateStuffCacheCommand，由命令Handler更新缓存。

这里的命令仅用于维护非核心业务状态，不会修改用户订单、账户等核心业务数据，因此不违反CQRS的命令-查询分离原则。

关键原则总结 #

• 核心业务状态的修改必须通过命令，绝对不能在查询Handler中执行。
• 缓存、任务调度这类辅助状态的变更，要通过装饰器、事件、基础设施命令等方式与查询逻辑解耦，保持查询Handler的纯粹性。
• 优先使用异步处理（事件队列、异步任务），避免副作用拖慢查询接口的响应速度。

内容的提问来源于stack exchange，提问作者Farzin Nasiri