对于cqrs体系结构，在诸如交易系统之类的写密集型实时应用程序中，传统的 loading aggregates from database + distributed cache + distributed lock 表现不好。
演员模型（akka）很适合这里，但我正在寻找一个替代方案。我想的是使用kafka来发送命令，使用主题分区来确保相同聚合的命令总是到达相同的节点。然后使用 database + local cache + local pessimistic lock 加载聚合根并处理命令。这带来了三大好处：
聚合分布在多个节点上
没有用于查找中央缓存和分布式锁的网络流量
保存和加载聚合时不序列化和反序列化
这种方法的一个问题是，当使用者组重新平衡时，可能会在本地缓存中产生过时的聚合状态，设置较短的缓存超时应该在大部分时间都有效。
有人在实际项目中使用过这种方法吗？它的设计好吗？缺点是什么？请分享你的想法和经验。谢谢您。
1条答案
按热度按时间j2cgzkjk1#
伊姆霍Kafka会为你做这件事。你需要确保，如果网络足够快。在我们的项目中，我们对客户需求和购买的软实时做出React，并将kafka信息发送给不同的服务，这些服务执行业务逻辑。这很有效。在kafka broker中，网络级别的确认做得很好。例如，当一个代理节点崩溃时，我们不会丢失消息。
另一个问题是，如果您需要对所有操作进行任何类型的非常强大的事务性确认，那么您需要在设计时小心—也许您需要更多的主题、发送信息和所有需要的逻辑确认。如果您需要实现更多的逻辑，比如消息被其他外部服务处理时的确认，那么您可能还需要禁用自动提交。
我不知道这是否是你问题的完整答案。