问题：
在我们的电子商务网站中显示用户统计数据（例如：销售/购物分析等）时，我们使用扇入方法：系统中的某些流向 rabbit worker 触发事件，该事件汇总每个用户的统计数据在 MongoDB 中，因此大多数计算都是在插入和检索统计信息以显示时完成的，非常简单且非常轻量级。
当工作线程没有收到事件时，计数器开始“偏离”真正的 MySQL 计数。
计数器可能会因以下原因而漂移：
随着用户/订单/消息/等的数量不断增长，执行 MySQL 计数和连接以即时计算这些统计数据变得越来越不可扩展。所以我们不能这样做。 这就是我们选择扇入方法开始的原因。
以稳健且可扩展的方式克服这些“漂移”的最佳解决方案是什么？
【问题讨论】：
标签： design-patterns architecture distributed microservices
您需要的是故障覆盖策略。您应该通过 apache mq 或 websphere mq 之类的中间件向 rabbit worker 发布事件。此外，如果您无法将消息放入队列中，请将其备份在数据库中，每 x 秒轮询一次以检查未传递的消息以重试
【讨论】：
当工作线程没有收到事件时，计数器开始“偏离”真正的 MySQL 计数。
有趣的问题。我认为确保您可以从这些暂时性中断中恢复并且应该对这些统计信息的最新程度设定一定程度的期望并不难。
这样的系统需要的一些东西如下：
1) 请求被认为是成功的，不仅当它进行了它需要的任何更改，而且当它通知下一个系统有关该请求并返回一个成功的响应时。
2) 异步任务（如计算统计信息）必须首先将请求记录到本地持久队列，如果发生故障，它可以在启动时处理，然后以成功的响应响应。
3) 异步任务必须在启动时首先处理其持久队列。
4) 使用全局唯一的事务 ID，以便如果请求被提交两次，由于竞争条件，不会被处理超过一次。
所以现在让我们来看看这个。向电子商务服务发出请求。所述服务处理请求并将关于该请求的任何相关统计信息提交给快速响应服务。异步服务将负责将请求记录到持久队列并快速响应成功。出于性能目的，异步服务对于电子商务主机来说可能是本地的。然后，所述异步服务可能有一个线程来认真处理这些请求，方法是将它们处理到另一个服务以进行进一步处理......这样做的原因是为了保持电子商务服务快速而不是通过访问非-关键的外部主机。本地异步工作线程会将统计信息发送到下一个服务，该服务将再次记录它然后以成功响应......等等等等......希望链不超过两个或三个。所有请求都必须处理成功或记录（永久）以便以后处理。
所有这一切确保了所有这一切结束时的统计数据是准确的，如果不准确，很快就会准确。预计此类数据存在一致性延迟。甚至可以计算出数据的最新程度并将其包含在统计数据的响应中。
如果需要，可能会进行定期审计，比如每晚，根据另一个来源重新计算统计信息，在你的情况下，这个 mysql 数据库可能是所有请求的主记录。
我认为您已经接近这一点，因为您已经在使用
【讨论】：