每秒30W次的点赞业务

答星球水友提问，30WQPS的点赞计数业务，如何设计?

可以看到，这个业务的特点是：

• 吞吐量超高;
• 能够接受一定数据不一致;

画外音：计数有微小不准确，不是大问题。

先用最朴素的思想，只考虑点赞计数，可以怎么做?有几点是最容易想到的：

• 肯定不能用数据库抗实时读写流量;
• redis天然支持固化，可以用高可用redis集群来做固化存储;
• 也可以用MySQL来做固化存储，redis做缓存，读写操作都落缓存，异步线程定期刷DB;
• 架一层计数服务，将计数与业务逻辑解耦;

此时MySQL核心数据结构是：

乎很容易就搞定了：

• 服务可以水平扩展;
• 数据量增加时，数据库可以水平扩展;
• 读写量增加时，缓存也可以水平扩展;

计数系统的难点，还在于业务扩展性问题，以及效率问题。

以微博为例：

来区分共一个msg_id的四种不同业务计数，redis不能支持key的模糊操作，必须访问四次reids。

假设首页有100条消息，这个方案总结为：

• for循环每一条消息，100条消息100次;
• 每条消息4次RPC获取计数接口调用;
• 每次调用服务要访问reids，拼装key获取count;

画外音：这种方案的扩展性和效率是非常低的。

那如何进行优化呢?

首先看下数据库层面元数据扩展，常见的扩展方式是，增加列，记录更多的业务计数。

（编辑：淮南站长网）

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