每一次前台的狂欢都有后台众多程序员的一把辛酸泪,双11.11是这样,除夕的抢红包活动肯定也一样,这简直就像虚拟世界的春运,也需要疏导分流。就此36氪电话采访了支付宝一位工程师(自称支付宝小二,负责项目管理、Android开发和测试等),当然微信红包的同学我们也想聊,但一时没touch到。
他告诉36氪,红包这个产品做了差不多3个月,牵扯到约10个部门,除夕当天200多人还奋战在红包前线,负责技术的小二当然也在。支付宝发布了这么一组数据,24小时,40亿元,收发红包总量2.4亿个。游戏+娱乐,除夕当晚8点,钱包界面点击量达到8.832亿次/分钟。2月19日凌晨,0点19分,马云的中文红包口令开启后,2998万人输入了近1亿个答案,1500万个“我”,2分36秒内发出了999999个红包。
支付宝小二告诉36氪,这次红包活动应对的压力规模比双11要大,相比之下双11的主要压力在资金结算和下单环节,而且后面的付款环节对支付宝产生的压力由于时间差是被离散掉的。抢红包的压力则集中在大规模登陆和发奖环节,抢红包的每一个整点都有流量的集体爆发,跟买东西不一样——刻不容缓。在现有的体系架构上,支付宝集成了各种限流措施,从网关、业务系统,缓存系统,数据库都做了限流处理。后台数百个开关控制着许许多多个技术预案,影响着流量往哪打,由哪些系统承接等等,能通过的阈值是多少,“任何一个开关错了可能都会引起线上的混乱”。
对用户而言,虽然登录的还是那个支付宝,在流量爆发的集中时刻也会有一些当时不太“着急”的功能会被暂时屏蔽掉,还记得抢红包的倒计时吧——每个用户的倒计时长是不一样的,这个时间差也是为了缓解访问压力(就是捉猫猫那个戳、戳、戳)做的微调,毕竟系统需要实时告诉用户有没有中奖。
被问及最奇葩的预案是什么?“那就是系统崩掉——让用户什么也看不见”,当然,该工程师说这个预案肯定是用不上的,“要不就打脸了”,但一定得有。
被问及打完这一仗的感言,小二说,“终于过去了...”