银行账户/钱包余额更新用例的Kafka或Java锁,选择哪一个性能更好



我正在研究一个基于java的用例(目标是为此制作一个微服务),在该用例中,银行账户同时发生借记和贷记。我想用最少的SLA使这个操作线程安全。在java中,有三种方法可以通过synchronized()块、ReadWriteLock和StampedLock来实现这一点。但对于所有这些选项,线程必须等待Lock的可用性。所以,若线程数量在未来增加,平衡更新API的SLA将增加。

有什么方法可以完美地减少这种对锁的依赖吗?我想到了一个基于卡夫卡的设计。在我进一步讨论之前,我想知道这里的专家对我的方法的看法。请评论/建议这是否是有效的解决方案。

这是我的方法:

(1) 付款制作人将付款(比如100美元的信用额度)作为主题发布到kafka(正确复制和配置以确保无数据丢失)

(2) 在Kafka成功注册Topic时,从发件人帐户并将成功交易确认发送到支付生产者。

(3) 现在支付消费者阅读支付主题(信用100美元)和将款项(+100美元)记入收款人账户。

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

请评论此用例中使用哪个选项更好?。

我对此的看法完全不同,当您想要记录的一致性时,异步处理的重要性是不必要的。被篡改的写入可能会有所帮助,但同样也有可能使您的数据失去准确性。我建议在数据层使用一种锁定机制,即写入时的乐观锁定,从而确保在实现中具有选择更新功能的元素。这不仅确保了数据的完整性,而且是一种巧妙的方法,无需大量的锅炉板代码,在我看来,也无需使用各种技术来解决您的问题。说到钱,乐观或悲观的锁是你最好的选择。

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

相关内容

  • 没有找到相关文章