去年我还没过来, 据说系统最后是没扛住双十一的大压力崩了, 今年提前好久开始准备, 底线是系统一定要扛住, 准备过程中列了下可能的风险点, 主要是
- 系统处理能力
- 用户流量出口
- 淘宝调用流量
- DB 写磁盘压力
挨个分析下
- 系统处理能力
这个反倒是小事, 我们自己的吞吐能力从来没出过问题 -
用户流量出口
今年年初开始就把静态内容放到了七牛上, 自己的流量压力小了很多. 不过盘算下到时候峰值可能还是会爆, 决定加带宽, 由于阿里云的奇葩定价策略, 单买 5M 带宽比买一台带 5M 带宽的虚拟机还贵, 于是我们就再继续买机器做分布式处理, 架构支持分布式就是好 -
淘宝调用流量
调淘宝接口居然还算的是外部流量, 这是之前没仔细考虑过的地方. 看了下大头在读写商品详情上, 这个功能到时候估计怎么加机器都会不够, 提前准备了关闭部分功能做降级的开关, 反正也不是核心功能, 到时候看情况关掉好了 -
DB 写磁盘压力
其实 DB 本身是没那么弱的, 我们的主库机器把内存选到了阿里云支持的最大内存, 只是阿里云的硬盘实在是太差了, 一旦有大量持久化操作写磁盘, 磁盘 IO 就扛不住了. 这个我们提前对 DB 里的冷数据做持久化, 降低内存里的数据大小, 避免磁盘 IO 被写死
双十一前一天, 系统的 UV 大概是平时的两倍, 下午继续慢慢往上涨, 最高的时候到了平时的快四倍, 因为今年我们自己的带宽没卡住, 调淘宝接口也没被限流, 来做设置的卖家搞完就走了, 没发生堵塞. 事实证明如果在你的处理能力范围内, 尽可能快的做完事情把人送走才是正确的解决办法, 把一堆人扣在这里慢慢排队处理只会让事情越来越糟糕, 交通枢纽应该都讲究怎么快的把人疏散走, 而不是把人垒在自己这 (说的就是你, 帝都的各种地铁站什么的)
淘宝官方说的是双十一前一天晚上十点接口限流, 我们吸取去年教训在我们的系统通知里说下午六点就暂停服务, 这也算是一个缓解的思路, 让一些人提前进来处理掉. 不过下午六点后 UV 还是明显在涨, 一群又一群赶着想在双十一捞一把的小白新卖家各种不看公告不管系统通知一定要作死的卡点来做设置. 到晚上快十一点淘宝正式限流, 我们这边也按预案暂停服务, 挂通知安抚
凌晨的时候淘宝限流有放开, 其实当天人就不多了, 坡就偷偷的把服务给开了, 但是暂停服务的通知还挂着. 上午估计一堆人发现了系统还能用, 又塞过来各种调, 淘宝那边也大量返回报错和限流提示, 看了下好像也没有想的那么夸张, 坡一狠心把重试次数加大, 居然就直接扛过去了
按系统通知, 是打算在双十一第二天中午十二点才恢复服务的, 结果双十一当天顺利的出奇, 晚上十二点系统也还开在那, 可惜没想到卖家折腾了一天后发现系统还可用就疯狂的做一键重开恢复平时的活动设置, 瞬间涌进来了平日高峰流量的快五倍那么多人, 系统和流量都没问题, 但是 DB 跪在了阿里云这不靠谱的磁盘上. 只能暂停服务, 继续挂通知, 来的快散的也快, 估计过了十来分钟大家看没戏就很快散了, 然后把服务重新恢复. 第二天白天人一直就不多, 一直观察到十二点也没出现预期的瞬间高峰, 可能还是大家发现系统是可用的, 没有卡点来做恢复操作. 双十一就这么有惊无险的过去了
习惯性总结下
- 系统的可扩展性很重要, 关键时刻如果能通过加机器搞定的事情就去加机器搞定好了, 多花的那么点钱完全不是个事
- 对自己系统的能力和客户的使用习惯要预估好, 我们最后还是托大了下, 没预料到双十一结束后的那个瞬时高峰
- 阿里云还是要给力才行, 据说今年会全面换成 SSD, 到时候先开个 DB 从库上去当小白鼠, 靠谱了就全切
当然, 每年都有各种二逼卖家改错价找上门哭诉或要挟的, 这种作死行为完全拦不住啊, 不看通知不看公告不看系统提示你们真的是来做生意的么, 然后每年继续还有二缺天猫卖家双十一当天跑过来说你们怎么不能用我要给你们差评, 啊叻天猫早就通知了双十一当天只有官方工具生效的好吧, 更二缺的天猫卖家发现双十一当天普通折扣不生效了就去改原价, 然后晚上不及时改过来第二天凌晨到早上被人超低价狂买然后跑来说你们软件有问题乱改价我亏了你们怎么赔我, 切爱谁谁吧, 淘宝城在文一西路上过去拉横幅要跳楼找马总解决吧