Architecture 减少多实例服务的不必要工作

我有一个小服务，它连接到第三方web服务，获取一些信息并将其保存到mongo集合中。该服务感兴趣的数据是相当静态的，但在特殊情况下可能会发生变化（顺便说一句，这是足球时间表）。为了获得有关更改的通知，该服务每3-6小时检查一次，查看是否有比赛被取消或重新安排。新条目最终进入数据库，旧条目被丢弃（因为它们已经在集合中）

该服务还公开了一个GET端点，用户可以连接到该端点

现在，当我运行服务的单个实例时，这很好，但当我有多个实例时，这就不太好了（可能不是所有实例都每隔三小时查询一次数据服务并放弃大部分结果）

如何解决这个问题，我有以下想法：

• 使用某种领导人选举算法，只有领导人应该查询第三方服务
• 将服务分为两个部分：一个较小的服务将查询数据（仍然存在多个实例的问题），将结果放在消息队列中，这样就可以保证只有一个使用者接受并处理该结果
• 结合前两种思想：查询服务的领导者选举，消费数据的消息队列
• 使用某种分布式锁（我知道Redis/Jedis有一个解决方案），这样只有一个服务进行查询。然而，这感觉有点过分；添加Redis只是为了锁定就像…嗯
• 一个更好的、其他的想法，通常在这种情况下使用：-）

---

您能告诉我是否有解决此类问题的首选方案吗？

我会让事情变得简单，避免过于复杂。

---

只要保持WS响应时间，在再次调用WS之前，每个实例都应该检查DB自上次调用以来经过了多少时间。

但是当时间戳过期时，我认为应该只允许其中一个实例更新此时间戳。否则，每个到达的请求都会注意到时间戳已过期，需要进行新的更新。当时间戳的“宽限期”过期，并且实例再次从WS请求数据时，它将使用新的时间戳保留新数据，因此检查时间戳的其他实例将找到有效的时间戳。是，但是，如果在更新时间戳时的时间间隔[t1，t2]（其中t1是更新请求的开始，t2是更新完成时）中接收到多个请求，则除了第一个实例之外的其他实例也可以发出请求（在t1之后和t2之前）。另外，如果实例更新了时间戳，然后发出请求，那么它应该是在读/写时间戳值时执行的某种阻塞。这将确保只有一个实例读取该值。然后，实例可以更新时间戳，并向WSI发出请求。我认为，在这种特定情况下，您描述的场景中的双WS调用不会导致任何负面问题，而且在统计上，它对资源的浪费非常有限。正如您所说的，在更新时锁定表读取可能会得到解决：无论如何，这种行为比双重调用造成的后果要严重得多。是的，但每个API调用都有成本，无论是每个API调用的价格还是该调用引入的延迟。OP没有提到使用WSP时是否涉及付款为什么需要多个实例检查相同的数据？只是为了冗余？因为服务也有GET端点，所以我希望它具有高可用性。我真的不希望系统中出现单点故障。