4 从小白到架构师: Feed 流系统实战( 三 ) _生活百科

对于时间线这种集合式的还存在第二类缓存穿透问题，正如我们刚刚提到的 Redis 中通常只存储最近一段时间的 Timeline，当我们读完了 Redis 中的数据之后无法判断数据库中是否还有更旧的数据。
这两类问题的解决方案是一样的，我们可以在 SortedSet 中放一个 NoMore 的标志，表示数据库中没有更多数据了。对于 Timeline 本来为空的用户来说，他们的 SortedSet 中只有一个 NoMore 标志：

文章插图
最后一点：拉取操作要注意保持原子性不要将重建了一半的 Timeline 暴露出去：

文章插图
总结一下使用 Redis 做关注时间线的要点:

使用 SortedSet 结构存储，Member 为 FeedID，Score 为时间戳
给缓存设置自动过期时间，不活跃用户的缓存会自动被清除。使用「在线推，离线拉」时只给 Timeline 缓存未失效的用户推送即可
需要在缓存中放置标志来防止缓存击穿

一层缓存不够再来一层虽然 Redis 可以方便的实现高性能的关注 Timeline 系统，但是内存空间总是十分珍贵的，我们常常没有足够的内存为活跃用户缓存关注 Timeline 。
缓存不足是计算机领域的经典问题了，问问你的 CPU 它就会告诉你答案 —— 一级缓存不够用就做二级缓存，L1、L2、L3 都用光了我才会用内存。
只要是支持有序结构的 NewSQL 数据库比如 Cassandra、HBase 都可以胜任 Redis 的二级缓存：

文章插图
附上一条 Cassandra 的表结构描述：

-- Cassandra 是一个 Map<PartionKey, SortedMap<ClusteringKey, OtherColumns>> 结构-- 必须指定一个 PartionKey，顺序也只能按照 ClusteringKey 的顺序排列-- 这里 PartionKey 是 uid, ClusteringKey 是 publish_time + article_id-- publish_time 必须写在 ClusteringKey 第一列才能按照它进行排序-- article_id 也写进 ClusteringKey 是为了防止 publish_time 出现重复CREATE TABLE taojin.following_timelins (uid bigint，publish_time timestamp,article_id bigin,PRIMARY KEY (uid, publish_time, article_id)) WITH default_time_to_live = 60 * 24 * 60 * 60;

这里还是要提醒一下，每多一层缓存便要多考虑一层一致性问题，到底要不要做多级缓存需要仔细权衡。
还有一些细节要优化分页器Feed 流是一个动态的列表，列表内容会随着时间不断变化。传统的 limit + offset 分页器会有一些问题：