咱们一同聊聊点赞系统的设计

随着社交网络的蓬勃开展，点赞配置逐渐成为了一个网站中无法或缺的配置。由于点赞配置不只可以让用户更直观地了解自己的视频、文章等外容被多少人认可，而且也优化了用户互动体验感。上方咱们来聊聊通用的点赞系统设计的打算。

1、点赞系统的数据表设计

在设计数据表的时刻咱们须要知道点赞系统须要成功的基础配置有哪些，点赞系统通常须要成功以下配置：

（1）用户可以点赞一个视频、文章、评论等外容

（2）用户可以检查一个等外容的点赞数

（3）用户可以敞开平等外容的点赞

针对如上所示的配置，咱们可以设计一张点赞记载表和点赞计数表来记载数据，如下是两张表的字段设计：

点赞计数表中记载了稿件（）被点赞和敞开点赞的总数，用作总的点赞数据展现；点赞记载表用于记载哪些用户在何时给哪个稿件点赞或敞开点赞。

2、系统设计

2.1 点赞数据写入的设计打算

点赞系统普通流量是比拟大的，特意是在某个稿件突然成为热点之后，那么流量就会突增过去，为了应答大流量，咱们在设计点赞系统的时刻驳回MQ来做削峰处置，整个点赞数据写入的流程如下所示：

（1）用户发送来点赞恳求，经过Nginx和网关转发到点赞服务上，点赞服务组装必要的数据（稿件的id、稿件用户id等数据）发送MQ信息，并发照应客户端写入点赞数据成功。

（2）点赞服务消费MQ信息，首先要保留点赞的数据，在保留点赞数据的时刻须要做一些逻辑测验上班，如下的流程图所示：

首先依据用户的id和点赞的稿件id查问数据库失掉用户的点赞记载数据，依据查问的结果分如下的状况剖析：

（a）假设没有查问到用户的点赞记载数据，那么间接保留用户的点赞记载到记载表中，将点赞计数表中的总的点赞数量加1。

（b）假设曾经存在了用户的点赞记载，那么就须要依据点赞的时期和点赞的举措进一步的审核

（b1）数据表中的点赞时期 > MQ中用户的点赞时期，说明或许存在重复的点赞，此时咱们这表MQ信息间接摈弃。

（b2） 数据表中的点赞时期 <MQ中用户的点赞时期，比拟数据库中的用户点赞形态能否为点赞，假设是点赞形态那么的MQ也不消费了，假设是数据库中形态是敞开形态，那么MQ信息咱们就须要消费，此时修正记载表的数据形态为点赞形态、点赞计数表中的稿件的点赞数量加1。

（3）点赞的数据写入缓存中从而减轻数据库的压力，点赞记载和点赞计数表的设计如下所示：

在redis中稿件的点赞总数可以驳回String类型的数据结构来缓存，点赞记载数据驳回Zset的数据格局来存缓存数据，这里须要给redis设置适当的过时时期。

（4）数据库的设计驳回读写分别的架构，经常使用canal来同步数据到从库中，一切的写恳求都打到主库上，一切的读恳求都转发到从库上。

（5）为了保障数据的分歧性，咱们驳回定时义务活期从数据库中同步数据到redis上，这样即使是redis在某个时期中写失败了，咱们经过定时义务的形式将数据补救到redis中。

敞开的点赞数据的写入流程也是一样设计的，只是最终逻辑是要点赞计数表中点赞的数量减1，敞开点赞的数量加1的，还要在点赞记载表中降级或许增加用户敞开点赞的记载，所以敞开点赞的这里就不在赘述。

2.2 用户读取点赞的数据

当点赞数据成功的写入缓存和数据库之后，用户读取点赞数据的流程如下：

（1）读恳求转发到点赞服务上之后，点赞服务优先查问redis中能否存在数据，假设有数据的状况下，间接照应数据给客户端。

（2）假设redis中无点赞数据，那么此时就须要到数据库中查问数据，此时读取数据库的时刻须要增加锁，防止短时期内由于缓存失效等要素形成少量的恳求间接恳求数据库从而造成数据库解体的疑问。数据库上查问的数据要缓存一份到redis中。

总结：

（1）点赞系统本文引见的是一种经过MQ+主从架构+redis的设计打算来应答大流量

（2）高并发下点赞系统的redis缓存介绍经常使用降级的打算，由于高并发假设频繁的删除缓存就会造成缓存的命中率降低，那么就施展不了缓存的作用

（3）主从架构中，主从的经过是经过canal来同步的，canal也是依赖与主库的binlog，假设主库由于系统的压力较大生成binlog速度慢了，就或许会出现从库和redis之间的数据不分歧性，此时定时义务可以做数据补救，修复从库和redis之间的数据不分歧性。