最近比较忙,已经两个多月没写博客了,分享一下专治强迫症的红点逻辑的服务端逻辑实现。

具体场景是例如一个图标,用户点击消失,如果距离用户上次点击有内容更新,则该用户则又出现红点。

容易想到的实现方式是记录每个用户的访问时间和内容更新时间作对比,如果没有用户的访问时间(说明是第一次访问)或者内容更新时间大于用户的访问时间,那么有红点,否则没有红点,数据结构使用redis的hash。这个方式已经比较简单了,不过我们可以有更简单的实现方式。

通过分析我们知道,最终目的是红点的显示与否,用户访问时间和内容更新的存取并不是必须的。所以我们可以使用redis的set记录用户红点显示的黑名单,用户初始都不在黑名单里面,用户查看会进入黑名单,内容更新会清空黑名单。这样判断逻辑就更简单了,如果用户在黑名单里面,则没有红点,否则就有红点。

比起记录访问时间的方式,我们少了访问时间和内容更新时间的存储成本,逻辑判断也更简单了。

最后,我们要注意的是对于点击返回不请求服务端的情况,客户端要作处理;用户发布内容是比查看更重的操作,所以发布清空set时可同时将该用户加入set;而set的key可以封装成枚举,做成多级的,这样就可以支持到更多更细的维度