文章目录
前言
分布式幂等性是指在分布式系统中的操作（通常是数据库操作）在多次执行时具有幂等性。幂等性意味着，无论操作执行多少次，最终的结果总是相同的。
这在分布式系统中是非常重要的，因为分布式系统由多个节点组成，每个节点可以在任意时间发送请求。如果不保证幂等性，那么可能会出现多次执行同一操作的情况，导致数据不一致。
幂等性的一个常见实现方法是使用唯一标识符（例如事务ID），以确保同一操作只能执行一次。当操作请求到达时，系统可以验证是否已经执行了该操作，如果已经执行，则忽略请求；如果尚未执行，则执行该操作。
分布式幂等性是分布式系统中非常重要的一个概念，可以确保数据的一致性和正确性。
提示：以下是本篇文章正文内容，下面案例可供参考
一、服务雪崩
“服务雪崩” (Service Avalanche) 是一种网络系统中的故障模式，在这种模式下，一个组件的故障引发了其他组件的故障，最终导致系统崩溃。
服务雪崩是由于分布式系统的设计中存在的循环依赖或不可预期的依赖关系所引起的。当一个组件出现故障时，它可能引发其他组件的故障，导致更多的故障，最终导致整个系统不可用。
为了防止服务雪崩，需要对分布式系统进行正确的设计和测试，以确保其组件之间的依赖关系是可预期的，并且能够在组件出现故障时对其他组件产生最小的影响。
服务雪崩效应是一种因“服务提供者的不可用”(原因）导致"“服务调用者不可用”(结果)，并将不可用逐渐放大的现象。如下图所示:
上图中, A为服务提供者,B为A的服务调用者,C和D是B的服务调用者.当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时,服务雪崩就形成了。
形成原因
服务雪崩的过程可以分为三个阶段：
- 服务提供者不可用;
- 重试加大请求流量;
- 服务调用者不可用;
服务雪崩的每个阶段都可能由不同的原因造成，总结如下:
应对策略
一开始你的服务能考虑抗住高并发吗?
成本的增加: 开发成本硬件成本–我要抗住高并发–10W - 500即使是淘宝这种平时的流量和双11的流量差异就很大
我们现在考虑到我今年可能出现一次高并发1W-我全年的服务都部署成可以抗住1W并发-500 - 1k某个时候出现了流量的猛增–2k
限流-2k但是我的服务能力只有1k，所以这个时候多出来的流量怎么办:1.拒绝2.排队等待用户体验不太好:当前访问用户过多，请稍后重试和你的服务直接挂了
用户体验降级了–原本是访问流畅，下单流畅->当前访问用户过多，请稍后重试
熔断-比如A服务访问B服务，这个时候B服务很慢–B服务压力过大，导致了出现了不少请求错误，调用方很容易出现一个问题:每次调用都超时2k，结果这个时候数据库出现了问题，超时重试-网络2k的流量突然变成了3k
这让原本就满负荷的b服务雪上加霜，如果这个时候调用方有一种机制:比如说
- 发现了大部分请求很慢-50%请求都很慢，
- 发现我的请求有50%都错误了
- 粗我数量很多，比如1s出现了20个错误
熔断-1.保险丝⒉.股市熔断
二、超时与重试
超时
timeout是为了保护服务，避免consumer服务因为provider响应慢而也变得响应很慢，这样consumer可以尽量保持原有的性能。
重试
如果provider只是偶尔抖动，那么超时后直接放弃，不做后续处理，就会导致当前请求错误，也会带来业务方面的损失。对于这种偶尔抖动，可以在超时后重试一下，重试如果正常返回了，那么这次请求就被挽救了，能够正常给前端返回数据，只不过比原来响应慢一点。重试可以考虑切换一台机器来进行调用，因为原来机器可能由于临时负载高而性能下降，重试会更加剧其性能问题，而换一台机器，得到更快返回的概率也更大一些。
幂等
如果允许consumer重试，那么provider就要能够做到幂等。同一个请求被consumer多次调用，对provider产生的影响是一致的。而且这个幂等应该是服务级别的，而不是某台机器层面的，重试调用任何一台机器，都应该做到幂等。
例：
三、使用grpc-middleware实现grpc调用的重试
github文档：https://github.com/grpc-ecosystem/go-grpc-middleware
grpc快速入门：https://blog.csdn.net/the_shy_faker/article/details/128082677
proto文件：
syntax = "proto3";
//option go_package = ".;proto";
package proto;
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
client端：
package main
import (
"awesomeProject3/grpc_interprotor/proto"
"context"
"fmt"
"github.com/grpc-ecosystem/go-grpc-middleware/retry"
"google.golang.org/grpc"
"google.golang.org/grpc/codes"
"google.golang.org/grpc/credentials/insecure"
"time"
)
func main() {
//拦截器：计算耗时时间
interceptor := func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
start := time.Now()
err := invoker(ctx, method, req, reply, cc, opts...)
fmt.Printf("耗时：%s\n", time.Since(start))
return err
}
//opt := grpc.WithUnaryInterceptor(interceptor)
//定义多个拦截器
var opts []grpc.DialOption
opts = append(opts, grpc.WithTransportCredentials(insecure.NewCredentials()))
//grpc_retry实现超时重试
retryOpts := []grpc_retry.CallOption{
grpc_retry.WithMax(3),//重试最多3次
grpc_retry.WithPerRetryTimeout(1 * time.Second),//每次最高超时1秒
grpc_retry.WithCodes(codes.Unknown, codes.DeadlineExceeded, codes.Unavailable),//基于返回codes判断超时机制
}
//添加拦截器
opts = append(opts, grpc.WithUnaryInterceptor(interceptor))
opts = append(opts, grpc.WithUnaryInterceptor(grpc_retry.UnaryClientInterceptor(retryOpts...)))
//建立连接
conn, err := grpc.Dial("127.0.0.1:8081", opts...)
if err != nil {
panic(err)
}
defer conn.Close()
c := proto.NewGreeterClient(conn)
//调用
r, err := c.SayHello(context.Background(), &proto.HelloRequest{Name: "jzin"})
if err != nil {
panic(err)
}
fmt.Println(r.Message)
}
server端：
package main
import (
"awesomeProject3/grpc_interprotor/proto"
"context"
"fmt"
"google.golang.org/grpc"
"net"
"time"
)
type Server struct{}
func (s *Server) SayHello(ctx context.Context, request *proto.HelloRequest) (*proto.HelloReply, error) {
return &proto.HelloReply{
Message: "hello" + request.Name,
}, nil
}
func main() {
//拦截器
interceptor := func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
fmt.Println("接收到了一个新的请求")
time.Sleep(time.Second * 2)
res, err := handler(ctx, req)
fmt.Println("请求已经完成")
return res, err
}
//添加拦截器
opt := grpc.UnaryInterceptor(interceptor)
g := grpc.NewServer(opt)
//注册实例
proto.RegisterGreeterServer(g, &Server{})
lis, err := net.Listen("tcp", "0.0.0.0:8081")
if err != nil {
panic("失败：" + err.Error())
}
//开启服务
err = g.Serve(lis)
if err != nil {
panic("失败：" + err.Error())
}
}
四、常用的幂等性解决方案
哪些情况下需要考虑幂等性–同样的请求发送多次︰
1. http请求的类型:
- get
-
- 获取商品信息，这个会引起商品的数据的变化吗?
- post
-
- 比较常见，这种接口需要考虑到幂等性
- put
-
- 不一定要实现幂等性
-
-
- put把1号商品的价格改为200，网络返回的时候抖动了，重试
-
-
-
- 第二次接口还是会把1号商品的价格改为200-这种情况下没有幂等的问题
-
-
- 出现幂等性问题的情况:
-
-
- 购物车中的商品，调用一次这个商品的数量加一
-
-
-
- 第一次调用原本的值10之后价格变为11-但是返回的时候出现了网络抖动
-
-
-
- 第二次发送原本的值11之后价格变为12-但是返回的时候出现了网络抖动
-
-
-
- 第三次发送原本的值12之后价格变为13-但是返回的时候出现了网络抖动
-
- delete
- —般不具备幂等性的要求
- 第一次调用删除数据
- 第二次调用还是删除当前的数据
现在假设，你自己开发了一个支付宝，然后别人在二维码支付页面，先支付了，结果由于网络问题，当前页面一直没有刷新，就让人以为我没有支付，然后我就再次扫码支付，这下完蛋了︰你扣了两次款。
2. 背景
我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。
get请求一般没有幂等性需求、delete请求一般也没有幂等性需求，post、update视情况而定例如:
- 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。
- 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱;
- 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的;
- 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。
等等很多重要的情况，这些逻辑都需要幂等的特性来支持。
3. 幂等性概念
幂等(idempotent、idempotence)是一个数学与计算机学概念，常见于抽象代数中。
在编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()"函数就是一个幂等函数.
更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
我的理解∶幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的
4. 技术方案
- 查询操作
查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作 - 删除操作
删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)
（1）唯一索引，防止新增脏数据
比如: 新建用户的时候将手机号码设置为唯一索引，那么即使你重试，也只会新建一个用户，不会因为重试导致当前用户注册了两个用户
要点:
唯一索引或唯一组合索引来防止新增数据存在脏数据
(当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可)
（2）token机制，防止页面重复提交
业务要求:
页面的数据只能被点击提交一次
发生原因:
由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交
解决办法:
集群环境: 采用token加redis (redis单线程的，处理需要排队)
- 数据提交前要向服务的申请
token，token放到redis或内存，token有效时间 - 提交后后台校验
token，同时删除token，生成新的token返回
token特点:
要申请，一次有效性，可以限流
注意: redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用
（3）悲观锁
获取数据的时候加锁获取
select * from table_xxx where id='xxx’ for update;
注意: id字段一定是主键或者唯一索引，不然是锁表，会死人的
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用
（4）乐观锁
乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。
乐观锁的实现方式多种多样可以通过version或者其他状态条件:
- 通过版本号实现
update table_xxx set name=#namet,version=version+1 where version=#version#
如下图(来自网上):
- 通过条件限制
update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount#>=0
要求:quality-#subQuality# >=，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高
注意: 乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好
update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version#
update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0
（5）分布式锁
以前做的分布式锁：https://blog.csdn.net/the_shy_faker/article/details/127981144
还是拿插入数据的例子，如果是分布式系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。
要点: 某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)
（6）select + insert
并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了
注意: 核心高并发流程不要用这种方法
（7）对外提供接口的api如何保证幂等
如银联提供的付款接口∶需要接入商户提交付款请求时附带: source来源，seq序列号source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
重点:
对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果;没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。
总结
幂等与你是不是分布式高并发没有关系。关键是你的操作是不是幂等的。一个幂等的操作典型如:把编号为5的记录的A字段设置为0这种操作不管执行多少次都是幂等的。一个非幂等的操作典型如:把编号为5的记录的A字段增加1这种操作显然就不是幂等的。要做到幂等性，从接口设计上来说不设计任何非幂等的操作即可。譬如说需求是:当用户点击赞同时，将答案的赞同数量+1。改为:当用户点击赞同时，确保答案赞同表中存在一条记录，用户、答案。赞同数量由答案赞同表统计出来。总之幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像支付宝，银行，互联网金融公司等涉及的都是钱的系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，用户体验也不好。
1134
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
