全程参加了过去11年全部双11的赵尊奎，在被问到“哪年最不好搞”时，秒答曰：“哪年都不好搞。”同样“全勤”的陈亮则表示：“14年之前，我们对于双11零点的信心，如果非要说一个数字的话，60%吧。”

但他很快补充：“不过2014年之后，这个数字就变成95%了。”

陈亮的信心，来自于当年支付宝压测体系的建立。这一次不再是手动调配置测单机了，而是创建出仿真环境让系统去跑，提前找出系统的问题并及时修复，以免在正式战场被打个措手不及。

“压测让双11开始从一个不确定的事逐渐变成确定的事，它极大地改变了我们对于双11稳定性的保障方式。”有“压测小王子”之称的郑洋飞说。

虽然2014年的压测仅覆盖核心系统，但这个体系已经帮了大忙。在双11之前的一个月里，它至少让一百多个致命的问题提前暴露出来。“如果其中有一个没有修复，我们2014年的双11肯定就挂了。”陈亮说。

【五】1%？或10%？

压测这一“压”，既压出和很多隐患，也压出了一个大问题：支付宝所用的Oracle数据库在压测之中“抖”了起来，性能眼见得触到了天花板。

2014正是移动互联网大爆发的年份。指数增长的移动支付比例势必带来比往年更汹涌的流量峰值，Oracle肉眼可见地支撑不住了。

再买服务器？成本吃不消，而且为了应对峰值而增添的机器，平日里没有用武之地，完全是资源的浪费。

还有没有别的办法？有的。阿里自研的分布式数据库OceanBase，从淘宝被划到支付宝后，已经沉寂了两年，正在焦急地寻找一展身手的舞台。

但是一听说是自研的数据库，业务满脸都是狐疑。跟交易和金额直接相关的数据库，只要错一个数据，后果就不堪设想，别说双11这么大的流量，即使平日，要不要用这个没经过验证的产品，也颇要斟酌一番。

先切1%的流量给OceanBase试试吧。这是大家争论了好一阵后得出的方案。

但是Oracle在压测中的表现显示，缺口不止1%，而是10%。

OceanBase说，我们来承接这10%。

10%，听起来不多，但双11的10%，相当于平日里的最高峰值。如果OceanBase能平安无事地接住这10%，就意味着它可以担起支撑支付宝日常运行的重任。

OceanBase必须证明自己有这样的能力。“我们找了淘宝的同学，协调了很多资源做了一个测试，主要校验淘宝订单的金额和支付宝交易金额是否能吻合。”DBA团队的工程师师文汇说，当时的方案很谨慎，如果OceanBase出现了问题，随时都可以切回来。