kafka或java锁定用于银行帐户/钱包余额更新用例,选择哪一个可以获得更好的性能?

yhxst69z  于 2021-06-07  发布在  Kafka
关注(0)|答案(1)|浏览(485)

关闭。这个问题需要细节或清晰。它目前不接受答案。
**想改进这个问题吗?**通过编辑这个帖子来添加细节并澄清问题。

去年关门了。
改进这个问题
我正在研究一个基于java的用例(目标是为此制作一个微服务),在这个用例中,一个银行账户同时发生借记和贷记。我想用最少可能的sla使这个操作线程安全。在java中,有三种方法可以通过synchronised()块来实现这一点:readwritelock和stampedlock。但是对于所有这些选项,线程必须等待锁的可用性。因此,如果将来线程数增加,平衡更新api的sla也会增加。
有什么方法可以完美地减少这种锁依赖性吗?我想到了一个基于Kafka的设计。在我进一步讨论之前,我想知道这里的Maven对我的方法的看法。请评论/建议这是否是有效的解决方案。
我的方法是:
(1) payment producer将payment(比如信用卡100美元)作为主题发布到kafka(正确复制和配置以确保没有数据丢失)
(2) 在Kafka成功注册主题后,从发送者账户中借记($100),并向支付制作者发送成功交易确认。
(3) 现在支付消费者阅读支付主题(信用100美元)和信用货币(+100美元)到收款人帐户。
在这种方法中,生产者和消费者不等待任何锁,所以我相信即使生产者线程的数量增加,平衡更新操作仍然有效。
请评论哪个选项更适合这个用例?。

mepcadol

mepcadol1#

我对此的看法完全不同,当您希望记录的一致性时,异步处理的重要性是不必要的。不同的写入可能会有所帮助,但您也有可能失去数据的准确性。我将在数据层提出一种锁机制,即对写操作的乐观锁,从而确保在实现中具有select for update特性的元素。这不仅确保了数据的完整性,而且是一种简洁的方法,不需要大量的锅炉板代码,在我看来,不需要使用各种技术来解决您的问题。说到钱,乐观或悲观的锁是你最好的选择。
kafka和其他任何排队机制一样,只用于从应用程序转移负载,允许它们在其他地方排队,而不是在应用程序内存中排队,否则会占用堆空间。kafka和其他amqp协议在需要速度并且不必担心哪个线程在哪个记录上运行时是很好的。对于您的用例,我不确定这是否会解决您的问题,相反,它可能会给您的应用程序带来不必要的复杂性。

相关问题