为什么只读节点在数据存储复制的情况下称为只读？
Why are read-only nodes called read-only in the case of data store replication?
我正在阅读文章，https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs 说，“如果使用单独的读写数据库，它们必须保持同步”。我可以从拥有单独的只读副本中了解到一个明显的好处是它们可以水平扩展。但是，我有一些疑问：
- 它说，“更新数据库和发布事件必须在单个事务中发生”。我的理解是，不能保证更新后的数据会立即在只读节点上可用，因为这取决于事件何时被只读节点消费。我没听错吗？
- 必须先将数据写入只读节点，然后才能读取数据，即写操作也在只读节点上执行。为什么它们被称为只读节点？是因为写入操作不是由数据生产者应用程序直接在这些节点上执行的吗？而是通过一些无服务器函数（例如 AWS Lambda 或 Azure 函数）从主题（例如 Kafka 主题）中获取事件，只写节点已将事件发送到该主题？
- 数据是跨只读节点分片还是每个只读节点都有完整的数据集？
所有这些都有“视情况而定”之类的答案...
是的，通常，尽管某些实现可能会选择（尝试）通过更新以事务方式更新读取模型。但是，对于多个节点，您很快就会被迫学习 CAP theorem，因此在许多 CQRS 上下文中，最终一致性只是作为一项功能被接受，因为容忍它的收益通常大大超过损失。
我怀疑您引用的内容是指通过发布事件以事务方式更新 write 存储。即使这也很难实现，这也是事件溯源试图解决的问题之一。
是的。很明显 - 在这种情况下 - 数据必须先写入才能读取，但作为数据消费者的应用程序将它们视为 read-only.
两者都是有效的结果。通常这部分与应用程序无关，更多地委托给您选择的 read-model 基础架构（Mongo、Cosmos、Dynamo 等）的功能。
我正在阅读文章，https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs 说，“如果使用单独的读写数据库，它们必须保持同步”。我可以从拥有单独的只读副本中了解到一个明显的好处是它们可以水平扩展。但是，我有一些疑问：
- 它说，“更新数据库和发布事件必须在单个事务中发生”。我的理解是，不能保证更新后的数据会立即在只读节点上可用，因为这取决于事件何时被只读节点消费。我没听错吗？
- 必须先将数据写入只读节点，然后才能读取数据，即写操作也在只读节点上执行。为什么它们被称为只读节点？是因为写入操作不是由数据生产者应用程序直接在这些节点上执行的吗？而是通过一些无服务器函数（例如 AWS Lambda 或 Azure 函数）从主题（例如 Kafka 主题）中获取事件，只写节点已将事件发送到该主题？
- 数据是跨只读节点分片还是每个只读节点都有完整的数据集？
所有这些都有“视情况而定”之类的答案...
是的，通常，尽管某些实现可能会选择（尝试）通过更新以事务方式更新读取模型。但是，对于多个节点，您很快就会被迫学习 CAP theorem，因此在许多 CQRS 上下文中，最终一致性只是作为一项功能被接受，因为容忍它的收益通常大大超过损失。 我怀疑您引用的内容是指通过发布事件以事务方式更新 write 存储。即使这也很难实现，这也是事件溯源试图解决的问题之一。
是的。很明显 - 在这种情况下 - 数据必须先写入才能读取，但作为数据消费者的应用程序将它们视为 read-only.
两者都是有效的结果。通常这部分与应用程序无关，更多地委托给您选择的 read-model 基础架构（Mongo、Cosmos、Dynamo 等）的功能。