在平时解决问题时，往往开始会一头雾水，在跌跌撞撞试错很多后，才勉强得到了合格的答案。但反观有些人非常有章法且迅速地就拿出了解决方案，有板有眼，既有说服力又预留了不少可能性。高下立判。

其实对于大部分常规问题，都是有套路可循的，别人动作快质量高，其实是基于套路的迅速复制，而且在大量复制的过程中，沉淀出了场景应变能力，将各类知识串起来，形成了高维度的能力代差。

本文开启一个系列，基于历史上对问题解决过程的复盘，我简单总结了一个套路。本文及后续的系列，会通过实际案例来对套路进行阐述及迭代。

不仅限于问题解决方案的探讨，将注意力往下沉，关注解决方案如何诞生。通过对元能力的持续总结，提升沉淀效果。

套路分为几步：

1. 第一性原理：通过连续追问直到问题根源，形成一颗树
2. 演绎回溯：从树的底部，往上逐层脑爆解决方案
3. 归纳：将脑爆方案分类梳理组合，得出优缺点
4. 带入变量：带入系统变量，通过优缺点变化趋势，找出最佳匹配
5. 更进一步：场景扩展延伸，形成应对预案，夯实系统扩展性

场景

榜单是直播非常重要的场景，这里承载了用户的存在感，主播荣誉感，直接影响商业变现。

榜单的本质是，某种积分规则在一定时间区间的排序结果，例如用户打赏排名，对花钱金额做排序；如主播营收榜，对主播挣的钱做排序。这种排序一般有一个时间区间限制，例如日榜、周榜。

每一次积分变化，都会对积分值做更新，产生新的排序结果。

冲突

一般为了持久化和可靠性，都会用数据库做存储。在积分变化时，对应的就是数据库的一次 update 操作：score = score + 增量，对一致性要求高的场景，还需要在事务中操作并写一次流水。

当某个大主播房间出现大规模送礼时，问题来了：

1. 热点问题：主播榜所有用户送礼对应的积分会写同一行数据
2. 写放大：当同时有很多个榜时，一次送礼会在榜单出现多次写

一般的系统设计，在送礼高峰下数据库很可能会被打瘫痪。如果强行做缓冲，那更新会延迟，损害用户体验。

怎么办？我们来套一下上面的框架。

解决方案

第一性原理

通过连续追问形成一颗问题树，直到无法拆解或无法解决。

演绎回溯

从问题树根部往上逐层提出解决方案，不设定约束进行头脑风暴：

归纳

基于头脑风暴的内容，整合出关键的解决方案。

方案之间往往需要组合，甚至是通过开关控制每个 feature 是否启用。

带入变量

方案清单出来了，但是该选哪一个？怎么组合？不通的场景需求，答案往往有差异，此时需要带入具体的业务场景变量，看优缺点如何变化，选择可以接受的那个。

如果主播寡头化明显，写打散的方案明显不行； 如果实时性、可靠性进一步要求提升，写合并方案必须要能应对，否则不能用。 如果用户进一步增长，分库分表肯定要搞。 如果业务逻辑复杂化，则批量写入的方案不可取。

根据实际变量选择最合适的就行，随着环境改变、基建升级，可以重新跑一次套路。总体来说，一般的场景，需要分库分表 + 写聚合配合进行，这两者本身可以做到彼此解耦合。

更进一步

在上面的变量带入中，有两个陷阱：

1. 有些变量拿不准
2. 环境往往有限制，例如资源有限

此时要在可扩展性上做余留。以下是举例。

总结

以上是基于榜单这个业务，对套路做的一次简单演练，要真实体验套路的威力，还是得挑一个问题动手试试。

高速成长 = 套路*重复次数。

另外，套路本质是思路和决策的加速器，一切的根基来源于朴素知识的格物致知。

所以基础知识的充实非常重要，这不是简单学习几个套路和方法论就可得到的。