每秒30W次的点赞业务，怎么优化？

继承答星球水友提问，30WQPS的点赞计数营业，怎样计划?

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

• 吞吐量超高;
• 可以或许接管必然数据纷歧致;

画外音：计数有细小禁绝确，不是大题目。

先用最朴实的头脑，只思量点赞计数，可以怎么做?有几点是最轻易想到的：

• 必定不能用数据库抗及时读写流量;
• redis自然支持固化，可以用高可用redis集群来做固化存储;
• 也可以用MySQL来做固化存储，redis做缓存，读写操纵都落缓存，异步线程按期刷DB;
• 架一层计数处事，将计数与营业逻辑解耦;

此时MySQL焦点数据布局是：

t_count(msg_id, praise_count) 

此时redis的KV计划也不难：

• key：msg_id
• value：praise_count

好像很轻易就搞定了：

• 处事可以程度扩展;
• 数据量增进时，数据库可以程度扩展;
• 读写量增进时，缓存也可以程度扩展;

计数体系的难点，还在于营业扩展性题目，以及服从题目。

以微博为例：

• 用户微博首页，有多条动静list，这是一种扩展;
• 统一条动静msg_id，不止有点赞计数，尚有阅读计数，转发计数，评述计数，这也是一种扩展;

若是用最朴实的方法实现，多条动静多个计数的获取伪代码如下：

// (1)获取首页全部动静msg_id 
list<msg_id> = getHomePageMsg(uid); 
// (2)对付首页的全部动静要拉取多个计数 
for( msg_id in list<msg_id>){ 
         //(3.1)获取阅读计数 
         getReadCount(msg_id);  
         //(3.2)获取转发计数 
         getForwordCount(msg_id); 
         //(3.3)获取评述计数 
         getCommentCount(msg_id); 
         //(3.4)获取赞计数 
         getPraiseCount(msg_id); 
} 

因为统一个msg_id多了几种营业计数，redis的key必要带上营业flag，进级为：

msg_id:read 
msg_id:forword 
msg_id:comment 
msg_id:praise 

用来区分共一个msg_id的四种差异营业计数，redis不能支持key的恍惚操纵，必需会见四次reids。

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

• for轮回每一条动静，100条动静100次;
• 每条动静4次RPC获取计数接口挪用;
• 每次挪用处事要会见reids，拼装key获取count;

画外音：这种方案的扩展性和服从长短常低的。

那怎样举办优化呢?

起首看下数据库层面元数据扩展，常见的扩展方法是，增进列，记录更多的营业计数。

如上图所示，由一列点赞计数，扩充为四列阅读、转发、评述、点赞计数。

增进列这种营业计数扩展方法的弱点是Ｔ媚课要扩充营业计数时，老是必要修改表布局，增进列，很烦。

有没有不必要改观表布局的扩展方法呢?

行扩展是一种扩展性更好的方法。

表布局固化为：

t_count(msg_id, count_key, count_value) 

当要扩充营业计数时，增进一行就行，不必要修改表布局。

画外音：许多设置营业，会行使这种方案，利便增进设置。

增进行这种营业计数扩展方法的弱点是：表数据行数会增进，但这不是首要抵牾，数据库程度扩展能很轻松办理数据量大的题目。

接下来看下redis批量获取计数的优化方案。

原始方案，通过拼装key来区分统一个msg_id的差异营业计数。

可以进级为，统一个value来存储多个计数。

如上图所示，统一个msg_id的四个计数，存储在一个value里，从而停止多次redis会见。

画外音：通过value来扩展，是不是很奇妙?

总结

（编辑：河北网）

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