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

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

本文彻底基于我的的有限的经验和了解，若是文中有什么问题还请你们一块儿讨论和指正。

微博热搜

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

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

但是，为何微博老是宕机，抵挡不住 xxx 明星出轨新闻流量？

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

电商秒杀

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

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

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

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

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

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

至于服务端，彻底能够只由一台服务器真正的处理用户秒杀请求，别的服务器能够不操做任何数据，只记录用户秒杀参与日志。

12306 抢票

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

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

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

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