昨天晚上,跟我们的几名开发人员,去水吧开了个小小的会议,一起总结了一下过去一个月中的进度,并规划了下一步的开发计划.
期间,针对排名的问题,讨论了一下排名算法的设计.
而这个排名算法中的一个很重要的因子,就是点赞数.
之前针对点赞的功能,简单的讨论了一下,但是因为没有硬性需求,也一直没有进一步的讨论.而现在,为了这个排名算法,我们却是必须想办法实现它.
之前我们对点赞模块的设计中,一直感到困惑的,有如下几点:
- 因为点赞是写操作,在点赞很频繁的情况下,会有大量的写操作,严重影响了数据库的性能.
- 在前端界面的设计中,如何根据用户是否已经点赞,定制相应的按钮呢?
- 是将赞了一篇文章的用户,统一存到数据库中对应的表中的对应字段中,还是新建一个表,专门用于映射文章和点赞用户之间的关系呢?
- 如果是统一存到表中的对应字段中,那当用户想要取消赞的时候,修改这条对应的记录时,是特别麻烦的.
要解决这些问题,我们需要重新认识一下我们的APP的使用场景:
- 这是一个论坛类APP,不是跟QQ,微信一样的熟人社交APP
因为我们不是熟人社交APP,那么我们就不必跟QQ空间中那样似得,需要显示出都有谁点了赞.换句话说,就是我们的这个点赞功能,对我们来说,仅仅需要统计那个帖子,都有多少人点了赞,然后根据排名算法,计算出对应的帖子的排名.
这样的话,由于我们并不需要记录点赞的用户,上面的四个问题中,后两个都自然而然的消失了.
那前两个问题我们如何来解决呢?
我们先说第二个.
既然我们并没有记录点赞的用户,那我们如何知道用户是否已经对一个帖子点赞了呢?
要实现这个,我们可以利用移动端的缓存,如果移动端使用H5构建的话,可以使用LocalStorage.这里我们统一称之为缓存.
我们新建一个缓存块,用于记录一段时间中,用户已经点过赞的帖子的ID.这样在用户进入帖子详情页面的时候,我们就可以通过判断用户是否在这个缓存的列表中,来显示对应的点赞按钮.
这里我们用缓存记录用户一个周中点赞的帖子的ID.一般情况下,这个缓存不会太大,我们计算一下,我们的帖子的ID是UUID.一个UUID为36位.一千个才36000位,为4500字节,还不到5KB.况且,即使对于点赞党,在我们这种论坛类APP中,一个周也不可能点1000个赞.
为了保证这个缓存不会太大,我们需要定期清理,我们这里是一个周清理一次.
这里有一个问题,就是如果用户手动清理了这个缓存,那就会出现无法判断用户是否已经点赞的问题,而导致用户可能重新点一次赞.这个问题,影响也不大,所以我们并没有打算处理它.如果这是一个很重要的问题的话,我们可以通过将用户点赞过的这些数据保存到持久化设备中,如移动端的SD卡中,来解决这个问题.
第二个问题解决了,那我们如何来解决第一个问题呢?即大量写操作影响数据库性能的问题.
其实这个问题,我们同样可以通过缓存的方法来优化一下.
我们在用户点赞时,新建一个缓存块,在其中记录用户本次打开APP中,已点赞的帖子.然后,当用户退出APP时,如果有这块缓存,我们就将这个缓存中的数据,发送到服务器端.这样,因点赞引起的写操作相对就少了很多.也减少了发送空消息的接口调用的次数.
这样虽然相对优化了一些,但是极端情况下,仍然可能会有点赞操作过多的情况.
那我们如何解决这个问题呢?我们可以借鉴MapReduce的思想,将请求Reduce一下.
我们可以改写一下点赞的接口,让其将一段时间内收到的数据,合并一下,然后统一存到数据库中.
假设我们设置合并五分钟之内收到的数据,我们在这五分钟之内收到的如下数据:
用户A点赞的帖子:
帖子1 -1
帖子2 1
帖子3 1
帖子4 -1
用户B点赞的帖子:
帖子1 1
帖子2 -1
帖子5 1
帖子6 -1
用户C点赞的帖子:
帖子3 1
帖子4 1
帖子5 -1
帖子7 1
经过排序后,我们将其整理成如下数据:
用户A点赞的帖子:
帖子2 1
帖子3 1
帖子1 -1
帖子4 -1
用户B点赞的帖子:
帖子1 1
帖子5 1
帖子2 -1
帖子6 -1
用户C点赞的帖子:
帖子3 1
帖子4 1
帖子7 1
帖子5 -1
假设我们不合并的话,我们需要执行下面的语句:
update Forum set star = star - 1 where uuid = '帖子1' or uuid = '帖子4';
update Forum set star = star + 1 where uuid = '帖子2' or uuid = '帖子3';
update Forum set star = star + 1 where uuid = '帖子1' or uuid = '帖子5';
update Forum set star = star - 1 where uuid = '帖子2' or uuid = '帖子6';
update Forum set star = star + 1 where uuid = '帖子3' or uuid = '帖子4' or uuid = '帖子7';
update Forum set star = star - 1 where uuid = '帖子5';
三个用户,我们需要三次数据库连接,执行了6条SQL语句.
而我们将这五分钟之内收到的数据合并了一下的话,我们合并成如下数据:
帖子1 0
帖子2 0
帖子3 2
帖子4 0
帖子5 0
帖子6 -1
帖子7 1
对其进行排序并去掉点赞数为0的数据,得到如下数据:
帖子6 -1
帖子7 1
帖子3 2
现在我们只需要获取一次数据库连接,执行三条语句:
update Forum set star = star - 1 where uuid = '帖子6';
update Forum set star = star + 1 where uuid = '帖子7';
update Forum set star = star + 2 where uuid = '帖子3';
我们现在只需要更新三条数据,而没有合并前,我们需要更新七条数据.
在马太效应下,这个优化的效果会更明显.
在我们对文章进行排名后,用户看到的是都是排名靠前的优质内容,点赞的帖子也相对比较固定,如果我们在帖子列表中,给用户展示的是十个优质帖子,那我们五分钟之内,现在很可能只需要一个数据库连接,执行十条SQL语句就行了.
那具体怎么实现呢?
最容易想到的是,我们在点赞接口前,加一个中间层,让其缓冲并进行如上面所述的数据处理,然后五分钟之后,统一将数据传给点赞接口.这样的实现方式,理论说比较轻松,但技术上比较难实现.我们需要修改Tomcat的源码,添加这个功能.如果利用每个接口调用都是新建一个线程来处理的特性,可能还是比较容易实现的.
另一个肯定能行得通,但是相对麻烦一些的是,让点赞接口先将数据统一写到消息队列中,然后实现几个消费者,从消息队列中读这些点赞的数据,进行处理,处理完之后,再写到另一个消息队列中,然后这个消息队列的消费者再从中读出数据,并执行SQL操作.
如下图所示:
其中的中间数据处理节点,我们可以通过实现MapReduce来做.
这样就完成了点赞模块.
