小明和他的“淘金网

《从小白到架构师》系列试图以通俗易懂图文并茂的方式向读者朋友们介绍WEB server从单一架构到今天的大型分布式系统微服务架构的演变。看了三篇长文，你一定累了。今天，我们再来看看小明和他的“淘金网”的故事。

正是这样一个流媒体系统使得“陶金”的工程师们。com”分成两组一直吵到小明的办公室，

在做出最终决定之前，让我们比较一下推拉模式：

读取操作速度很快

逻辑复杂性

消耗大量存储空间

粉丝多的时候，就灾难了

简单的逻辑

节省存储空间

虽然拉模式乍一看有很多优点，但是Feed流是一个极其不平衡的读写场景，读请求数比写请求数高两个数量级的情况并不少见，这使得拉模式消耗的CPU等资源更高。

此外，push可以做得很慢，但用户很难容忍在打开页面时等待很长时间才能看到内容，因此pull模式的应用因其阅读效率较低而受到很大限制。

没必要仔细考虑。我们知道粉丝群的活跃用户是有限的，所以只能推给活跃粉丝，不能推新文章给那些几个月没启动App的用户。

进行计算，

鲁迅先生有句话说得好，3354，“有事，不能决定去雷迪斯。”因为它是一个缓存，所以Redis就派上了用场。

这种重复操作不影响结果。有个高大上的名字————幂等元。

需要在缓存中放置一个标志，以防止缓存崩溃。

缓存不足是计算机领域的经典问题。问你的CPU，它会告诉你答案。——如果一级缓存不够，做二级缓存。我只会在L1L2和L3都用完的时候使用内存。

这里有一个提醒：对于每一个额外的缓存层，应该考虑多一层一致性。是否做多级缓存需要仔细权衡。

提要是一个动态列表，列表的内容会随着时间而变化。传统的极限和偏移寻呼机会有一些问题：

这个问题的解决方案是根据上一页最后一个提要的ID拉下一页：

用Feed ID分页需要先根据ID找到Feed，然后根据Feed的发布时间读取下一页。过程比较麻烦，如果删除作为分页光标的Feed就更麻烦了。

我更喜欢使用时间戳作为光标：

使用时间戳必然会出现两个Feed时间戳相同的问题，让我们的寻呼机无所适从。

虽然我们已经将推送提要的任务转移给了MQ Worker，但是单个Worker仍然难以处理将提要推送给数百万粉丝的庞大任务，而且一旦进程中途崩溃，就需要从头再来。

我们可以将一个大的推送任务分割成多个子任务，并通过消息队列将它们发送给多个MQ Worker进行处理。