我有三个需要相互通信的微服务。Microservice-1 负责数据和数据库（他写入和读取）。我将为 Microservice-1 添加一个 redis 缓存存储来缓存数据。如果数据已经在缓存存储中，我想为其他 2 个微服务放置一个 redis-slave 以减少与实际微服务的通信。由于对数据的所有更新都必须通过 Microservice-1 并且他将始终更新缓存，因此 redis 复制将确保其他两个微服务也将获得它。当然，如果数据不在缓存中，它会调用 Microservice-1 获取数据，这会更新缓存。
用这种方法，我错过了什么吗？
这肯定适用于“晴天”的情况。
但有时会有风暴，在风暴中，有可能失去缓存的一致性（即 DB 和 Redis 在数据上存在分歧）。
例如，假设您让 Microservice-1 更新数据库，然后更新 Redis。如果更新 DB 和更新 Redis 之间发生崩溃会发生什么？
另一方面，如果您颠倒顺序（更新 Redis，然后更新 DB）怎么办？现在可以更新 Redis 而不是数据库。
这些都不是不可逾越的，但缺少一种确保更新 Redis 的 0 或 2 和 DB 的事务的方法，总会有一个时间窗口，其中一个发生变化，而另一个发生变化。在这种情况下，可能值得采用最终一致性（例如，定期扫描数据库并使用最近更新的记录更新 redis）。
作为对此的详细说明，带有事件溯源（CQRS/ES）的命令查询职责分离（CQRS/ES）方法可能被证明是有用的：Microservice-1 被分成两个服务，一个接受命令（更新请求），另一个处理查询。现在，命令服务不再更新 DB 中的一行，而是附加（在典型的 DB 中为 INSERT）一个事件，该事件描述了更改的内容。查询服务可以订阅这些事件并更新 Redis。其他微服务也可以订阅事件流并更新他们自己对 Microservice-1 状态的视图（可以以任何他们想要的方式重新混合）。