关于高并发下的阅读量，点赞量，评论量的实现方案总结

  作互联网应用时，常常会碰到关于商品或者文章等详情的阅读量，点赞量，评论量这些频繁更新的属性如何存储设计的业务场景；这两天恰好遇到顺便总结一下；

     方案一：

     以视频为例，在视频实体video中用countRead做为阅读总数；

•   用redis存放video的访问增量，key能够为“video_count_inc”+videoId
•   在访问video详情时redis访问增量+1，
•   定时任务读取redis中的增量更新到视频中，更新完后redis要减去这个增量（若是增量为0则删除这个key）；
•   查询视频时其阅读量要加上redis中的增量

    方案二：

    今天又想了一种实现方案，并且感受这种方案更好，对于方案一，假设这个视频的变更的属性特别多比点赞，阅读，收藏，转发等那每一项属性都要按方案一来一遍会很繁琐，并且重点是，通常咱们都会吧video详情放redis作缓存，那这样就会缓存不少冗余数据！因此方案二来了

• 将video详情转hash放redis（redis的hash结构能够直接对hash中的每一项操做，并且速度比对象快！）；
• 点赞，阅读，收藏，转发操做时判断redis中有无video详情，若是没有则需先将video加载进redis，而后将对应属性+1，同时要记录一下本次操做的时间戳；
• 定时任务扫描redis，将详情刷入数据库；若是操做时间戳距离如今的时间差x大于定时任务的时间间隔则无需更新，而后若是x超过xx天说明该视频没什么热度了能够将其从redis删除；（这一步若是要求高的话能够直接统计库里的数据信息）