1.善用缓存

• 理财业务，对于用户的收益数据，是实时去DB中查询的, 当DB发生故障时, 如果没有备份数据源，用户将看不到收益，如果使用redis做缓存，则可以作为备用数据，展示给用户，避免用户投诉
• 使用redis时，如果redis也挂了，需要考虑本地是否有数据，如果业务场景允许一段时间的脏数据，可以使用本地内存或者二级cache先扛住，如果业务不同意脏数据, 那需要快速失败，就直接
  告诉用户失败了，稍后再重试
• 通常用户看到失败后，都会不断的重试，反而给业务后台带来更大的压力，造成消息堆积雪崩， 针对这种情况必须做好流量控制，快速失败的方案，前后端都可以做控制. 系统设计重点要考虑异常如何处理.

2.主动重试

• 建立自动重试的机制，这样可以避免频繁的人工介入，尤其是针对服务极其不稳定的合作方，更需要如此，以减少我们的工作量.

3.必须优化掉DB慢查询

• 慢查询非常危险，必须要确认表中有索引，如果没有，当并发超高时，将会造成DB cpu飙升，程序无法响应，用户发现请求失败后，就会继续不断的发请求上来，最后服务雪崩了.

4.引入异步处理

• 对于耗时很长的任务，可以拆分成异步操作，先快速的返回给上游，让上游继续做其它事情，或者上游收到响应后，尝试查询几次后，就接着继续做后面的事情。
  从用户体验上比单纯的让用户一直等待好很多.

5.程序执行顺序

• 在异常情况下，程序的执行顺序会给系统带来问题，比如有处理重试任务的应用，如果代码设计时，是在系统重启后，马上处理失败的任务，则有可能把正常请求堵死，反而导致更多的失败发生.

6.清晰的日志

• 涉及到多个系统之间的调用时，需要有一个统一的字段，串联起整个交易，这样方便运维查获日志，定位问题，以及监控.

7.流量控制

8.降级开关

9.旁路

10.消息驱动的模式