时间戳

首页 > 解决方案 > 微服务规模架构中不同系统数据变化更新中央缓存

caching - 微服务规模架构中不同系统数据变化更新中央缓存

问题描述

我们正在构建一个微服务系统，新数据可以来自三个（或更多）不同的来源，并最终影响最终用户。
这个问题的系统目的是什么并不重要，所以我真的会尽量让它简单。请看附图。

数据可以来自以下来源：

  1. 后台站点：定义系统和用户配置。
  2. 主站点：用户与站点交互并执行操作的位置。
  3. 外部来源数据：例如可以提供有关用户的附加数据（补充信息）的合作伙伴。

这些服务是：

  1. 站点后台服务：为后台站点服务。
  2. 用户服务：服务于主站点。
  3. 导入服务：从外部来源导入附加数据（补充信息）。
  4. 用户缓存服务：与上述所有系统数据同步，并将它们组合成预先准备好的缓存响应。这样做的原因是因为主站点应该为数亿用户提供服务，并且应该以非常低的延迟工作。

主要思想是：

  1. 每个微服务都有自己的数据库。
  2. 每个微服务都可以扩展。
  3. 三个部分之一的每个数据更改都会影响用户，并应发送到缓存服务，以便最终反映在主站点上。
  4. 缓存 (Redis) 将所有数据组合到主站点的预先准备好的响应中。
  5. 每个服务数据更改都将发布到 pubsub 主题，以便缓存服务更新 Redis 数据库。
  6. 该系统应为大约 2 亿用户提供服务。

所以......问题是：。

  1. 由于用户缓存服务可以（并且必须）是可扩展的，例如，如果有两条更新数据消息在 pubsub 上等待，一条是旧的，一条是新的，会发生什么情况。如何只处理新消息并防止一个缓存服务实例将新消息数据更新到 Redis 并且仅在另一个缓存服务实例用旧消息覆盖它之后的情况。
  2. 还有一种情况，缓存服务实例需要先读取当前缓存用户数据，对其进行更改，然后才用新数据更新缓存。如何防止例如两个实例读取当前缓存数据而第三个实例用新数据更新它并用他们的数据覆盖它的情况。

  3. 是否有可能根据可以定期更改的多个来源预先准备响应？解决这个问题的正确方法是什么？

    系统架构图

标签： cachingscalemicroservicesgoogle-cloud-pubsub

解决方案

我将尝试解决您的一些观点，如果我误解了您的要求，请告诉我。

1）我相信你在问如何强制消息排序，旧的更新不会覆盖新的更新。消息的“publish_time”字段（https://cloud.google.com/pubsub/docs/reference/rpc/google.pubsub.v1#google.pubsub.v1.PubsubMessage）根据云发布订阅的时间进行协调服务器收到您的发布请求。如果您希望基于其他时间或排序机制进行协调，您可以向您的 PubsubMessage 或有效负载添加一个属性来执行此操作。

2）这似乎是一个普遍的同步问题，不一定与云发布订阅有关；我会把这个留给其他人来回答。

3）云数据流实现了类似于您所描述的窗口和水印机制。也许您可以使用它来删除冲突更新并在将它们写入后备存储之前执行预处理。 https://beam.apache.org/documentation/programming-guide/#windowing

-丹尼尔

推荐阅读