微博发布后，需快速推送给所有关注者

普通用户：采用Push模型，微博直接推送到粉丝缓存，保证实时性

大V用户：采用Pull + Push组合模型，优先推送活跃粉丝，非活跃粉丝延迟拉取，避免系统过载

缓存优化：使用分布式缓存（如Redis），结合数据压缩和定期清理，提升系统性能

异步处理：通过消息队列（如Kafka）异步推送，降低服务器压力

01.微博消息推送Feed流设计

0、需求说明

• ‌社交媒体中的feed是指一种数据格式，用于向用户推送最新的信息内容
• 当某个用户发布一条微博的时候，TA的所有关注者都可以接收到这条信息
• 那么怎么样设计一个合理的解决方案来让用户快速将他所发布的微博信息推送给所有的关注者呢？

1、普通用户的 Push 模型

Push 模型：

• 消息发布后，系统会主动将其推送给关注者，适用于普通用户，因为其粉丝基数相对较小，推送压力较低

• 普通用户的粉丝量较少，且大多数粉丝并非活跃用户，因此使用 Push 模型可以提升系统效率

• 微博发布后直接推送到粉丝缓存：

  • 每当普通用户发布微博，后台系统查询其粉丝列表，并直接将这条微博推送到粉丝的缓存中，保证实时性和高效读取

• 缓存管理：

  • 粉丝的缓存是有限的，常用的策略如 LRU 会将不常访问的内容清理出缓存，避免占用太多内存

• 批量操作：

  • 系统可以在合适的时间段进行批量推送，降低服务器压力，避免实时写入给缓存带来过大负载

• 通过这些手段，可以快速完成普通用户微博推送的流程，使得粉丝能够立即看到更新的内容

2、大V Pull + Push 组合

• 大V用户发布的内容可能影响数千万甚至上亿用户，无法通过简单的 Push 模型直接推送给所有粉丝

• 为此，设计上采用 Pull + Push 结合的策略

• Pull 模型：

• 用户主动发起请求，从服务器拉取他们所关注人的信息

• 适合处理大V用户发布的微博，因为大V用户的粉丝基数巨大，Push 模型下瞬时流量扇出巨大，无法承受

1）大V发布微博推送逻辑

• 活跃粉丝优先推送：

  • 当大V用户发布微博时，系统首先对活跃粉丝进行分批推送
  • 通过查询当前在线或活跃用户，将微博推送到他们的缓存中，避免瞬时推送所有粉丝造成系统负担过大
  • 这样，活跃粉丝能够立即接收到大V的更新

• 消息队列的异步处理：

  • 使用消息队列（如 Kafka 或 RabbitMQ）处理大规模推送请求，将消息写入到多个缓存节点中
  • 通过分布式架构，分批次将微博推送到活跃粉丝的缓存中，降低单节点负载压力

• 延迟推送与批量拉取：

  • 对于离线用户，不进行实时推送，而是将微博信息标记为待推送状态
  • 当用户下次上线时，再批量拉取这些微博
  • 这种方式减少了不必要的推送操作，并优化了服务器资源的使用

• 结合 Pull 模型：

  • 对于大V微博的非活跃粉丝，系统使用 Pull 模型，即用户刷新页面时，才从大V的微博池中拉取最新的微博信息
  • 这样可以避免系统因一次性推送大量内容而崩溃

2）大V Pull 模型扩展

• 动态推送策略：
  • 系统会根据用户的活跃度动态调整推送频率和优先级
  • 比如，当大V发布微博后，活跃粉丝会即时推送
  • 而对于长期不活跃的用户，可以降低推送优先级或等到用户主动拉取时才提供
• 拉取历史记录：
  • 大V的粉丝在登录或刷新页面时，系统从数据库中拉取微博历史记录，并按时间排序合并显示

3、缓存策略的优化

• 分布式缓存系统：
  • 引入如 Redis 的分布式缓存集群，保证微博数据在推送和读取时的高可用性
  • 特别是对于大V粉丝，数据分散存储在不同节点中，降低单个缓存节点的压力
• 数据压缩与定期清理：
  • 通过数据压缩和定期缓存清理，减少缓存占用空间
  • 对微博内容进行适当的压缩可以显著降低推送和缓存写入时的数据量，尤其在处理大V的海量粉丝时效果明显

4、大V与普通用户的组合方案

• 对于普通用户的微博发布，系统采用 Push 模型，将其微博内容直接推送到关注者的缓存中
• 对于大V用户，系统使用 Pull 模型，通过活跃粉丝优先推送、异步队列处理、延时推送和批量拉取等方式优化推送过程