分布式接口的幂等设计
金融系统设计要点--数据一致(事务、幂等、网络请求)
金融系统设计要点-数据一致事务、幂等、网络请求目录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）：悲观锁通过在执行操作之前锁定数据，阻止其他操作对该数据的访问。
只有当操作完成后才释放锁。
但是，悲观锁可能导致操作的延迟和阻塞，并且需要考虑锁的粒度和并发度的平衡。
接口设计的16个原则
接⼝设计的16个原则接⼝设计需要考虑哪些⽅⾯1. 接⼝的命名。
2. 请求参数。
3. ⽀持的协议。
4. TPS、并发数、响应时长。
5. 数据存储。
DB选型、缓存选型。
6. 是否需要依赖于第三⽅。
7. 接⼝是否拆分。
8. 接⼝是否需要幂等。
9. 防刷。
10. 接⼝限流、降级。
11. 负载均衡器⽀持。
12. 如何部署。
13. 是否需要服务治理。
14. 是否存在单点。
15. 接⼝是否资源包、预加载还是内置。
16. 是否需要本地缓存。
17. 是否需要分布式缓存、缓存穿透怎么办。
18. 是否需要⽩名单。
当我们设计接⼝，我们或多或少都会有上⾯列举的⼀些考虑，我们只有想的更多才能让让我们的接⼝更加完善，我个⼈觉得100%完美的接⼝是不存在，只有适合才是最重要。
接⼝设计原则原则⼀：必须符合Restful，统⼀返回格式，约定业务层错误编码，每个编码可以携带可选的错误信息。
原则⼆：命名必须规范、优雅。
原则三：单⼀性。
单⼀性是指接⼝要做的事情应该是⼀个⽐较单⼀的事情，⽐如登陆接⼝，登陆完成应该只是返回登陆成功以后⼀些⽤户信息即可，但很多⼈为了减少接⼝交互，返回⼀⼤堆额外的数据。
⽐如有⼈设计⼀个⽤户列表接⼝，接⼝他返回每⼀条数据都是包含⽤户了⼀⼤堆跟另外⽆关的数据，结果⼀问，原来其他⽆关的数据是他下⼀步想要获取的，想达成数据的懒加载。
原则四：可扩展。
接⼝扩展性，是指设计接⼝的时候多想想多种情况，多考虑各个⽅⾯，其实我觉得单独将扩展性放在这⾥也是不妥的，感觉说的跟单⼀性有点相反的意思，其实这个不是这个意思。
这边的扩展性是指我们的接⼝充分考虑客户端，想想他们是如何调⽤的，他要怎样使⽤我的代码，他会如何扩展我的代码，不要把过多的⼯作写在你的接⼝⾥⾯，⽽应该把更多的主动权交给客户程序员。
如获取不同的列表数据接⼝，我们不可能将每个列表都写成⼀个接⼝。
还有⼀点，我这⾥特别想指出来的是很多开发⼈员为了省事（姑且只能这么理解），将接⼝设计当成只是 app 页⾯展⽰。
幂等性原理
幂等性原理在计算机网络和分布式系统中，幂等性原理被广泛应用。
也被称为“幂等性”，它是一种特殊的操作，无论它执行多少次，都会产生相同的结果。
它的作用主要是防止一次重复操作的请求被执行多次，因此非常重要。
幂等性原理最初被用于网络设计中，主要是为了解决分布式系统中的消息发送和网络容错的问题。
在这种情况下，如果一个请求被重复发送，则可能会被重复执行。
幂等性原理最常见的操作是PUT和DELETE，它们都是不可逆的操作。
由于PUT和DELETE不可逆，因此如果这些操作被重复执行，则可能会对系统造成不可挽回的破坏。
为了防止这种情况的发生，在进行PUT和DELETE操作之前，必须应用幂等性原理，以确保操作不会被重复执行。
此外，幂等性原理还可以应用于分布式系统中的事务处理。
随着分布式系统的发展，有很多不同类型的事务，其中有些是通过网络发送的。
这样的事务如果发送被重复多次，则可能会被重复执行，从而影响系统的一致性。
使用幂等性原理可以有效地解决这个问题，从而保护系统的一致性。
除了分布式系统中的应用，幂等性原理还可以用于网络安全方面的应用，例如访问控制机制。
在这种情况下，访问者可能会重复地发送多个访问请求，从而降低系统的安全性。
使用幂等性原理，可以确保重复的访问请求只会被执行一次，从而更好地保护系统的安全性。
此外，幂等性原理也可以用于任务调度，可以避免因失败而重复执行任务，从而提高任务处理的效率。
基于这些原因，幂等性原理在网络设计和分布式系统中发挥着至关重要的作用。
总之，幂等性原理在分布式系统中发挥着重要作用，它能够有效地防止重复操作的请求被重复执行，从而保护系统的一致性和安全性。
为了使分布式系统的功能能够得到最大限度地发挥，幂等性原理是不可缺少的。
因此，理解幂等性原理对于分布式系统设计者来说是非常重要的。
分布式数据库中的数据重复与幂等性处理方法(四)
分布式数据库中的数据重复与幂等性处理方法在分布式数据库中，数据重复和幂等性是一个常见的问题。
当多个节点同时对数据库进行操作时，可能会出现数据重复的情况，造成不一致性；而幂等性是指在多次执行同一个操作时，结果保持一致。
在处理这些问题时，我们需要采取一些方法来确保数据的准确性和一致性。
一、数据重复处理方法数据重复是指多个节点同时对数据库进行插入或更新操作，造成同一条记录多次出现。
为了避免数据重复，我们可以采取以下几种方法：1. 生成唯一标识符在每次插入新数据时，可以为每条记录生成一个唯一标识符。
可以使用UUID或者分布式ID生成算法来保证生成的标识符不会重复。
当有新的数据插入时，先检查数据库中是否已存在相同的标识符，如果存在则说明数据重复，可以选择忽略或者进行更新操作。
2. 使用唯一索引在数据库表中，可以设置唯一索引来保证数据的唯一性。
当有新的数据插入时，数据库会自动检查索引字段是否已存在相同的值，如果已存在则会抛出唯一约束异常。
通过捕获异常并进行相应处理，可以避免插入重复数据。
3. 建立缓存层在实际应用中，可以引入缓存层来处理数据重复的问题。
当有多个节点同时对数据库进行插入操作时，先将数据写入缓存中，再由缓存层来判断数据是否已存在。
如果数据已存在，则不再进行插入操作，避免数据的重复。
二、幂等性处理方法幂等性是指在多次执行同一个操作时，结果保持一致。
在分布式环境中，由于网络延迟、节点故障等原因，可能会导致同一操作多次执行。
为了保证幂等性，我们可以采取以下几种方法：1. 使用乐观锁在更新操作中，使用乐观锁可以有效保证幂等性。
乐观锁是通过版本号或时间戳来实现的，每次更新时都会比较当前版本号与数据库中的版本号是否一致，如果一致则更新成功，否则说明其他节点已更新过，操作失败。
2. 利用幂等性操作在设计接口和系统时，可以将一些操作设计成幂等性的。
比如，数据库更新操作可以使用replace into语句来实现。
幂等函数的应用
幂等函数的应用一、什么是幂等函数幂等函数是指不论调用多少次，结果都是相同的函数。
在计算机科学中，幂等性是指对同一操作的多次执行所产生的影响与执行一次的影响相同。
幂等函数是很有用的，特别是在分布式系统和并发编程中，能够保证系统的可靠性和一致性。
二、应用场景举例2.1 数据库操作在数据库操作中，幂等函数可以防止重复操作造成的数据不一致的问题。
例如，在插入数据时，如果调用插入函数多次，可能会导致重复插入相同的数据，而幂等函数可以在插入前先检查是否已经存在相同的数据，避免重复插入造成的数据冗余。
2.2 支付系统在支付系统中，幂等函数可以确保同一笔支付请求不会被重复处理。
由于网络延迟等原因，可能会导致支付请求在某些情况下被重发多次，而服务器必须保证只有一次请求被处理。
幂等函数可以通过记录已处理的支付请求，来去重并避免多次扣款或多次付款的问题。
2.3 消息队列消息队列是分布式系统中常用的异步通信方式。
在消息的生产者和消费者之间，可能会存在网络故障或其他原因导致消息重复发送的情况。
幂等函数可以确保消费者在接收到消息后，只执行一次相应的处理逻辑，避免重复处理消息带来的副作用。
2.4 接口调用在网络接口调用中，由于网络传输的不可靠性，可能会导致接口请求失败或超时。
为了保证接口调用的可靠性，可以使用幂等函数来处理接口请求。
当接口请求失败时，可以重新发送相同的请求，而幂等函数可以保证相同的请求只执行一次，避免重复调用接口带来的问题。
三、实现幂等函数的方式3.1 唯一标识符一种常用的实现幂等函数的方式是使用唯一标识符（例如订单号）来标识请求的唯一性。
在处理请求之前，先检查标识符对应的请求是否已经处理过。
如果已经处理过，则直接返回结果；如果未处理过，则执行相应的处理逻辑，并记录已处理状态。
3.2 提交状态检查另一种实现幂等函数的方式是通过提交状态检查来判断请求是否已经处理过。
在处理请求之前，先检查请求的提交状态。
如果已经提交成功，则直接返回结果；如果提交失败或未提交，则执行相应的处理逻辑，并更新提交状态。
一口气说出四种幂等性解决方案，面试官露出了姨母笑~
一口气说出四种幂等性解决方案，面试官露出了姨母笑~什么是幂等性？幂等是一个数学与计算机学概念，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同。
“在计算机中编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。
这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
什么是接口幂等性？在HTTP/1.1中，对幂等性进行了定义。
它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
这里的副作用是不会对结果产生破坏或者产生不可预料的结果。
也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
为什么需要实现幂等性？在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：1.前端重复提交表单：在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
2.用户恶意进行刷单：例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
3.接口超时重复提交：很多时候HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
4.消息进行重复消费：当使用MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。
“使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。
引入幂等性后对系统有什么影响？幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：1.把并行执行的功能改为串行执行，降低了执行效率。
接口的幂等性
接口的幂等性
1.什么是幂等性：
幂等性是指一个接口，可以在不破坏系统状态下，多次重复调用执行同样的操作，其结果每次返回的结果均一致，也就是多次调用的结果和一次的调用结果一致。
2.为什么需要实现幂等：
当网络连接不稳定，或者客户端因网络问题导致调用失败，客户端会不断的重发调用，而这类重复调用会对服务端造成极大的压力，此时如果接口不是幂等性的，当接口多次调用时，会出现数据错乱或者数据重复写入的情况，从而破坏系统设计。
3.如何实现幂等：
实现幂等性接口的方法有很多种，其中最常用的是使用记录产生的唯一的请求ID。
当客户端发起一个请求时，服务端可以在处理请求前，根据请求ID查询该ID对应的请求是否存在，如果存在且状态为未处理，则认为该请求已被处理过，服务端返回一个相应消息，不在重复处理请求；如果不存在，则认为是一个新请求，服务端处理该请求，同时保存请求ID，处理完成后将该ID的状态置为“已处理”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
分布式接口的幂等设计
什么是接口的幂等性
解释
什么是接口的幂等性，接口的幂等性实际上就是接口可重复调用，在调用方多次调用的情况下，接口最终得到的结果是一致的。
有些接口可以天然的实现幂等性，比如查询接口，对于查询来说，你查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。
除了查询功能具有天然的幂等性之外，增加、更新、删除都要保证幂等性。
那么如何来保证幂等性呢？
举例
在微服务架构下，我们在完成一个订单流程时经常遇到下面的场景：
1. (重复创建)一个订单创建接口，第一次调用超时了，然后调用方重
试了一次
2. (重复更新)在订单创建时，我们需要去扣减库存，这时接口发生了
超时，调用方重试了一次
3. (重复更新)当这笔订单开始支付，在支付请求发出之后，在服务端
发生了扣钱操作，接口响应超时了，调用方重试了一次
4. (无序更新)一个订单状态更新接口，调用方连续发送了两个消息，
一个是已创建，一个是已付款。
但是你先接收到已付款，然后又接
收到了已创建
以上问题，就是在单体架构转成微服务架构之后，带来的问题。
当然不是说单体架构下没有这些问题，在单体架构下同样要避免重复请求。
但是出现的问题要比这少得多。
解决方案
全局唯一ID(通用解决方案)
如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。
如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。
如果存在则表示该方法已经执行。
从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。
另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。
使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。
但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。
去重表(适用于插入或更新操作)
这种方法适用于在业务中有唯一标识的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。
这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入到去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。
插入或更新(适用于插入或更新)
这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。
这时就可以使用InsertOrUpdate操作。
在mysql数据库中如下：
insert into goods_category
(goods_id,category_id,create_time,update_time)
values(#{goodsId},#{categoryId},now(),now())
on DUPLICATE KEY UPDATE
update_time=now()
多版本控制(适用于更新)
这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等
在实现时可以如下
boolean updateGoodsName(int id,String newName,int
version);
update goods set name=#{newName},version=#{version}
where id=#{id} and version<${version}
状态机控制(适用于某状态字段有序更新)
这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的创建肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为100。
付款失败为99
在做状态机更新时，我们就这可以这样控制
update `order` set status=#{status} where id=#{id} and
status<#{status}
以上就是保证接口幂等性的一些方法。