任务。使用 CQRS/事件源架构构建可扩展的高负载应用程序。
让我们假设它是一个有很多在线用户的免费广告板。所以用户应该能够:
- 注册/登录
- 添加/更新/删除广告
- 查看广告列表
- 搜索广告
- 一段时间后分析广告/从 Event Store 重现每个应用状态。
我的想法。
我会考虑使用类似的东西:
- Cassandra/MongoDB... - 商店事件
- Kafka/Redis/Hazelcast/RabbitMQ... - 事件队列
- Elasticsearch + 缓存(例如 Redis)- 用于 View
问题。
- 在每个步骤中使用一个对比另一个的优缺点是什么?或者将事件存储与队列结合起来(例如,使用 Kafka 作为队列和长期事件存储)?
- 是否有人拥有经过验证的堆栈并可以分享 CQRS/事件溯源架构的经验?
最佳答案
对于我当前的项目,一个基于 Web 的 CRM 应用程序,我使用以下堆栈:
- MongoDB 作为事件存储;
- 我不使用事件队列;我不需要一个,因为我使用事件存储中的池;每个消费者都管理自己的状态。
- 用于 View 的 MongoDB。
关于architecture - CQRS/事件溯源架构的最佳实践/存储选择,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42958640/