Hello，大家好！我是你们的老朋友小米，一个积极活泼的29岁技术分享达人~ 今天要跟大家分享的是我最近在个人项目里遇到的一个有趣的优化案例——“推拉结合”。这个案例主要涉及用户在线状态的管理和消息推送机制的选择问题。如果你也正在为如何处理用户状态更新、推送机制优化而烦恼，那么这篇文章一定对你有帮助！让我们一起来看看，如何利用推拉结合的策略高效管理系统资源，优化用户体验吧！

历史方案回顾

在开发涉及社交功能的系统时，用户在线状态管理和消息推送一直都是技术中的难点和重点。之前的历史方案其实并不复杂，但它带来的系统负担和扩展问题逐渐显现。我们先来回顾一下传统的方案架构：

1. 服务器在缓存集群里存储所有用户的在线状态

在最开始，我们选择在缓存集群中存储所有用户的在线状态，目的很简单：确保状态可查。这种方式的优势在于当其他用户或功能需要查询用户在线状态时，能够快速地在缓存中找到数据，而不用频繁查询数据库。这在一定程度上减少了数据库的压力，并提高了查询效率。

不过，随着用户量和数据规模的增加，实时更新用户在线状态的操作频率逐渐变高，缓存的压力也随之增大。而且，更新每一个用户的在线状态涉及到很多跨服务、跨集群的操作，这就让系统的复杂度大大增加了。

2. 用户状态实时变更，任何用户登录/登出时，需要推送所有好友更新状态

第二个关键点是，用户的状态实时变更。当用户登录或者登出时，我们会把该用户的状态实时推送给所有好友，确保每个好友都能及时获取该用户的在线/离线信息。这种设计的初衷是希望用户的体验更加顺畅和实时化，但它也带来了一个问题，那就是消息风暴。

随着用户好友数量的增长，每次推送的消息量都呈指数级增长。比如用户A有50个好友，当A登录时，系统需要发送50条消息给这些好友。而当一个活跃用户拥有上千好友时，这个消息量就非常可观了。

3. A登录时，先去数据库拉取自己的好友列表，再去缓存获取所有好友的在线状态

第三个历史方案是：用户A登录时，系统会先去数据库拉取其好友列表，然后再根据这些好友列表去缓存中获取好友的在线状态。这看似是一个合理的步骤，但问题在于这个流程不够灵活，效率也不够高，尤其是在用户拥有大量好友时，查询和拉取的过程会导致一定的延迟，而且缓存命中的效果也并不理想。

消息风暴扩散系数

这里要引入一个新概念，叫做消息风暴扩散系数。这个系数表示的是一个消息发出后，可能被扩散成N个消息的过程。这个系数会随着业务需求、好友数量以及系统设计的不同而变化。比如，当一个用户登录时，系统需要将他的在线状态推送给他的所有好友，如果好友数量很大，这个扩散系数就会相应增大。扩散系数越大，推送的消息量就越多，也会给系统带来更大的负载。

在我们的历史方案中，好友登录时系统推送的消息量是非常可观的，尤其是当用户有数百上千个好友时，每次登录/登出都会引发大量消息的推送。这种高频的消息扩散不仅会拖慢系统的响应速度，还会对整个系统的稳定性造成威胁。

优化方案：推拉结合

了解了历史方案的弊端后，我们决定采用一种更加灵活的机制，那就是推拉结合的策略。在不同的场景下，灵活地使用推送和拉取机制，既能够降低系统负担，又能保证用户体验。

1. 好友状态推拉结合

我们第一个优化方案是在用户好友的在线状态同步时引入推拉结合。简单来说，我们将重要好友的状态推送更新，而对普通好友的状态则通过定期轮询拉取。

• 首页置顶亲密好友和当前群聊：这些是用户最关注的联系人，因此我们仍然保持实时推送。无论是亲密好友的状态变化，还是当前聊天群组中的群友状态变化，我们都使用推送的方式，确保用户能够第一时间看到重要状态更新。
• 其他好友：对于不在亲密好友和群聊范围内的好友，我们采用轮询的方式进行状态同步。用户每隔一段时间从服务器拉取这些好友的状态，减少实时推送的压力。

这种推拉结合的策略确保了重点用户的在线状态能够实时获取，而普通好友的状态则通过定期拉取的方式获取，减轻了系统的推送压力。

2. 群友状态按需拉取

群聊中的群友状态管理是另一个需要重点优化的场景。由于消息风暴扩散系数在群聊中可能非常高（特别是当群成员数量庞大时），如果采用完全的实时推送，系统负载会剧增。因此我们对群友状态的同步进行了特殊处理。

• 按需拉取：当用户主动查看群聊时，系统才会从服务器拉取群友的在线状态。这种方式避免了每次群友状态变化时都需要推送，减轻了系统压力。
• 延时拉取：如果用户频繁进入同一个群聊，系统可以在一个固定的时间窗口内缓冲状态变化，定期进行一次拉取，而不是每次都实时请求状态更新。

通过按需拉取和延时拉取的机制，群聊中的状态同步变得更加高效，也避免了大规模推送带来的性能瓶颈。

3. 系统消息/开屏广告推送

最后，我们针对系统消息和开屏广告这种对用户体验要求比较高的实时性内容，仍然采用推送的方式。这类消息的实时性要求高，而且不会像用户状态更新那样有高频的消息风暴，因此推送方式能够很好地满足需求。

• 系统消息：比如版本更新提醒、公告类通知，这类消息通常对所有用户生效，因此可以统一推送，确保用户第一时间接收到重要信息。
• 开屏广告：为了保证用户打开应用时的即时展示，开屏广告也是通过推送来确保广告的及时到达。

END

在这次项目优化中，我们通过推拉结合的策略，灵活应对了不同场景下的需求，既保证了用户体验，又大大减轻了系统负载压力。总结一下这个优化方案的亮点：

• 好友状态同步推拉结合：重点好友实时推送，普通好友轮询拉取。
• 群友状态按需拉取：通过按需和延时拉取，避免大规模推送带来的性能问题。
• 系统消息和开屏广告推送：针对实时性要求高的场景，采用推送确保及时性。

通过这种方式，我们有效降低了消息风暴扩散系数，优化了系统的稳定性和响应速度。如果你也在做社交类项目，遇到类似的推送和拉取困扰，希望今天的分享能够给你带来一些启发和帮助！

我是小米，一个喜欢分享技术的29岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！