微博热搜、天猫秒杀、12306抢票，都是高并发，难点相同吗？

又是一年春运抢票时，12306 又挂了。同为高并发，微博热搜、天猫秒杀、12306 抢票有什么不同呢？

本文完全基于个人的有限的经验和了解，如果文中有什么问题还请大家一起讨论和指正。

微博热搜

「微博热搜」是一个典型的读多写少场景。读今日的热点新闻，写自己的微博评论。

作为一个后端开发，看到“读多写少”，第一反应就应该想到要加缓存。

可是，为什么微博总是宕机，抵挡不住 xxx 明星出轨新闻流量？

对微博来说，难点在于热点无法预测，在面对突发流量时，如何快速扩容。

电商秒杀

电商秒杀的大部分做法都是先定日子，然后上报要参与的秒杀商品，最后倒计时秒杀。

也就是说，什么时候会有秒杀活动，哪些商品会参与秒杀，这些数据在秒杀前服务端是都可以获取到的。

而这些数据，也正是关键的“热点数据”。

有了热点数据之后，服务端可以在秒杀开始前，先加载好相关热点数据的缓存，做好预热。

同时，在秒杀前做好相应的限流、扩容准备，已应对即将到来的突发流量。

秒杀的限流，可以从客户端开始做起，js 动态的 sleep 一会，延迟请求，让用户看一会秒杀的排队动画。

至于服务端，完全可以只由一台服务器真正的处理用户秒杀请求，别的服务器可以不操作任何数据，只记录用户秒杀参与日志。

12306 抢票

12306 抢票是一个类秒杀的业务，其核心为：查票、买票。

那么，12306 的秒杀和电商的秒杀有什么不一样吗？

电商秒杀：秒杀的对象是商品，一个商品的 sku 个数总是有限的，客户端直接将用户想要购买的 skuid 传给服务端即可。

12306 抢票：秒杀的对象是票。“票”是一个很特殊的商品，比如从杭州到北京，沿路会经过若干各站点。起始站点、车次、时间，各种不同的选择会组合出各种不同的结果，即便是“查票”这一个功能，服务端可能也需要大量的计算。不同的组合方式可能就是不同的下单行为，而秒杀，直接秒对应的商品即可。