architecture - CQRS/事件溯源架构的最佳实践/存储选择

Question

任务。使用 CQRS/事件源架构构建可扩展的高负载应用程序。

让我们假设它是一个有很多在线用户的免费广告板。所以用户应该能够:

1. 注册/登录
2. 添加/更新/删除广告
3. 查看广告列表
4. 搜索广告
5. 一段时间后分析广告/从 Event Store 重现每个应用状态。

我的想法。

我会考虑使用类似的东西:

1. Cassandra/MongoDB... - 商店事件
2. Kafka/Redis/Hazelcast/RabbitMQ... - 事件队列
3. Elasticsearch + 缓存(例如 Redis)- 用于 View

问题。

1. 在每个步骤中使用一个对比另一个的优缺点是什么？或者将事件存储与队列结合起来(例如，使用 Kafka 作为队列和长期事件存储)？
2. 是否有人拥有经过验证的堆栈并可以分享 CQRS/事件溯源架构的经验？

Answer 1

对于我当前的项目，一个基于 Web 的 CRM 应用程序，我使用以下堆栈:

1. MongoDB 作为事件存储；
2. 我不使用事件队列；我不需要一个，因为我使用事件存储中的池；每个消费者都管理自己的状态。
3. 用于 View 的 MongoDB。