如何实现一个海量计数系统

的时候，都去统计。每次有变更的时候，就去数据库里面进行selectCount，查询后将结果保存下来。之后每次有人访问这条评论，我们就直接返回，而不需要进行SelectCount。当然，每次都去SelectCount也是一个笨方法，我们为什么不每次有人点赞就+1，有人取消点赞就减一呢。我们将点赞数据的电话分为两种事件，一种是+1，另一种是-1。当然，这种做法的潜在风险点就是并发问题，例如原来的数据是5，突然来了两个+1的请求，由于他们并发执行了，最终的结果变成6。这种情况下我们需要加锁防止并发，或者让数据库帮我们实现。

仅是这样是远远不够的，我们如何面对突发的流量呢?例如突然爆发了一个热点事件，突然火了一条评论，可能10分钟之内就已经几万个点赞了。假如我们每次都去数据库更新，那势必效率会大大降低。为了应对这种突发性的流量，业内的解决方案大家其实都非常熟悉，不就采用消息队列进行削峰嘛。但是，这种突发性的流量容易造成MQ堆积，那么有没有什么好的方法呢?其实非常简单，本来我们要进行10次+1的操作，为什么我们不合并成1次+10操作呢。这样就能大大减少数据库的压力，我们一般有两场常见的实现方式，一种是对异步队列进行任务合并，另外一种是我们可以将计数存在缓存上，定期将数据刷到数据库中。

我们更多采用的是第二种方法，并且我们还会进一步优化，就是我们会将点赞的统计存放在Redis这种的缓存中间件上，然后再定期刷到磁盘上。对于这样的统计数据，冷热是非常明显的，基本上，采用采用这种方案，已经可以适用大部

（编辑：揭阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!