揭秘：2018阿里双11秒杀背后的技术
在今天双 11 这个万众狂欢的节日，对于阿里员工来说，每个环节都将面临前所未有的考验，特别是技术环节，今天我们就一起来探讨下双11天量交易额背后的技术。
一、阿里双11秒杀场景
今日凌晨零点，2018年天猫双11全球狂欢节，根据现场实时数据，双11开场2分05秒破百亿，26分03秒破500亿，1小时47分26秒破千亿。
根据公开数据，在2017年双11购物狂欢节上，开场28秒钟成交额破10亿， 3分01秒成交额破百亿，9小时04秒破千亿。交易峰值32.5万/秒，支付峰值25.6万/秒，刷新全球纪录。同时诞生的还有数据库处理峰值，4200万次/秒。
几乎毫无悬念，今年天猫双11将刷新去年1682亿的销售记录，技术的各种峰值数据也将再次打破全球记录。
然而在这样的业务场景下，背后是靠什么样的技术来支持如此庞大的秒杀场景?
二、阿里双11背后的技术
1. 云计算
利用云计算弹性能力，支撑交易峰值每秒32.5万笔、支付峰值每秒25.6万笔的混合云弹性架构。
2. 分布式消息引擎
在双11当天实现万亿级消息流转。
3. Docker技术
交易核心应用容器化撑起双11交易下单峰值，解放资源的超大规模Docker化技术。
4. 在线交易的数据实时和离线计算能力
支撑全球最大规模在线交易的数据实时和离线计算能力，包括承载阿里巴巴集团核心大数据的离线计算平台，以及双十一保证每秒处理亿条日志的计算。
5. 阿里人工智能
在搜索、推荐以及客服场景下的创新应用，包括人工智能赋能的数千家品牌商家店铺的个性化运营和粉丝会员的精准营销。
6. VR技术
虚拟购物环境背后的VR技术。
7. 前端技术
应对前端极限挑战的淘宝直播首屏秒开，以及应用世界级开源跨平台移动开发工具Weex实现双11会场几近全覆盖，实现全网首屏渲染完美践行“秒开”体验。
8. 监控技术
千万量级监控项，PB级监控数据，亿级报警通知背后的技术。
9. 物流技术
菜鸟通过包裹预测、供应链入库、订单下沉、订单路由调度、电子面单及智能分单，以及末端小件员，涉及十亿级包裹的双11之战。
总之，双11将涉及：基础设施、存储、中间件、云计算、业务架构、大数据、认知计算与人工智能、交互技术等技术领域。
由于篇幅有限无法完全详细展开，我就以其中一个大家最关心的双11秒杀场景为例，贯穿这些部分技术的应用和设计思路。
三、双11秒杀架构设计思路
秒杀系统特点是并发量极大，但实际秒杀成功的请求数量却很少，所以如果不在前端拦截很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。
很重要的设计思路：将请求拦截在系统上游，降低下游压力。
1. 充分利用分布式缓存(tair+redis)
利用缓存可极大提高系统读写速度。
2. 充分利用消息中间件削峰
这里有相关的阿里消息中间件(Notify和MetaQ)，以及开源的(ActiveMQ、Kafka等)。
消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。
3. 前端设计优化
- 页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素，通过CDN来抗峰值。
- 禁止重复提交：用户提交之后按钮置灰，禁止重复提交，防止一秒钟内多次写入数据库。
- 用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流
4. 后端设计优化
- 服务端控制器层(网关层)
- 限制uid(UserID)访问频率：我们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层需要针对同一个访问uid，限制访问频率。
- 服务层：上面只拦截了一部分访问请求，当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。
- 采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。
- 利用缓存应对读请求：比如双11秒杀抢购，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力。
- 利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。
5. 数据库层
数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。