1.概念

CQRS全称：Command Query Responsibility Segregation ，中文名：命令查询与职责分离

2.什么是CQRS

CQRS 将系统中的操作分为两类，即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。而查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。

CQRS 的核心思想是将这两类不同的操作进行分离，然后在两个独立的「服务」中实现。这里的「服务」一般是指两个独立部署的应用。在某些特殊情况下，也可以部署在同一个应用内的不同接口上。

Command 与 Query 对应的数据源也应该是互相独立的，即更新操作在一个数据源，而查询操作在另一个数据源上

3.CQRS架构

先看一下 CQRS 的架构图:


在软件架构设计中，CQRS（Command Query Responsibility Segregation）模式是一个将命令和查询责任分离的策略。这种模式通过将数据更新操作和数据查询操作分开处理，以提高系统的性能和可扩展性。以下是对CQRS模式的深入分析和总结：

CQRS架构概述

CQRS模式通常涉及两个系统：Command系统和Query系统。Command系统负责处理数据更新操作，而Query系统则负责处理数据查询操作。当Command系统完成数据更新后，会通过领域事件通知Query系统，后者随后更新其数据源以确保数据的一致性。

CQRS带来的挑战

事务一致性问题

在CQRS架构中，由于Command和Query系统是分离的，事务的一致性保证变得更加复杂。Command系统更新数据后，需要通过事件通知Query系统，这个过程中存在时间差，可能会导致数据在一段时间内不一致。如果业务对数据实时性要求极高，CQRS可能不是最佳选择。 此外，一个Command触发的事件可能需要在Query系统中更新多个数据模型，如果更新过程中出现失败，将导致数据长时间处于不一致状态，需要外部介入解决。

查询模型设计

CQRS允许我们为查询功能设计专门的数据模型，这通常意味着需要为每个查询接口设计一个数据视图。然而，随着查询接口的增多，这种设计可能会变得难以管理。因此，需要按照领域驱动设计（DDD）的原则，将属于同一领域的查询集中管理，或将其独立为微服务。

CQRS的优势与适用场景

CQRS模式在领域驱动设计（DDD）中经常被提及，其主要优势在于分离了领域模型和查询功能，使得复杂的查询可以摆脱领域模型的限制，以更简单的数据传输对象（DTO）形式展现查询结果。同时，它允许开发者根据查询需求自由选择数据存储引擎。 然而，CQRS也引入了额外的复杂性，如分布式事务处理、消息中间件管理以及数据模型设计等。在引入CQRS之前，需要对团队的技术能力和现有架构进行仔细分析，并针对短板进行提升。

结论

如果现有系统逻辑较为简单，主要是CRUD操作，那么CQRS可能并不适合。但如果业务系统庞大，业务流程复杂，逻辑繁琐，CQRS可以帮助清晰地划分领域模型和数据模型的边界，提高系统的可维护性和扩展性。