京东春晚红包技术背后

无意间看到一篇关于春晚京东保障春晚发红包的解决方案，对关键点进行了整理。结合自身业务中遇到的一些思路，有感而写，技术是为了解决问题，做技术除了对相关的技术栈要熟悉外，从技术实现的业务角度出发，把相关联牵扯到的点能梳理出来，也是对思维能力的一种提升。

总结出的京东红包保障技术背后牵扯到的内容如下：

1、 时间要求

京东从1月3日领到任务，到1月31日的春晚，只有27天的准备时间。相比其他大厂，腾讯、阿里都是3个月，百度也是一个多月，留给京东的时间准备是最短的。而负责超大云计算力的“京东云”，是压力最大的。

2、用户、流量评估

春晚当天会有多少人来抢红包？答案是，最高可能有6亿。6亿是什么慨念呢？京东一年的活跃用户数是5.7亿，相当于这些人会在春晚4个小时之内全部涌进App。这个流量也相当于京东“618购物节”当天流量的6倍。

3、硬件难题
据京东云团队估算，他们至少需要新增1.5万台服务器，才能勉强应对。然而，当他们给8家供应商挨个打了一圈电话，得到的回答一模一样：现在马上春节放假，而且“芯片荒”一直没解决，你掏多少钱我们也没货。

4、解决方案

有技术大牛拿出了解决方案，分两步走：一是“极限腾挪”。假设，京东一共有5万台服务器，其中2.5万台用来处理前台的用户浏览、购物，2.5万台用来处理后台的会计、盘点等业务。当除夕夜几亿人涌进来领红包的时候，就从前台和后台共抽调1.5万台服务器，用来处理发红包；当抢红包高峰过去，再把这1.5万台服务器的算力还给前台和后台。
听起来很简单，对不对？这里的关键是，1.5万台服务器得借用多久？春晚四个半小时，是不是就借用四个半小时呢？不行。这么长的时间里，如果前台卖货和后台会计少了这么多算力，系统可能同样得崩掉。你抢到红包想顺便去京东下个单，结果发现下不了，那京东花这么大成本做的这波营销，效果就要大打折扣了。

最后的方案是“七借七还”，春晚发七次红包，就在每次抢红包洪峰的几分钟内借算力，然后马上还回去，下次发红包时再借。这就要求，1.5万台服务器，共计100万颗CPU核心，在两分钟之内切换工作内容，而且每颗CPU核心上的计算要平稳顺滑，不能抖动，技术上非常难。好在，京东云之前研发的“云舰”系统，刚好可以满足这个要求。

5、业务保障手段
不过，光是这样，还是无法应对春晚当晚691亿次的抢红包互动。接下来还有第二招，就是“提前预埋”。在我们抢红包的时候，服务器返给我们的其实是两类数据：一类是提前设计好的静态数据，包括引导栏、商品图片等等，一类是必须等你点抢红包按钮之后，实时计算的动态数据，也就是你抢到的具体金额。提前预埋，就是把可以提前做好的静态数据，事先传送到用户手机上的京东App里，这样在当晚抢红包的高峰时，服务器只需要传输很少的动态数据就可以了。不过这样做的前提是用户必须在春晚开始之前，打开京东App做一次系统升级。为此，京东可谓使出了洪荒之力，在春节前推出各种促销优惠活动，就为了让用户提前打开一次。
但就算是这样，也至少还有30%的用户，是在当晚抢红包的时候才现打开App。对这部分用户，怎么办？京东去买了很多CDN资源，也就是遍布全国各地的小机房节点，专门用来给附近的用户传送图片、视频等大文件。春晚当晚，就由这些机房节点向用户传送红包静态数据。这也意味着，所有资源必须提前一周部署到CDN节点上，不允许临时更改。做完这两步，京东还做了很多应急预案：比如，万一出现网络严重拥堵，那么就“丢卒保帅”，次重要的业务，比如某些监控数据，就不要了。再比如，红包服务器集中的北京和廊坊两座机房之间如果高速网线突然断掉，要在一分钟之内就要找到新的绕行路
如，红包服务器集中的北京和廊坊两座机房之间如果高速网线突然断掉，要在一分钟之内就要找到新的绕行路线，重新连接。还有，京东和运营商沟通，请求他们绝对不要春节当晚在机房旁边施工，以防一铲子挖断网线。京东还给各家手机厂商沟通，给手机应用商店多准备一点资源，以防春晚当天人们冲进去下载京东App,让应用商店宕掉，等等。你看，在我们顺畅抢红包背后，是一场艰苦而缜密的系统保卫战。在报道的最后说，京东用史上最“抠门”的方式完成了一次春晚发红包。而抠门的背后，是京东一直强调的“刀锋利润”：最低廉的成本，完成最极致最稳定的服务。