一次宕机的小讨论

记录一场因为线上并发量大导致的宕机事故讨论

现象

做了一个”消耗道具会获得相应积分,通过积分排名(所有服排名)领取排名奖励和达标奖励(达到多少积分可以获得相应奖励)”的活动。
玩家知道有这活动后，大批量玩家提前开始攒道具。
0点一到，活动开启，玩家狂点消耗,服务器，卒.

需求：要实时更新排行榜(玩家点一下排行榜取到的是最新的数据)
服务器架构：有一个总排行服S1，所有逻辑服Sn启动都连到S1，某一个服有数据更新时，Sm发送新数据到S1，S1再广播给N个逻辑服同步新排名数据

活动已经开了多期，但之前服务器比较少，还ok，这次有300来个服务器连着S1，每个玩家点一下，要向S1发1条消息，S1要向外面发300条消息，当玩家玩家集中点击的时候，S1向外发送消息阻塞，卒。

改需求，五分钟同步。策划不同意，GG。

多机处理，总排行服S1,加再S2,S3,S4…S10，来做为下一层的排行服，分别与数个逻辑服相连和S1相连。这样分流后，单服消息量减少(~~其实并不能减少多少~~)，阻塞会明显减少。

成本高，GG。

一边退一步,综合考虑。
这也是最后线上方案优化方案。
架构不变，但不实时广播，延迟5秒(对玩家和策划来说都能接受的范围)，把这5秒内收到的更新消息，处理后再以单帧1000条消息上限发给逻辑服。可以说成是把5秒内的消息去重再分批发送出去。

使用方案三优化后，的确也稳定了下来，没有宕过，消息去重的小优化，作用挺明显。