【问题标题】:How to scale? Make Rest API calls thousands times and update database如何规模化?使 Rest API 调用数千次并更新数据库
【发布时间】:2022-01-14 04:35:46
【问题描述】:
1. cron job started
2. create Entity1 and save to DB 
3. Fetch transactionEntity from DB
4. using transactions as transactionIds.
    for (Transaction id : transactionIds) {
        a. create Entity2 and save to db
        b. fetch paymentEntity from DB.
        c. response =  post request Rest API call
        d. udpate Entity2 with response
    }
5. udpate Entity1.

问题陈述 - 我使用需要按上面给出的处理的 cron 作业从 transactionIds 中的 db 获得 5000 多个事务。使用上述方法,而我的上一个循环正在进行,接下来 5000 多个事务进入循环,因为 cron 作业在 2 分钟内运行。 我已经检查了多个解决方案(.parallelStream() with ForkJoinPool / ListenableFuture,但我无法确定哪个是扩展上述代码的最佳解决方案。我可以为此使用弹簧批处理,如果是,如何做到这一点?步骤是什么来自上述步骤的 reader、process 和 writer。

【问题讨论】:

  • 与其尝试在 2 分钟内处理 5000 笔交易,不如更改设计,以防万一您开始收到 10000 笔交易,您的系统仍会处理它们。更好的解决方案可能是将所有 transactionId 保存在某种队列中并继续从队列和进程中读取。 Cron 作业会不断将 transactionIds 添加到此队列中。
  • @Smile - 队列的所有选项是什么,因为该服务在多个 pod 上运行。实际上,这些都是钱包失败的交易。需要尽早处理。
  • 你可以看看kafka,或者如果你在云上部署,云提供商有他们自己的植入物,比如AWS SQS等
  • 只需要使用java解决没有其他选择。

标签: java java-8 forkjoinpool


【解决方案1】:

解决此问题的一种方法是使用 Kafka 来处理消息。您可以增加 pod 的数量(希望您使用的是微服务),并且每个 pod 都可以成为消费者组的一部分。这将有效地消除代码中的循环,并且可以根据需要增加消费者以处理任何规模。

基于消息的方法的另一个优点是您可以有多种交付模式(至少一次,最多一次等),并且有很多开源库可用于查看主题的统计信息(消费和消费之间的滞后)在主题中生成消息)。

如果这是不可能的,

  1. 不应为每笔交易进行其余调用,您需要将交易作为批次发布。 API 调用的成本总是很高,因此较少的往返次数会使您完成循环所需的时间有很大差异。
  2. API调用前后不直接更新DB,可以改变循环使用 repository.saveAll(yourentitycollection) // 循环后只有一个 DB 调用,可以批量处理
  3. 建议您在不久的将来转向生产者-消费者战略。

【讨论】:

  • 你能从上面的一个中推荐 reader、process 和 writer 的内容吗?
猜你喜欢
  • 1970-01-01
  • 2016-12-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-09-24
相关资源
最近更新 更多