这个问题是关于微服务，以及如何在微服务的数据库模式改变时处理同步数据(特别是大量数据).它与this SO question非常相似，但更侧重于数据同步方面.
例如，您有一个User—API和一个Chat—API通过消息代理连接.您的聊天API必须知道some个用户相关数据(例如:邮箱，个人资料图片)，但到目前为止还不是全部.因此，您的Chat—API(因为它有自己的模式)监听用户创建和删除的消息，并使用数据的子集更新自己的User—Table.
现在，一个新的功能出现了，它突然要求聊天API也意识到用户是否购买了某种订阅.User—API提供了该字段，但它以前被忽略了.现在假设您有100.000多个用户，但您现在在Chat—API数据库中没有这些用户的信息.
显而易见的解决方案是以某种方式将所有这些消息从Users—API重新发送回聊天API，这样它现在也可以获取用户订阅的值并存储它.但取决于数据库的大小，这可能是一个荒谬的任务.
这是你唯一的 Select 吗或者我错过了什么？
你可以通过从message queue切换到message log来解决这个问题.
RabbitMQ是message queue的一个例子.发布服务器发出消息，该消息被复制到所有订阅服务器的队列中，当订阅服务器使用该消息时，该消息将从其队列中删除.
卡夫卡就是message log的一个例子.发布者发出一条消息，该消息被写入一个主题.所有订阅者都指向此主题，并且该主题跟踪每个订阅者的偏移量.当订阅者使用消息时，它的偏移量会增加.您可以将Kafka配置为永不删除邮件.
您的问题是您使用了message queue，因此当您希望订阅者再次使用所有消息时，您必须再次发出所有消息.如果使用message log，则只需重置订阅服务器的偏移量，订阅服务器将再次消耗所有消息.
为了限制主题中的消息数量，我强烈建议您将Kafka配置为压缩，这意味着Kafka将只保留具有相同id的最后一个版本的消息.这也将加快订阅者从头开始的速度，因为它将消耗更少的消息.
不要害怕用100K+消息做这个主题.我已经做了定期的基础上的主题与数百万的消息.