美团点评智能支付核心交易系统的可用性实践：https://tech.meituan.com/Trade-High-Availability-in-Action.html
今天看了一篇支付相关的博客，回头看了下我们的清结算系统，引发了一些思考。
1、消除依赖、控制依赖、弱化依赖
消除依赖：交易系统将订单数据推送给MQ，而清结算系统从MQ上拉取订单数据，这样的优点是交易与清结算消除了依赖，实现了交易与清结算的解耦。
控制依赖：MQ接收消息依赖交易系统，清结算系统拉取消息依赖MQ
弱化依赖：对于以上依赖关系，当MQ发生故障时，交易系统与清结算系统将无法通信，这样的话我们可以直接采用RPC调用通信，实现弱化依赖的效果，达到容灾处理。
2、事务中不包含外部调用
这里的外部调用，可直接理解为调用外部服务接口。当调用外部服务接口时，可能出现一些不稳定因素：比如有可能遇到外部服务挂掉引起调用接口失败，或者网络不稳定引起的调用接口超时，当遇到这种情况的时候我们一般采用重试机制，一般默认重试3次，当最后一次调用失败则报警，人工干预。
而事务中如果包含外部调用，必然会造成大事务，大事务会造成其他对数据库的连接请求获取不到，导致和这个数据库相关的所有服务处于等待状态，造成连接池被打满，多个服务直接宕掉。
解决方案：
排查各个系统的代码，检查是否存在RPC调用，HTTP调用，消息队列操作，缓存，循环查询等耗时操作，将这些操作移到事务外，理想情况事务中只处理数据库操作。
建议不要使用xml文件配置事务，而使用注解的方式。原因是XML配置事务，第一可读性不强，第二切面通常配置的比较泛滥，容易造成事务过大，第三对于嵌套情况的规则不好处理。
对大事务添加监控报警。
3、合理设置超时时间和重试次数
清结算系统的响应时间=内部处理时间+外部依赖超时时间*重试次数
清结算系统存在一些外部服务调用、消息队列操作等，而当这些依赖方发生故障时，如果超时时间过长、重试次数过多，或者系统长时间不返回，可能导致连接池被打满，系统宕掉；如果超时时间设置过短，则错误会增多，系统可用性就比较差。
解决方案：
超时时间=响应时间*1.5；
调用方的超时时间依赖被调用方的响应时间；
可默认重试次数为3；
4、处理慢查询
读写分离。读走分库，写走主库
优化索引。索引过多影响数据库写性能，索引不够查询会慢；调研所有查询sql，优化索引，页面查询，可设置默认值，走组合索引，DBA建议索引个数不要超过5个，组合索引字段不要超过5个
将查询分为实时查询、近实时查询、离线查询。实时查询可直接查询数据库，其他可通过ES实现一个查询中心，处理近实时查询和离线查询
不要出现大表。当一张表的数据量达到千万级别，效率将急剧下降，则可考虑分库分表
5、熔断
当依赖的服务不可用时，服务调用方应采用一些技术手段，向上提供有损服务，保证业务柔性可用。
解决方案：
自动熔断，
手动熔断，
6、限流
系统可能收到一些有意或无意的请求，如DDoS攻击、用户失败重刷。
流量控制中常用的算法：令牌桶、漏桶、计数器。可以使用Guava的RateLimiter来实现，其中SmoothBurstry是基于令牌桶算法的，SmoothWarmingUp是基于漏桶算法的。