熔断
ha-rongduan
ha-rongduanstate
- rpc调用开始时，熔断器关闭
- rpc发生超时（拒绝服务），超时次数超过阈值，熔断器打开，不发送rpc请求，直接产生异常
- 熔断器打开超过一定时间，尝试去发送rpc请求，进入半打开状态
- 如果尝试成功，则熔断器关闭，正常发送请求
- 否则熔断器继续打开，拒绝服务
节流
ha-jieliu
上面的公式代表客户端请求拒绝概率
requests是收到的请求
accepts是后端接收的请求
当requests>K*accepts时，开始节流
K越大，可以接受后端拒绝服务越多
K越小，对后端拒绝服务越小
客户端通过上面的公式，以一定概率抛弃请求。
限流
- 滑动窗口
ha-windows
例如一个格子1s
一个窗口包含5个格子
如果一个窗口的流量超过阈值，则抛弃请求
窗口每过一秒向右移动一格
存在的问题：
- 流量超过，则必须抛弃或者降级
- 控制不够精细，不能限制突发流量
- 令牌桶
ha-lingpaitong
ha-get-lingpai
初始先注满令牌桶
周期性的检查令牌桶是否满，未满则注入新的令牌
客户端每次发生调用，都先取令牌，如果获取到，则执行，否则拒绝服务
-
动态适应算法
根据TCP BBR算法，衍生出限流的自适应算法。
关注3个值：TPS，latency，CPU
ha-autu-limit
算法规则如下：- 定时采样CPU，如果CPU的利用率大于阈值（80%），则进入流量控制
- 统计当前服务在一定时间窗口内的请求数和latency，得出inflight
- 统计当前服务所有 buckets中完成的最多请求数和最小latency，得出maxflight = TPS*min latency
- 如果inflight > maxflight则表明过载，进行流量控制、
维度
- 按用户维度限流
- 按IP维度限流
- 按业务优先级维度限流
负载均衡
-
静态算法
-
DNS
-
动态CDN
- 选择经量近的节点
- 基于带宽策略选择机房
- 基于服务容量来平衡流量
-
随机负载
忽略了机器之间的性能差异
-
轮询
忽略了机器之间的性能差异
-
最小连接
-
加权选择
大部分流量压到权重大的机器
-
-
动态算法
-
p2c
在多个结点中随机选择两个结点
二选一
每个机器都有可能选择到，也考虑了机器之间的性能差异
-
EWMA
-
ha-ewma
通过把过去的信息加权平均，来计算当前服务器的负载
通过EWMA计算每个后端服务器的负载
使用p2c随机选择两个后端服务器结点
比较两个结点的EWMA值，选择负载低的结点进行发送
重试
- 每分钟设置最多可以重试次数，超过则直接标志为失败
- 限制重试次数比例为10%
- 随机重试策略
- Exponential Backoff And Jitter
- 如果发生RPC服务拒绝，则启动重试
- 重试的时间间隔以2的指数增长
- 并设定最大重试次数
幂等
- 相同id，保存在数据库或者redis
- 使用seq序号来保证幂等
降级
当发生后端服务器负载过高，或者拒绝服务时，返回兜底资源，而不是请求后端服务器，来保证服务的可用性
超时
- 客户端发起RPC请求时携带可接受的超时时间
- 服务器每处理一段业务，进行超时时间的递减
- 一旦发现处理时间大于客户端的超时时间，则停止往下执行
过载保护
- 如果CPU超过80，则丢弃部分流量
- 内存使用量超过阈值，则丢弃部分流量
- 使用队列的最大长度，限制正在处理的最大请求
- 可控延迟算法 Codel
Ref:
https://baijiahao.baidu.com/s?id=1714316170925203681&wfr=spider&for=pci1i2
https://martinfowler.com/bliki/CircuitBreaker.html
https://cloud.tencent.com/developer/news/868069
网友评论