这个问题是关于微服务以及如何在微服务的数据库架构发生变化时处理同步数据（特别是大量数据）。它与这个SO问题非常相似，但更多地关注数据同步方面。
例如，您有一个通过消息代理连接的用户 API 和聊天 API。您的 Chat-API 必须了解“一些”用户相关数据（例如：用户名、个人资料图片），但到目前为止还不是全部。因此，您的 Chat-API（因为它有自己的架构）会从 Users-API 监听有关用户创建和删除的消息，并使用数据子集更新其自己的用户表。 现在出现了一个新功能，突然要求 Chat-API 也知道用户是否购买了某种订阅。 User-API 提供了该字段，但之前它被忽略了。现在假设您有 100.000 多个用户，但您现在在 Chat-API 数据库中没有任何一个用户的信息。
以某种方式将所有这些消息从 Users-API 重新发送回 Chat-API 的明显解决方案，以便它现在还可以获取用户订阅的值并将其存储。但根据数据库的大小，这可能是一项荒谬的任务。
这是您在这里唯一的选择吗？或者我错过了什么？
切换到消息日志来解决这个问题。 RabbitMQ 是
消息队列的一个示例。发布者发出一条消息，该消息被复制到所有订阅者的队列中，当订阅者消费该消息时，该消息将从其队列中删除。 Kafka 是
消息日志的一个示例。发布者发出一条消息，该消息被写入主题。所有订阅者都指向该主题，该主题会跟踪每个订阅者的偏移量。当订阅者消费消息时，其偏移量就会增加。您可以将 Kafka 配置为永不删除消息。 您的问题是您使用了
消息队列，因此当您希望订阅者再次消费所有消息时，您必须再次发出所有消息。如果您使用消息日志，您只需重置订阅者的偏移量，订阅者将再次消费所有消息。 为了限制进入主题的消息数量，我强烈建议您配置 Kafka 进行压缩，这意味着 Kafka 只会保留具有相同 id 的最新版本的消息。当订阅者从头开始时，这也会加快速度，因为它将消耗更少的消息。
不要害怕在超过 10 万条消息的主题上执行此操作。我定期对包含数百万条消息的主题进行此操作。