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