动态圈子功能优化分析

      很久没写过博客了，前几天与一个公司的技术总监聊天，聊到了一个我公司的一个产品的其中一个模块功能，这个模块功能就是动态圈子，是干嘛的呢？其实就是在这个平台上每个用户发了动态，然后平台上其他用户都可以看到这条动态，非常类似微博和朋友圈，跟朋友圈非常相似，但是没有朋友圈的限制只能是好友才能看到。

好了，废话不多说，现在问题来了，假如这个产品的动态圈子目前只有发布动态和读取最新动态列表并且可以看到历史动态的功能，要支撑到百万级别用户量和数据量的场景下，并且能够在只有2台机器的情况下，如何保障这个动态圈子可以正常并且快速的响应。

在此我想了一个方案，利用redis缓存机制，具体方案如下：

首先进行场景分析，在客户端有什么动作，一个是发布动态，另一个是刷新加载最新动态和加载更多动态，好，剖析了客户端场景，发布动态之后的内容可以进行缓存，因为内容不是经常变化的，所以可以使用redis缓存起来，此时 我给这个发布内容的业务模块 设置一个缓存

Key = 固定业务模块编号 +发布日期短日期(yyyyMMDD,如果后续活跃度高则考虑细分至小时划分等,如果是分布式则考虑在后面加一些标识进行区分和消息队列)

Value = 有序集合(sorted set)存储内容+ 时间戳(score)

然后每次当有新的发布动态内容时就加入到缓存中

然后怎么读取动态呢？

读取动态的API设计如下：

参数	是否必须
时间戳	默认当前时间戳

服务端读取动态的逻辑是

1.根据时间戳转换成功短日期

2.组装key = 业务固定编号+ 短日期

3.根据key去redis缓存中读取缓存

并根据score排序获取指定范围的内容数据集（如果客户端传递了时间戳，则再加上这个时间戳的序号为最大分数，否则使用当前时间戳为最大分数）

zrevrangescore key max min [withscores] [limit offset count]

4.拿到的数据返回，下次读取历史数据时只需要将上一次请求拿到的最后一条数据的时间戳当成参数传递即可拿到历史数据

整个从发布到读取的过程中完全不依赖数据库，而全部从缓存中读取。

取值会考虑到几种极端情况:

A.当前天获取的条数不足十条，则延到昨天查询,将最后一行数据的时间戳作为下一次加载更多的条件

B.隔几天没有数据或者半年都没数据，一样进行短日期递减,最多查半年的数据

如果上面没看懂则看下图：

现在发散下思维，假如有新需求过来了，需要在圈子动态上增加一个关注用户功能，并且被关注的用户发布的动态在那些关注用户查看的动态列表中高亮并置顶，这个时候应该如何做呢？

添加一个用户关注API

然后读取内容API修改一下如下图：

既可满足需求。

好了，方案写到这了，但这个方案是否经得起实际环境中百万级别以上的产品数据考验，需要实际使用才可以测试出。欢迎有更好的建议进行交流！