高并发下的接口幂等性解决方案
我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。
例如：
1.前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。
2.我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统
bug重发，也应该只扣一次钱；
3.发送消息，也应该只发一次，同样的短信发给用户，用户会哭的；
4.创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。
等等很多重要的情况，这些逻辑都需要幂等的特性来支持。
二、幂等性概念
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。
这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
例如，“getUsername()和setTrue()”函数就是一个幂等函数.
更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
我的理解：幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的
三、技术方案
1. 查询操作查询一次和查询多次，在数据不变的情况下，查询结果是一
样的。
select是天然的幂等操作
2. 删除操作删除操作也是幂等的，删除一次和多次删除都是把数据删除。
(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)
3.唯一索引，防止新增脏数据比如：支付宝的资金账户，支付宝也有用户
账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录
要点：唯一索引或唯一组合索引来防止新增数据存在脏数据（当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可）
4. token机制，防止页面重复提交
业务要求：
页面的数据只能被点击提交一次。
发生原因：由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交
解决办法：集群环境：采用token加redis（redis单线程的，处理需要排队）单JVM环境：采用token加redis或token加jvm内存
处理流程：
1.数据提交前要向服务的申请token，token放到redis或jvm内存，token
有效时间
2.提交后后台校验token，同时删除token，生成新的token返回
token特点：要申请，一次有效性，可以限流
注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用
5. 悲观锁获取数据的时候加锁获取
select * from table_xxx where id='xxx' for update;
注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用。
6. 乐观锁乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相
对于悲观锁，效率更高。
乐观锁的实现方式多种多样可以通过version或者其他状态条件：
1、通过版本号实现
update table_xxx set name=#name#,version=version+1 where version =#version#
2、通过条件限制
update tablexxx set avaiamount=avaiamount-#subAmount# where avaiamount-
#subAmount# >= 0
要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高
注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好
update tablexxx set name=#name#,version=version+1 where id=#id# and version=#ve rsion#
update tablexxx set avaiamount=avaiamount-
#subAmount# where id=#id# and avai_amount-#subAmount# >= 0
7. 分布式锁还是拿插入数据的例子，如果是分布是系统，构建全局唯一
索引比较困难，例如唯一性的字段没法确定
这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁
这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。
要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)
8. select + insert并发不高的后台系统，或者一些任务JOB，为了支持
幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了
注意：核心高并发流程不要用这种方法
9. 状态机幂等在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机
如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
注意：订单等单据类业务，存在很长的状态流转，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助
10. 对外提供接口的api如何保证幂等
如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号
source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
重点对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引
这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。
注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。
总结
幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像支付宝，银行，互联网金融公司等涉及的都是钱的系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，用户体验也不好。
金融系统设计要点--数据一致(事务、幂等、网络请求)
金融系统设计要点-数据一致事务、幂等、网络请求目录1.内容概要 (3)2.常见概念 (3)2.1.ACID (3)2.2.Base(basically available, soft state, eventually consistent) (3)2.3.CAP定律 (3)2.4.强一致 (4)2.5.弱一致性 (4)2.6.最终一致性 (4)3.分布式事务 (5)3.1.本地消息表 (6)3.2.MQ（非事务消息） (7)3.3.MQ（事务消息） (8)3.4.其他补偿方式 (10)4.幂等性 (10)1.内容概要分布式架构解决的是高并发的问题，高并发下服务高可用和数据一致性问题问题；当规模规模较小时，单库HA即可满足请求，当业务规模持续增加，单库已经无法满足业务需求，业界主流做法，是对业务进行分表、分库，那么原来的有些业务，现在则要在一个事务中，保证两个库同时操作成功或操作不成功(一个库成功，一个库失败，要么重新尝试失败库操作直到成功，要么回滚成功库)。
随之而来的问题既是如何保证分库时业务操作的数据一致性。
理解高并发分布式架构、分布式系统数据一致性的问题、起源是第一步。
2.常见概念2.1.ACID关系型数据库通常具有ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
2.2.Base(basically available, soft state, eventually consistent)一种 Acid 的替代方案，BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。
化学理论中ACID是酸、Base恰好是碱。
2.3.CAP定律在分布式系统中，同时满足"CAP定律"中的"一致性"、"可用性"和"分区容错性"三者是不可能的。
分布式数据库中的数据重复与幂等性处理方法
分布式数据库中的数据重复与幂等性处理方法在分布式数据库中，数据重复和幂等性是常见的问题，对于保证数据的准确性和一致性至关重要。
本文将探讨数据重复和幂等性的概念并介绍一些处理方法。
一、数据重复的概念和问题数据重复是指在分布式数据库中存在多个相同的数据副本。
造成数据重复的主要原因有网络延迟、系统故障和并发操作等。
数据重复可能导致数据不一致、冗余和浪费存储空间的问题。
对于数据重复问题，通常有以下几种处理方法：1. 唯一标识符（Unique Identifier）：为每条数据生成一个唯一标识符，通过唯一标识符来判断是否存在重复数据。
但是，唯一标识符需要在分布式环境中保证唯一性，这需要额外的开销和复杂的实现。
2. 一致性哈希（Consistent Hashing）：一致性哈希将数据均匀地分布在多个节点上，根据数据的哈希值来确定数据存储的节点。
这样可以避免数据重复问题，但是一致性哈希需要维护哈希环和节点的加入和移除操作。
3. 事务（Transaction）：分布式事务可以保证一组操作的原子性、一致性、隔离性和持久性。
通过使用事务，可以在多个节点上执行一组操作，并在操作失败时回滚。
但是，事务会增加系统的开销，并且需要面对并发操作和故障恢复的挑战。
二、幂等性的概念和问题幂等性是指对同一操作的多次调用会产生相同的结果。
在分布式数据库中，幂等性问题是指在并发操作下可能导致重复执行产生不一致的结果。
幂等性问题的处理方法包括：1. 乐观锁（Optimistic Locking）：乐观锁通过使用版本号或时间戳来判断是否需要执行某个操作。
对于相同的操作，只有一个操作可以执行成功，其他操作将被忽略。
但是，乐观锁需要额外的字段来保存版本号或时间戳，并且可能导致操作的延迟和冲突。
2. 悲观锁（Pessimistic Locking）：悲观锁通过在执行操作之前锁定数据，阻止其他操作对该数据的访问。
只有当操作完成后才释放锁。
但是，悲观锁可能导致操作的延迟和阻塞，并且需要考虑锁的粒度和并发度的平衡。
处理高并发的六种方法
处理高并发的六种方法处理高并发的六种方法随着互联网的飞速发展，各种网站、移动应用和电子商务平台都面临着处理海量并发请求的挑战。
高并发是指在同一时间内，服务端接收到的客户端请求数量大于其能够处理的数量，这种情况下，如果服务器不能及时地处理请求，就有可能出现系统崩溃、服务停止等严重问题。
为了解决这一问题，本文介绍了处理高并发的六种方法。
1. 垂直扩展垂直扩展是指通过增加服务器的硬件配置来提升其运行效率，包括增加 CPU、加大内存、使用更快的硬盘等。
这种方式的优点是容易实现，操作简单，对系统架构没有太大影响，但是成本较高，容量上限较小，无法承载海量并发请求。
2. 水平扩展与垂直扩展相对应的是水平扩展，它是通过增加服务器的数量来提高整体系统的处理能力。
这种方式的优点在于成本相对较低，容量上限相对较大，吞吐量也较高。
但是，水平扩展需要考虑负载均衡、数据同步等问题，所以对系统架构的调整较大。
3. 负载均衡负载均衡是指通过多台服务器对请求进行分流，让每台服务器处理一部分请求，从而提高整体处理能力的方式。
负载均衡可以分为软件负载均衡和硬件负载均衡，软件负载均衡适合小规模的网络架构，硬件负载均衡适合大规模的网络架构。
负载均衡需要考虑多台服务器之间的数据同步、请求转发等问题。
4. CDN 加速CDN（Content Delivery Network，内容分发网络）是一种用于加快网络传输速度和提高网站可用性的技术。
CDN 可以将静态资源（如图片、CSS、JS 文件等）缓存到离客户端最近的服务器上，从而使客户端的请求可以更快地响应。
CDN 还可以通过负载均衡和智能路由等机制，让用户和最近的服务器之间建立连接，减少延迟和网络拥堵。
5. 缓存技术缓存技术是指将常用的数据存储到内存或磁盘中，从而可以将数据读写速度提高数倍以上。
缓存技术可以减轻数据库的负担，提高网站的访问速度。
缓存技术可以采用多种方式，如使用 Redis、Memcached 等内存数据库，使用 Nginx 或Apache 等 Web 服务器的缓存模块等。
幂等性详解！
幂等性详解！来源：/weixin_42412601/article/details/108412439幂等性1.什么是幂等性？幂等性：提交一次和多次，结果是一样的。
2.哪些情况需要保证幂等性？用户多次点击按钮；用户页面回退再次提交；微服务相互调用，由于网络原因，导致请求失败，feign触发重试机制；其他业务情况；3.什么情况下需要幂等性？以SQl为例，有些操作时天然幂等。
select * from table where id =? 无论查询多少次都不会改变状态，是天然幂等的。
update table set col=1 where col2=2,无论执行操作多少次都不会改变状态，是天然幂等的。
delete from user where userId=1,多次操作，结果一样幂等操作。
inter into user(id,name)values(1,'a’),如id唯一主键，即重复操作上面的业务，只会插入一条数据，具备幂等性；update table1 set col1=col1+1 where col2=2,每次执行的结构都会发生变化，不是幂等。
inter into user(id,name)values(1,'a’),如id不是主键，即重复操作上面的业务，会插入多条数据，不具备幂等性；4.幂等解决方案？4.1 token机制1.服务端提供了发生token的接口。
我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token,服务器会把token保存到redis中。
2.然后在调用业务接口请求时，把token携带过去，一般放在请求头部。
3.服务器判断token是否存在于redis中，存在表示第一次请求，然后删除token，继续执行业务4.如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给客户端，这样就保证了业务代码，不被重复执行危险性：1、先删除token还是后删除token如果是后删除令牌，用户点提交订单，连续点两次，第一次提交订单，还没执行完，还没来得及删除令牌，第二次的提交订单就进来，这样就出现数据不一致的问题了。
.netcoreapi请求实现接口幂等性
.netcoreapi请求实现接⼝幂等性简单实现接⼝幂等性，根据参数的hascode实现：1. 参数介绍1. WaitMillisecond ：请求等待毫秒数 2. CacheMillisecond：请求结果缓存毫秒数2. 参数具体使⽤场景 1. WaitMillisecond ：⽤户频繁发起多次请求，只处理第⼀次请求，后续请求在这个等待（时间范围内）的均返回“正在执⾏..”，超出这个预设时间会再次真实请求到后台业务逻辑2. CacheMillisecond：第⼀次请求成功并且拿到结果，⽤户频繁发起请求在这个缓存时间在，将返回上次⼀样的结果。
直⾄过期1.使⽤⽅式[HttpPost][HttpIdempotent(WaitMillisecond = 10000,CacheMillisecond = 3000)]public async Task<IActionResult> Order(string orderNo) { //TODO }2.具体实现1///<summary>2/// api request idempotence3///</summary>4public class HttpIdempotentAttribute : Attribute, IAsyncResourceFilter5 {67static HttpIdempotentAttribute()8 {9var thread = new Thread(() =>10 {11while (true)12 {13var hashtableDatas = HashTable.Where(x => DateTime.Now > x.Value.Time).ToList();1415if (hashtableDatas.Any())16 {17foreach (var hashtableData in hashtableDatas)18 {19 HashTable.Remove(hashtableData.Key);20 }21 }22else23 {24 System.Threading.Thread.Sleep(2000);25 }26 }2728 });2930 thread.IsBackground = true;31 thread.Start();32 }3334///<summary>35/// http request parameter code collect36///</summary>37private static readonly Dictionary<int, HashtableData> HashTable = new();3839///<summary>40/// http request parameter code41///</summary>42public int _httpHasCode;4344///<summary>45/// waiting for the last request , default value:100046///</summary>47public double WaitMillisecond { get; set; } = 1000;4849///<summary>50/// result cache Millisecond , default value:100051///</summary>52public double CacheMillisecond { get; set; } = 1000;5354///<summary>55/// interceptor56///</summary>57///<param name="context"></param>58///<param name="next"></param>59///<returns></returns>60public async Task OnResourceExecutionAsync(ResourceExecutingContext context, ResourceExecutionDelegate next) 61 {62await this.SetHttpParameterHasCode(context.HttpContext);6364if (HashTable.ContainsKey(_httpHasCode))65 {66var hashtableData = (HashtableData)HashTable[_httpHasCode];67if (hashtableData != null)68 {69if (DateTime.Now < hashtableData.Time)70 {71 context.Result = hashtableData.Value;72return;73 }74else if (DateTime.Now > hashtableData.Time)75 {76 HashTable.Remove(_httpHasCode);77 }78else if (hashtableData.Value.Value == null)79 {80 context.Result = new ContentResult()81 {82 Content = "正在执⾏..."83 };84return;85 }86 }87 }8889 HashTable.Add(_httpHasCode, new HashtableData(DateTime.Now.AddMilliseconds(WaitMillisecond), null));9091try92 {93var netResult = await next();9495if (HashTable.ContainsKey(_httpHasCode))96 {97var hashtableData = (HashtableData)HashTable[_httpHasCode];98if (hashtableData != null)99 {100 hashtableData.Value = (ObjectResult)netResult.Result;101 hashtableData.Time = DateTime.Now.AddMilliseconds(CacheMillisecond);102 }103 }104 }105catch (Exception ex)106 {107 HashTable.Remove(_httpHasCode);108 }109110 }111112///<summary>113/// get http request parameter code114///</summary>115///<returns></returns>116private async Task SetHttpParameterHasCode(HttpContext httpContext)117 {118119object readFromJson = null;120121try122 {123if (httpContext.Request.Method != "GET")124 {125 readFromJson = await httpContext.Request.ReadFromJsonAsync<object>();126 }127 }128catch (Exception e)129 {130 Console.WriteLine(e);131 }132133//todo 根据实际项⽬情况处理，获取Headers toke134var authorization = httpContext.Request.Headers["Authorization"];135136var queryString = httpContext.Request.QueryString;137var bodyString = readFromJson == null ? string.Empty : readFromJson.ToString();138139var builder = $"{authorization}-{queryString}-{bodyString}"; 140141this._httpHasCode = builder.GetHashCode();142 }143144///<summary>145/// Hashtable parameter model146///</summary>147private class HashtableData148 {149public HashtableData(DateTime time, ObjectResult value) 150 {151 Time = time;152 Value = value;153 }154public DateTime Time { get; set; }155public ObjectResult Value { get; set; }156 }157 }。
接口的幂等性问题怎么解决？
接⼝的幂等性问题怎么解决？
答：
幂等的意思是重复操作，接⼝的幂等性也就是接⼝被重复调⽤了，在前端不进⾏限制的情况下，同⼀个接⼝可能重复调⽤多次，为了避免类似重复下单的问题，可以通过以下⼏种⽅式来解决幂等性问题：
1、全局唯⼀ID，根据业务操作和内容⽣成全局唯⼀的ID，然后在执⾏操作前先判断是否已经存在该ID，如果不存在则将该ID进⾏持久化(存在数据库或者redis中)，如果已经存在则证明该接⼝已经被调⽤过了。
⽐如下单时可以⽣产⼀个流⽔号来作为该订单的唯⼀标识。
2、可以使⽤select+insert来进⾏判断，因为⼀般订单的ID都是唯⼀索引，在⾼并发场景下不推荐。
3、可以使⽤乐观锁解决，在表中可以添加⼀个version字段。
4、token机制，将token放在redis中。
php接口幂等性
php接⼝幂等性什么是幂等性幂等性是系统服务对外⼀种承诺，承诺只要调⽤接⼝成功，外部多次调⽤对系统的影响是⼀致的。
声明为幂等的服务会认为外部调⽤失败是常态，并且失败之后必然会有重试。
什么情况下需要幂等以SQL为例：SELECT col1 FROM tab1 WHER col2=2，⽆论执⾏多少次都不会改变状态，是天然的幂等。
UPDATE tab1 SET col1=1 WHERE col2=2，⽆论执⾏成功多少次状态都是⼀致的，因此也是幂等操作。
UPDATE tab1 SET col1=col1+1 WHERE col2=2，每次执⾏的结果都会发⽣变化，这种不是幂等的。
insert into user(userid,name) values(1,'a') 如userid为唯⼀主键，即重复操作上⾯的业务，只会插⼊⼀条⽤户数据，具备幂等性。
如userid不是主键，可以重复，那上⾯业务多次操作，数据都会新增多条，不具备幂等性。
delete from user where userid=1，多次操作，结果⼀样，具备幂等性http接⼝中的默认幂等性⼤家都知道,http协议,根据客户端请求服务端的不同操作分为多个请求⽅法:GET /users# 获取users列表GET /users/12# 查看某个具体的usersPOST /users# 新建⼀个usersPUT /users/12# 更新users 12DELETE /users/12# 删除users 12get ⽅法(幂等)get⽅法对资源并没有任何的影响,虽然第⼀次请求完,可能会有数据更改(并⾮这次请求的修改),获取的数据和第⼀次的不⼀致,但并不是它修改的数据,所以它在http协议中默认是幂等性的操作post ⽅法(⾮幂等)⼤家都知道,post⼀般⽤于提交表单,新增或修改数据,当提交多次时,会新增多次数据,所以它默认情况是⾮幂等性操作.put⽅法(幂等)put⽅法将替换原有的资源,由于是直接替换,⽆论多少次请求,替换的内容都是相同的,所以它是幂等性操作delete⽅法(幂等)delete针对于删除某⼀个资源,再次删除的话并不会额外删除其他的资源,也不会新增资源,所以它是幂等性操作在上⾯的http默认幂等性中,我们可以看出,post⽅法是⾮幂等性的(当然不⽌post⼀个).⽽且,在我们正常后端写接⼝时,⽤的最多的应该是post/get去实现所有的数据操作⽅式.那么,现在有⼀些问题:⽤户A提交⼀个⽀付订单,由于添加时⽹络不好,⽤户点击了2次.那么接⼝正常来说,是会新增2个订单的,但是这样就会严重影响⽤户的体验了同理⽤户A想给B转账100元钱,但是不⼩⼼点了2下,如果没做好幂等性,就会造成扣除2次100,扣200块钱.⽀付宝⽀付请求服务器充值回调,给⽤户A增加余额,同时给⽀付宝返回OK告诉⽀付宝增加余额成功,但由于⽹络异常,⽀付宝没有收到OK信号,给服务器重发了⼀次充值回调,这时候给⽤户A⼜增加了⼀次余额如何保证幂等token机制1、服务端提供了发送token的接⼝。
一口气说出四种幂等性解决方案，面试官露出了姨母笑~
一口气说出四种幂等性解决方案，面试官露出了姨母笑~什么是幂等性？幂等是一个数学与计算机学概念，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同。
“在计算机中编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。
这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
什么是接口幂等性？在HTTP/1.1中，对幂等性进行了定义。
它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
这里的副作用是不会对结果产生破坏或者产生不可预料的结果。
也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
为什么需要实现幂等性？在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：1.前端重复提交表单：在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
2.用户恶意进行刷单：例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
3.接口超时重复提交：很多时候HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
4.消息进行重复消费：当使用MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。
“使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。
引入幂等性后对系统有什么影响？幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：1.把并行执行的功能改为串行执行，降低了执行效率。
接口的幂等性
接口的幂等性
1.什么是幂等性：
幂等性是指一个接口，可以在不破坏系统状态下，多次重复调用执行同样的操作，其结果每次返回的结果均一致，也就是多次调用的结果和一次的调用结果一致。
2.为什么需要实现幂等：
当网络连接不稳定，或者客户端因网络问题导致调用失败，客户端会不断的重发调用，而这类重复调用会对服务端造成极大的压力，此时如果接口不是幂等性的，当接口多次调用时，会出现数据错乱或者数据重复写入的情况，从而破坏系统设计。
3.如何实现幂等：
实现幂等性接口的方法有很多种，其中最常用的是使用记录产生的唯一的请求ID。
当客户端发起一个请求时，服务端可以在处理请求前，根据请求ID查询该ID对应的请求是否存在，如果存在且状态为未处理，则认为该请求已被处理过，服务端返回一个相应消息，不在重复处理请求；如果不存在，则认为是一个新请求，服务端处理该请求，同时保存请求ID，处理完成后将该ID的状态置为“已处理”。
幂等性问题如何解决
幂等性问题如何解决
幂等性是指一次和多次执行某个操作时产生的结果是相同的。
例如一次登录，两次登录，得到的结果唯一并保持一致。
解决幂等性问题需要三方面的技术：确定性身份验证、幂等消息和检查点。
确定性身份验证可以防止请求篡改和伪造，它可以在发出请求时通过数字签名建立令牌来表明发出请求的身份。
若使用了确定性身份验证，多次重复发出相同请求都是从一个可靠来源而来，提高了安全性。
幂等消息可以防止请求重复或重播，它通过消息唯一标识、时间戳和消息序号来确保消息的唯一性。
当消息到达服务器时，服务器会通过查询该消息是否已处理，来实现幂等性。
检查点可以根据系统的历史记录追踪用户对系统资源的操作，并在运行时使用复原点来确保一致性。
在遇到意外情况时，系统可利用复原点恢复到操作之前的历史状态，而不是重复执行同一操作。
无论采取什么方式解决幂等性问题，都需要在系统中建立有效的安全措施，及时、有效地跟踪审计等，以保证在系统对环境发生变化时能够得到及时反应，以保证信息安全意识和使用权限的一致性。