【问题标题】:Best design with fault tolerant for retrieving updates periodically invoking an API具有容错能力的最佳设计,用于定期调用 API 检索更新
【发布时间】:2022-11-29 00:40:03
【问题描述】:

我是一个客户,比如 clientA,我需要每 15 分钟定期调用服务器 serverA,以便从 serverA 获取新的更新。

ServerA 只能公开一个接受 2 个参数的 API - 开始时间和结束时间,并返回新创建的帐户详细信息列表。

示例 serverA 公开:REST GET Api 看起来像这样

http://somedomainname.com/getAccounts?startTime={say currentTime-15minutes}&endTime={say currentTime}

回复:

{[
123,
456,
789
....
]} // List of account numbers that was created in serverA between supplied start time and end time.

作为 clientA,我必须定期(比如每 15 分钟)调用上述 API 并将更新存储在我的客户端数据库中。 什么是设计我的 clientA 系统调用 serverA API、检索更新并存储在我的客户端数据库中的最佳方法,考虑容错性,例如 serverA 因任何原因关闭或 clientA 本身关闭或任何其他意外错误场景。我也想避免重试机制中的重复调用。

很高兴听到您对此的意见。 我的客户端将使用 Spring Boot 框架用 Java 语言编写

【问题讨论】:

    标签: rest web-services architecture spring-rest system-design


    【解决方案1】:

    根据我的经验,如果可以更好地在系统之间同步数据,则使用推送而不是拉取方法。从 API 中提取更新,尤其是通过多个客户端提取更新会很快导致 API 性能出现问题。相反的推送方法可以更好地扩展——任何数量的客户端都可以订阅更新,更新的发布者可以在方便的时候发送它们。

    但是回到你的问题。 无论如何,您需要某种锚点来跟踪上次成功检索更新的时间。 在非常简单的场景中——用一个字段存储在数据库表中,例如LastSuccesfullAccountUpdateCallDatetime。如果调用成功更新此字段。如果通话失败,您不会更新它。下次您的客户知道从哪里开始。 在该表中更复杂的情况下,您可以存储用于检索帐户更新的所有时间段。 例如。

    ID StartTime           Success
    1  01-01-2021 00:00:00 true
    2  01-01-2021 00:15:00 false
    3  01-01-2021 00:30:00 true
    

    这些时间段可以预先生成,也可以仅由客户作为调用结果插入。

    然后,您可以将此 Id 链接到 Account 表,并根据需要对每个时间段执行对帐。 让我们为您在数据库帐户中拥有的 TimePeriod.Id = 1:123,456 但后来发现还有更多。您使用存储在数据库中的时间拨打电话,例如123,456,789 并且您看到应该添加 789。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2021-07-13
      • 2018-12-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-06-10
      • 1970-01-01
      相关资源
      最近更新 更多