济南企业型网站,响应式网站视频,WordPress如何更改文章链接,百度学术论文查重官网一、何为幂等性#xff1f;其任意多次执行所产生的影响均与一次执行的影响相同从对系统的影响结果来说#xff1a;At least once 幂等消费 Exactly once。那么如何实现幂等操作呢#xff1f;最好的方式就是#xff0c;从业务逻辑设计上入手#xff0c;将消费的业务逻辑设…一、何为幂等性其任意多次执行所产生的影响均与一次执行的影响相同从对系统的影响结果来说At least once 幂等消费 Exactly once。那么如何实现幂等操作呢最好的方式就是从业务逻辑设计上入手将消费的业务逻辑设计成具备幂等性的操作。但是不是所有的业务都能设计成天然幂等的这里就需要一些方如果一个函数 f(x) 满足f(f(x)) f(x)则函数 f(x) 满足幂等性。法和技巧来实现幂等。二、常见幂等性实现实现方式1.利用数据库的唯一约束实现幂等发起请求前预先生成id正常执行业务逻辑如果已经消费过报违反唯一性约束。未消费过正常执行成功。2.为更新的数据设置前置条件(1)业务性条件给数据变更设置一个前置条件如果满足条件就更新数据否则拒绝更新数据在更新数据的时候同时变更前置条件中需要判断的数据。这样重复执行这个操作时由于第一次更新数据的时候已经变更了前置条件中需要判断的数据不满足前置条件则不会重复执行更新数据操作。比如刚刚我们说过“将账户 X 的余额增加 100 元”这个操作并不满足幂等性我们可以把这个操作加上一个前置条件变为“如果账户 X 当前的余额为 500 元将余额加100 元”这个操作就具备了幂等性。对应到消息队列中的使用时可以在发消息时在消息体中带上当前的余额在消费的时候进行判断数据库中当前余额是否与消息中的余额相等只有相等才执行变更操作。基于这个思路不光是可以使用关系型数据库只要是支持类似“INSERT IF NOTEXIST”语义的存储类系统都可以用于实现幂等比如你可以用 Redis 的 SETNX 命令来替代数据库中的唯一约束来实现幂等消费。(2)类似数据库乐观锁--增加一个version字段借鉴数据库的乐观锁机制如update t_goods set count count -1 , version version 1 where good_id2 and version 1根据version版本也就是在操作库存前先获取当前商品的version版本号然后操作的时候带上此version号。我们梳理下我们第一次操作库存时得到version为1调用库存服务version变成了2但返回给订单服务出现了问题订单服务又一次发起调用库存服务当订单服务传如的version还是1再执行上面的sql语句时就不会执行因为version已经变为2了where条件就不成立。这样就保证了不管调用几次只会真正的处理一次。3.记录并检查操作如果上面提到的两种实现幂等方法都不能适用于你的场景我们还有一种通用性最强适用范围最广的实现幂等性方法记录并检查操作也称为“Token 机制或者 GUID(全局唯一 ID)机制”实现的思路特别简单在执行数据更新操作之前先检查一下是否执行过这个更新操作。具体的实现方法是在发送消息时给每条消息指定一个全局唯一的 ID消费时先根据这个 ID 检查这条消息是否有被消费过如果没有消费过才更新数据然后将消费状态置为已消费。原理和实现是不是很简单其实一点儿都不简单在分布式系统中这个方法其实是非常难实现的。首先给每个消息指定一个全局唯一的 ID 就是一件不那么简单的事儿方法有很多但都不太好同时满足简单、高可用和高性能或多或少都要有些牺牲。更加麻烦的是在“检查消费状态然后更新数据并且设置消费状态”中三个操作必须作为一组操作保证原子性才能真正实现幂等否则就会出现 Bug。比如说对于同一条消息“全局 ID 为 8操作为给 ID 为 666 账户增加 100 元”有可能出现这样的情况这样就会导致账户被错误地增加了两次 100 元这是一个在分布式系统中非常容易犯的错误一定要引以为戒。t0 时刻Consumer A 收到条消息检查消息执行状态发现消息未处理过开始执行“账户增加 100 元”t1 时刻Consumer B 收到条消息检查消息执行状态发现消息未处理过因为这个时刻Consumer A 还未来得及更新消息执行状态。对于这个问题当然我们可以用事务来实现也可以用锁来实现但是在分布式系统中无论是分布式事务还是分布式锁都是比较难解决问题。参考
