事物中调用RPC
事物中调用RPC
RPC的设计和使用核心是design for failure，从这个角度介绍一下事物中调用RPC,谈谈我自己的理解。
1.场景
一个事物中可能包含N个RPC调用，可能因为各种原因，RPC会调用失败，而事物又不能一直等待，因此需要做系统上的涉及保证系统能正常使用。
2.服务使用方策略
2.1.超时重试
因为RPC请求肯定都是会设置超时的，如果不设置可能造成链路阻塞，但是超时的原因多种多样，有些可能仅仅因为网络抖动。
因此重试是必不可少的，对于不同的服务可以采取不同的超时策略。
-
不进行重试的
-
业务逻辑错
-
下游系统挂掉
-
-
进行重试的
- 网络抖动
。。。
可以通过业务异常进行区分判断
-
对实时性有要求的
- 请求重要度低的
对于这样的超时可以直接执行failfast，或者降级返回mock数据。
- 请求重要的
基本上是需要根据异常情况进行是否重试，或者事物补偿/人工处理，通常来说对实时性有要求的重试会在固定时间间隔发起。
- 对实时性要求低的
这样的重试可以采用指数退避的方式,即第一次等N 第二次等2N...这样的方式，不会对下游造成太大压力
2.1.1.如何重试
重试是Design for failure的重要部分
常用的方式有:
-
failover
-
failfast(不重试)
-
failBack
2.2.幂等设计
2.2.1.是不是需要幂等
首先要明确的是不是所有请求都需要做幂等操作的，因为幂等是需要代价的(通常都依赖存储层唯一键，和全局唯一id).类似Restful接口中DELETE GET HEAD等都不需要增加幂等操作，同样RPC也一样，对数据状态不影响的请求不应该过多的增加幂等。
2.2.2.如何保证幂等
通常来说RPC需要带一个全局id(可以考虑snowflake),在接收方将id保存到数据库中，如果id冲突说明已经有此id，即消息是重复的。
2.3.对某些服务进行服务降级
降级是针对相对不重要的服务的，如果是重要服务是不能进行降级的。降级是从整体负载考虑的，因此就需要为服务定优先级，确定优先级之后才能合理的进行降级分配。
2.3.1.对非核心链路服务降级
降级一般有两种方式，自动方式和手动方式，这边主要聊一下自动方式。
2.3.1.1.自动降级
通常来说自动降级需要失败记录的配合：
-
超时降级
-
失败次数降级
-
故障降级
-
限流降级
等等。。。
2.3.1.2.降级方式
一般来说的降级方式是进行mock返回
-
force:return策略:直接返回mock数据
-
fail:return策略：调用后触发重试上限之后返回mock数据。
2.3.对不重要的服务进行熔断
降级是从整体资源分配的考虑上来考虑的，大多数是因为为了应对即将到来的大流量或者弹性的hold住大流量。而系统往往还会遇到下游系统故障导致无法正确返回的问题。这样就需要增加熔断机制，来保证不会造成压力传递，导致雪崩。
2.3.1.熔断怎么做
断路器状态有以下几个
-
关闭状态
-
打开状态
-
半开状态
2.4.事物回滚(补偿机制)
这一步通常是最后才考虑的，因为随着链路的深入，事物补偿的代价变得很大，不过如果必须走到这一步也只能做，同样也有不同策略：
因为补偿通常都是有状态有上下文的，因此需要保存上个状态的数据，可以通过以下两种模式保存
2.4.1.本机保存
直接本机保存补偿数据
-
优点：方便，快速
-
缺点：会涉及宕机丢数据，集群处理时数据混乱
2.4.2.持久化保存
持久化保存也是通常的使用方案，（这里不纠结是使用mysql还是redis，存储层的高可用不在这边讨论）
-
优点：全局共享，不会丢数据
-
缺点：可能影响性能，对存储带来压力
2.5.人工处理
如果补偿失败，则会触发人工处理，因为补偿失败意味着这个事物进退两难了，至少这个请求已经脱离系统控制。这时候就需要适合的监控报警方式。
至于如何进行人工处理不在本文讨论内容，各自系统都需要自己解决。无外乎数据修修补补，bug修复。
3.服务提供方策略
3.1.服务限流
光是调用方做处理实际上是不够的，还需要服务自身尽量保证自己不会被压力压垮，因此需要用限流的方式拒绝一些流量，来保证自己服务不会被打挂.
3.1.1.常见的限流策略
-
漏斗桶
-
令牌桶
