我们实际系统中有很多操作,是不管做多少次,都应该产生一样的效果或返回一样的结果。 例如
幂等(idempotent、idempotence)是一个数学与计算机学概念,常见于抽象代数中。 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
比如一次select id from users where id=1 执行三次,结果一样,但是update score=score+1 from users where id=1 执行三次发生的结果就不一样了。
具体流程步骤:
注意:
对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现,保证原子性
全局唯一 ID 可以用百度的 uid-generator、美团的 Leaf 去生成
具体流程步骤:
具体流程步骤:
1. 客户端先请求服务端,会拿到一个能代表这次请求业务的唯一字段
2. 将该字段以 SETNX 的方式存入 redis 中,并根据业务设置相应的超时时间
3. 如果设置成功,证明这是第一次请求,则执行后续的业务逻辑
4. 如果设置失败,则代表已经执行过当前请求,直接返回
1.分布式锁
redlock
2.状态机
典型的状态机是松鼠状态机, 状态机的核心思路是假设state=4 如果要改成5,那么之前的状态必须为4,不能为3或者6。因为限制了必须从4变成5,所以多次变更依然是4变成5,不会从4变成6
3.悲观锁
获取数据的时候加锁获取。select * from table_xxx where id='xxx' for update; 注意:id字段一定是主键或者唯一索引,不然是锁表,会死人的悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会很长,根据实际情况选用
4.乐观锁
乐观锁只是在更新数据那一刻锁表,其他时间不锁表,所以相对于悲观锁,效率更高。乐观锁的实现方式多种多样可以通过version或者其他状态条件:1. 通过版本号实现update table_xxx set name=#name#,version=version+1 where version=#version#;2. 通过条件限制 update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0要求:quality-#subQuality# >= ,这个情景适合不用版本号,只更新是做数据安全校验,适合库存模型,扣份额和回滚份额,性能更高
总之,当你去设计一个接口的时候,幂等都是首要考虑的问题,防止数据被重复提交,重复消费,重复扣款等问题发生。电商系统的库存超卖也是个幂等问题。
https://zhuanlan.zhihu.com/p/345512692
https://blog.csdn.net/u011635492/article/details/81058153