风险评估
生产前压力测试
使用JMeter做初期库存数秒杀，看看Redis以及订单接口是否异常或者超时，预估本次活动的访问流量，做上线上的验证。
生产可降级熔断
当瞬间秒杀产品库存太大，造成的Redis写暴增，可能造成线程阻塞最后写超时对于如上的异常，添加一个秒杀开关，大量异常时开关关闭停止一切秒杀活动，以免造成更大的损失。
由于订单还没有做sharding，当每秒写超过单机承受能力甚至影响正常的非秒杀产品下单该怎么办？对于如上的异常添加一个秒杀开关，如果超时或者异常切换到订单临时表中，启用定时任务将订单从临时表数据取出来然后调用下单接口更新到订单库。
监控
监控Redis调用性能，这边主要是看读和写的性能两个指标，看接口日志是否超时或者异常，查看公司埋点框架mertic统计是否有拐点，因为内存消耗很少通过Zabbix查看Redis集群CPU信息。
监控下单接口性能，看是否超时或者异常，统计booking库中失败或者未到order库的订单数，定时预警超过阀值自动发邮件通知相关人员。
观察订单master数据库的性能，目前master机器是32核128g内存，通过Zabbix查看其CPU内存以及IO使用情况，查看slave机器的延迟分发情况，因为订单信息显示都是从slave机器读取的。
鉴于目前数据库还不支持sharding，对于大量的insert只能通过增加CPU、内存和SSD来弥补，不利于横向扩展且代价也比较昂贵，后期还是应该完善订单库sharding，降低单点单库的数据更新压力，是个长远的策略。总之大胆尝试小心验证，多备预案服务做到可切换可降级，减少系统间耦合尽量将风险降到最低。
推荐一个架构类的会议
当业务量爆发增长时，高可用架构是永恒的话题。出行、电商、社交网络、房产，每个看似不同领域的技术架构都承受着相同的高并发冲击。滴滴、京东、Facebook以及链家，四个不同的行业巨头将在这里分享他们自己在对高可用架构的见解。