1.交易线与展示线拆分
背景：系统a需要为系统b提供一接口查询，用于计算打折后的活动商品价格
情况分析：
1.系统a定位为一个交易链路执行系统，主体为交易线提供服务
2.为系统b所提供的接口服务属于展示线的服务
3.新接口属于展示线调用量大，需要防止该接口影响到了现有交易线的接口
解决方案：
新接口划分独立包是为了和原来交易线的接口独立开，防止展示线的量过大，影响到了交易线。所以需要对现有系统a进行层级划分。独立一个war包，作为为展示层代码包，该包独立部署，有专门的数据源集群（redis）
折后价作为商品四级页展示元素，对应tps要求较高，预估为7w+/tps
故申请2c4G的redis10组。每组2W/tps
收获：
原则交易线优先级>展示线
交易线可用度>展示线
展示线允许少量错、脏数据
2.订单占用信息入db方案：
1.通过windQ解耦入db
2.设置一个单独的redis存储需要入db占用信息，后台起一个job定时取出该redis中的数据，批量入db
3.活动平台化的路由
背景：有多个类型的销售活动，活动通过活动类型 type 和 平台类型做区分，多类型的活动处理流程相同，但处理方式细节不同
解决：
1.定义公共接口，每大类活动类型编写实现类
2.定义自定义注解，在每种实现类上填写注解
3.定义工厂类，bean实例化后将各个实现类初始化并入工厂
调用时，根据注解进行调用
4.对于tps压力过大的系统考虑冷热分流
waf -> lua -> ngix -> jboss
lua层进行热品实时计算，对于超过阈值的商品或请求打上热标签，进行热处理，拦截流量
5.生产事故：web缓存了空数据
lua调用web前台子接口获取对应参数A下的a数据集合。
子接口内部逻辑
1.进Redis中取参数A对应的缓存数据a1
2.当1为空时回源solr查询对应的数据a2，并缓存到redis中，redis ttl:整点失效
3.后台会有job定时会往Redis中初始化a1
问题：步骤2中对不同的参数进入不同的solr core中进行回源，该操作是一连窜 if…else进行判断的，但参数A并不在if条件中，所以无法回源。
造成返回空数据，同时对于请求结果集又设置了cache时间，结果将空数据结果集做了缓存。导致Redis缓存到达失效前，该用户访问不到类目集合。
总结：
开发中，对于调用现成的子接口，尽量了解下子接口的实现逻辑，最低层度跟踪下一次执行过程，防止出现意料之外的问题。
对于重要数据的结果集缓存时要评估是否是异常数据，对异常情况下的异常数据，最好做到动态配置缓存时间。