风险来源：
1.目前ESearch日常总日平均QPS接近1000(搜索接口QPS800, 价格接口QPS200)，根据运维流量估计，大促顶峰流量是平常的2-->6倍，也就是QPS接近2000-->6000。
如果我们取10倍峰值流量来作为我们的最大值的话，QPS也就是8000。
2.价格接口
对于QPS最大可以支撑8000，对于目前200*10 = 2000QPS大促总QPS是可以满足的。
3.搜索接口
场景 QPS 风险预估
日常总QPS 约800 低
大促总QPS 约2400-->4800 中
预估最大峰值QPS 约8000 高
3.ES已有机器集群
机器台数 支撑QPS
集群1 5（32核128G） 目前search Rate 1500 左右， 能支撑的最大Search Rate 5500左右
集群2 5（32核128G） 目前search Rate 1500 左右， 能支撑的最大Search Rate 5500左右
集群3 3（32核64G） 目前search Rate 200 左右， 能支撑的最大Search Rate 3000左右
从以上情况可知，ES集群这边能支撑的最大QPS大概在现在的4倍左右也就是3200
基于这种情况，我们预计需要一个备用ES集群，需要5台机器（32核128G）
集群4 5（32核128G） 可支撑的最大Search Rate 5500左右
4.ESearch应用模块
esearch-->search 扩一台，备一台。
esearch-->restapi 备一台
新增两台机器（32核64G）
5.Redis集群容量
ES聚合查询需要放在缓存中，对缓存的容量有一定的要求，目前使用了12G内存，总容量是36G，按照3-->6倍的量来预估的话，需要36G-->72G内存，扩容redis集群容量
双11 黑五 复盘
一.搜索技术团队前期准备
1.启动大会：制定目标，确定负责人。
2.梳理对外服务，整理已有服务契约，服务瓶颈点
获取业务方根据本年行情设定的访问量是多大。
来评估，我们搜索目前qps支撑量是多少？基于历史经历，往年大促是日常的几倍
来决定今年的流量。
然后基于流量来评估是否需要扩充机器，如果需要，则联系运维，去购买机器。
如果不需要，则也需要根据实际情况，来对关键服务来准备几台备用服务机器。
3.监控项：帮助研发更好的了解我们服务状态，更及时的处理问题。
3.1 机器性能状态：zabix 小米监控，监控机器各项性能指标，网络，cpu，磁盘等。
3.2 nginx流量路径监控 ：sentinal 可提供流控
3.3 重要服务接口调用频率：SOA链路追踪和监控。
3.4 ES集群性能指标： kibana 这块目前已经提供对应集群JVM和对应索引服务状态的展示数据。
3.5 运维Kibana：可以监控Nginx访问情况，采集访问日志。
3.6 分布式缓存中间件redis：监控空间，根据业务内容提前进行扩容，设置好的缓存策略。
3.7 canal binlog同步组件：prometheus+grafana监控组件 这个监控组件可以监控binlog同步状态，DB运行状态。
这部分，最好分配给团队对应童鞋进行监控，每个人分担一部分监控任务，定时巡检。
4.梳理自身业务，了解自身业务瓶颈点，更好的为大促做准备，大促趋近保守策略。
4.1 慢sql 提前梳理总结，提前清理。
4.2 依赖服务梳理
4.3 消息中间件 消息堆积 kafka
4.4 缓存击穿mysql压力大
4.5 redis 哨兵
4.6 关键服务熔断降级限流
5.压测
5.1 测试环境进行压力测试，整个服务链路压测计划。使用jmeter进行。制定压测方案。
5.2 如果可以的话，可以针对生产环境进行一波压力测试，逐步提升阈值，这样能够发现一些在测试环境发现不了的问题。
6.预演
6.1 对于既定的应急方案，我们需要提前做一遍，看看能不能达到既定的期望，否则，等到大促，就来不及了。
7.封板计划
7.1 接受到的需求与项目，在既定的时间拿到这个需求点的时候，就需要考虑业务方期望时间是否符合，避免在大促期间进行发版。
如果紧急bug需要发版，我们需要划清楚架构逻辑，回滚计划，再谨慎执行上线计划，验证，监控。
谨慎！！！
8.过程数据统计
我们需要统计本次部门本次大促期间对应的数据，作为后面同事评估来源。
二.大促进行时
1.值班人员安排
2.定时巡检任务
3.应急预案
三.大促结束时
1.进行关键问题的复盘
2.进行数据统计
四.思考
1.工作在平时，检验在大促
我们应该做好我们产品，做好设计，做好服务契约，做好业务架构。
