高并发系统数据幂等的解决方案
前言
在系统开发过程中，经常遇到数据重复插入、重复更新、消息重发发送等等问题，因为应用系统的复杂逻辑以及网络交互存在的不确定性，会导致这一重复现象，但是有些逻辑是需要有幂等特性的，否则造成的后果会比较严重，例如订单重复创建，这时候带来的问题可是非同一般啊。
什么是系统的幂等性
幂等是数据中得一个概念，表示N次变换和1次变换的结果相同。
高并发的系统如何保证幂等性？
1.查询
查询的API，可以说是天然的幂等性，因为你查询一次和查询两次，对于系统来讲，没有任何数据的变更，所以，查询一次和查询多次一样的。
2.MVCC方案
多版本并发控制，update with condition，更新带条件，这也是在系统设计的时候，合理的选择乐观锁，通过version或者其他条件，来做乐观锁，这样保证更新及时在并发的情况下，也不会有太大的问题。
例如：update table_xxx set name=#name#,version=version+1 where version=#version# ,或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。
3.单独的去重表
如果涉及到的去重的地方特别多，例如ERP系统中有各种各样的业务单据，每一种业务单据都需要去重，这时候，可以单独搞一张去重表，在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。
4.分布式锁
还是拿插入数据的例子，如果是分布是系统，构建唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。
5.删除数据
删除数据，仅仅第一次删除是真正的操作数据，第二次甚至第三次删除，直接返回成功，这样保证了幂等。
6.插入数据的唯一索引
插入数据的唯一性，可以通过业务主键来进行约束，例如一个特定的业务场景，三个字段肯定确定唯一性，那么，可以在数据库表添加唯一索引来进行标示。
这里有一个场景，API层面的幂等，例如提交数据，如何控制重复提交，这里可以在提交数据的form表单或者客户端软件，增加一个唯一标示，然后服务端，根据这个UUID来进行去重，这样就能比较好的做到API层面的唯一标识。
7.状态机幂等
在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
以上就是高并发系统数据幂等的解决方案的资料整理，后续继续补充相关知识，谢谢大家对本站的支持！
-
主要内容：1.难题与方案,2.具体措施,3.九种技术架构1.难题与方案 1、亿级流量电商网站的商品详情页系统架构 面临难题：对于每天上亿流量，拥有上亿页面的大型电商网站来说，能够支撑高并发访问，同时能够秒级让最新模板生效的商品详情页系统的架构是如何设计的? 解决方案：异步多级缓存架构+nginx本地化缓存+动态模板渲染的架构 2、redis企业级集群架构 面临难题：如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数
-
本文向大家介绍高并发系统的限流详解及实现，包括了高并发系统的限流详解及实现的使用技巧和注意事项，需要的朋友参考一下 在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。本文结合作者的一些经验介绍限流的相关概念、算法和常规的实现方式。 缓存 缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库
-
主要内容：一、前情提示,二、基于消息中间件的队列消费模型,三、基于消息中间件的“Pub/Sub”模型,四、RabbitMQ中的exchange到底是个什么东西？,五、默认的exchange,六、将消息投递到fanout exchange,七、绑定自己的队列到exchange上去消费,八、整体架构图一、前情提示 上一篇文章《高并发+海量数据下如何实现系统解耦？【中】》分析了一下如何利用消息中间件对系统进行解耦处理。 同时，我们也提到了使用消息中间件还有利于一份数据被多个系统同时订阅，供多个系统来使
-
主要内容：一、写在前面,二、背景回顾,三、实时计算平台与数据查询平台之间的耦合,四、下集预告一、写在前面 之前更新过一个“亿级流量系统架构”系列，主要讲述了一个大规模商家数据平台的如下几个方面： 如何承载百亿级数据存储 如何设计高容错的分布式架构 如何设计承载百亿流量的高性能架构 如何设计每秒数十万并发查询的高并发架构 如何设计全链路99.99%高可用架构。 接下来，我们将会继续通过几篇文章，对这套系统的可扩展架构、数据一致性保障等方面进行探讨。 如果没看过本系列文章的同学可以先回过头看
-
主要内容：一、前情提示,二、清晰的划分系统边界,三、引入消息中间件解耦,四、利用消息中间件削峰填谷,五、手动流量开关配合数据库运维操作,六、支持多系统同时订阅数据,七、系统解耦后的感受一、前情提示 上一篇文章《高并发+海量数据下如何实现系统解耦？【上】》，给大家初步讲述了一套大规模复杂系统中，两个核心子系统之间一旦耦合，会发生哪些令人崩溃的场景。如果还没看上篇文章的，建议先看一下。 这篇文章，咱们就给大家来说一说通过MQ消息中间件的使用，如何重构系统之间的耦合，让系统具备高度的可扩展性。 首先来
-
本文向大家介绍PHP利用Mysql锁解决高并发的方法，包括了PHP利用Mysql锁解决高并发的方法的使用技巧和注意事项，需要的朋友参考一下 前面写过利用文件锁来处理高并发的问题的，现在我们说另外一个处理方式，利用Mysql的锁来解决高并发的问题 先看没有利用事务的时候并发的后果 创建库存管理表 创建订单管理表 测试代码 我们预置库存是十个，然后执行ab测试查看结果 得到了订单共有12个，而库存表的