关于CQRS模式下读写分离数据库部署形式的架构疑问

CQRS的核心是读写职责分离，但它并没有硬性规定读写数据库必须是单机还是集群，具体部署形态完全由业务规模、可用性要求和性能需求决定：

• 小型项目、演示或低流量场景：可以采用单机数据库分别作为写库和读库，比如你提到的用SQLite处理写入、MongoDB作为读库的示例，这种模式复杂度低，足以支撑小规模需求。
• 生产级高可用、高并发场景：读写数据库都应该采用集群部署：
  • 写库（命令侧）：一般依托数据库集群的主节点（如Mongo Replica Set的Primary、MySQL主从架构的主库）承载写入操作，借助集群的故障转移机制保障写入的连续性；集群内的从节点是数据库自身的冗余节点，用于故障时的主节点选举，并非CQRS定义的读库。
  • 读库（查询侧）：同样可以部署为集群，比如由Mongo Replica Set的Secondary节点组成的读集群，或是专门的分析型数据库集群（如Elasticsearch集群），这样既能支撑高并发读请求，也能通过横向扩展应对流量增长，同时还可以根据查询需求对数据做结构化优化（比如反范式化），这也是CQRS读库的核心价值之一。

需要明确的是：数据库自身的主从集群同步是数据库层面的一致性保障机制，而CQRS的读写库同步是业务层面的（比如通过RabbitMQ、Kafka等消息队列实现），二者的目的不同——前者是为了数据库的可用性和数据冗余，后者是为了让读库适配查询场景，做针对性的数据模型优化。

内容的提问来源于stack exchange，提问作者Chris Bao