正在使用微服务实现系统。为了减少体系结构中"同一级别"实现的微服务之间的交互作用，一些微服务将在本地缓存由其他服务管理的表。假设是，微服务经常以"读取模式"访问本地缓存的表(a(，并且(b(具有相对静态的内容(即，更多的"查找表" vice vice vice a vice a vartactional content(。
本地缓存将使用服务间消息维护同步。由于内容应该是相当静态的，因此这不是一个重大的问题/工作量。但是，在微服务的启动时，本地缓存可能已经过时了。
我想在源表上实现某种滚动修订号码，以便具有本地粘贴者的微服务可以检查此修订号以避免重新同步事件。
这种方法有"最佳实践"？或者，鉴于每个微服务都由其自己的数据库支持(即没有共享数据库(？
在我看来，您不应该在启动时加载数据。维护版本可能很复杂。
缓存模式
通常，在微服务体系结构中，您可以考虑"高速缓存模式"。您不会在前面构建缓存，而是按需构建缓存。当您获得请求时，您会检查缓存，如果不存在该请求，则会使用最新值和返回响应更新缓存，从那里始终从缓存返回。好处是您不需要将所有内容都加载到前面。假设您有200个记录，虽然服务仅经常使用50个记录，但您正在维护可能不需要的额外缓存。
让请求构建缓存，这是DB点击一次。您可以在缓存上设置有效期，并再次将其构建。
如果您的数据完全是静态的(永远不会更改(，那么这种模式可能不值得讨论，但是如果您有一个可以更改的查找表，那么您应该使用此模式随着缓存到期时间的较长时间。维护版本可能是昂贵的。但是真的，您可能想如何实施。
https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside
我们遇到了同一问题，并通过使用LastUpdated时间戳比较(与您的版本名称名称相同的概念(暂时解决了它。每天晚上(当我们的应用程序趋于慢时(每个服务都会发布一条ServiceXLastUpdated消息，其中包括添加/编辑数据时的最新时间戳。订阅此数据的任何其他服务都会处理消息，如果有不匹配，则请求所有行都"触摸"，因为它是最后一个本地更新，以便它可以恢复同步。
对我们来说，目前，这还可以，因为新服务不会倾向于上网并在同一天使用。但是，我们未来的计划是，每当服务启动时，它都可以为每个订阅的服务发布一条消息，以表明其最新的缓存更新时间戳。如果"源"服务看到时间戳不是当前的，则可以发送更新以重新同步数据。这具有仅将所需更新发送到需要它的特定服务的优势，即使(至少对我们来说(所有订阅的服务都可以访问消息。
我们首先使用持久队列，因此，如果微服务的所有实例都关闭，则消息将在其队列中堆积。有两个问题使我们能够建立更好的东西：
1(显然没有解决"第一个启动"方案，因为没有队列在
中堆积的队列2(如果在存储排队消息或处理它们时出现任何问题，您最终会不同步。如果发生这种情况，您仍然需要像我们现在一样积极的机制来使事情同步。因此，似乎值得走这条路线
我不会说我们的方法是一种"最佳实践"，如果有一种方法，我就不知道。但是，我们这样做的方式(包括计划的未来工作(到目前为止，已证明可以简单地构建，易于理解和监视和强大的构建，因为我们很少见，我们得到了由同步的本地数据引起的事件。