Kafka或Java Lock用于银行账户/钱包余额更新的用例，选择哪一个可以获得更好的性能？

Question

我正在做一个基于java的用例(目标是为这个做一个微服务)，其中并发借记和贷记发生在一个银行账户上。我想用尽可能少的SLA使这个操作线程安全。在java中，有三种方法可以通过synchronised()块、ReadWriteLock和StampedLock来实现这一点。但对于所有这些选项，线程必须等待Lock的可用性。因此，如果将来线程数量增加，那么平衡更新API的SLA也会增加。

有没有办法完美地减少这种Lock依赖？我想到了一个基于kafka的设计。在我继续之前，我想知道这里的专家对我的方法的看法。请评论/建议这是否将是有效的解决方案。

以下是我的方法：

(1) Payment producer将Payment (例如100美元的信用)作为主题发布到kafka (正确复制和配置以确保没有数据丢失)

(2)在Kafka注册Topic成功后，从Sender账户中扣款(- 100美元)，并向支付生产者发送成功的交易确认。

(3)现在支付消费者阅读支付主题(信用100美元)和信用货币(+ 100美元)到接收方账户。

在这种方法中，生产者和消费者不等待任何锁，所以我相信即使生产者线程的数量增加，平衡更新操作也将保持高效。

对于这个用例，请评论哪个选项更好？

Answer 1

我对此有不同的看法，当您希望records.Deffered写入的一致性可能会有所帮助时，异步处理的重要性是不必要的，但您也有可能失去数据的准确性。我建议在数据层使用一种锁定机制，即写操作上的乐观锁定，从而确保您的实现中具有select for update特性的元素。这不仅确保了数据的完整性，而且也是一种巧妙的方式，不需要太多的样板代码，在我看来，不需要使用不同的技术来试图解决你所面临的问题。当涉及到金钱时，乐观或悲观的锁是你最好的选择。

与任何其他排队机制一样，Kafka只用于传输应用程序的负载，允许它们在应用程序内存之外的其他地方排队，否则将占用堆空间。Kafka和其他AMQP协议是很好的，当你想要速度，而不是必须担心哪个线程操作哪个记录。对于你的用例，我不确定这会解决你的问题，相反，它可能会给你的应用程序带来不必要的复杂性。