整个系统分为三个部分：
原始数据
包装成商品后数据
客户持有列表数据
原有设计是每一次客户获取客户持有列表数据都会从包装成商品之后的数据获取数据（包装成商品之后原有的原始数据的属性会有可能被商城变更）
因为Dubbo的方便性让人不自觉的就忽略掉了远程调用的IO是很重的
原有设计时，每个客户第一次访问会从原始数据+包装后商品数据进行遍历，然后存入redis，接着以后调用直接走redis。
当天上线后，发现原始数据的系统直接出现了百万次调用且因为代码笔误全部打到了数据库上，灰度环境紧急回滚
事后分析可能有以下几个原因：
1、不知道因何系统无法从redis上读取数据，都直接开始了调用
2、因为原有的设计可能流量只会放大N倍，但因为配合其他系统上线，增加了两段逻辑，流量放大为3N倍
3、因为dubbo的超时重试机制，流量再次放大三倍，直接导致整个系统的崩溃
优化方案：
将远程调用转为本地调用
1、给dubbo接口增加Proxy，作为本地缓存
2、定期从原始数据平台拉去数据，保证数据的一致性
3、其他逻辑保持不变
这样将网络请求变为本地内存调用，比较好的解决了因系统流量放大导致的系统雪崩情况