携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第28天,点击查看活动详情 >>

接口幂等性2

5. 悲观锁

使用数据库层面，效率低，sql加锁：

select * from table where id = 'xxx' for update;

注意，id 字段一定要是主键或者唯一索引，否则会导致锁表。

悲观锁的使用一般伴随事务一起使用，数据锁定事件可能会很长，正常情况来说一般都是不用的

6. 乐观锁

乐观锁只是在更新数据的那一刻锁表，其他时间不锁表，所以相对于悲观锁效率更高。

乐观锁的实现方式多种多样，可以通过 version 或者其他状态条件。

7. 分布式锁

还是拿插入数据的例子，如果是分布式系统，构建全局唯一索引比较困难，例如唯一性的字段无法确定。那么这时候就可以引入分布式锁，通过第三方的系统（Redis 或 Zookeeper），在业务系统插入数据或更新数据，获取分布式锁，然后做操作，之后再释放锁。这样其实是把多线程并发锁的思路引入了多个系统，也就是分布式系统中的解决思路。

要注意的是，某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志（用户 ID + 后缀等）获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁（分布式锁需要第三方系统提供)）

8.select+insert

对于一些并发不高的后台系统，或者一些任务 Job，为了支持幂等，支持重复执行，简单的处理方法是先查询下一些关键数据，判断是否已经执行过，然后再进行业务处理就可以了。就是先查询，后再进行数据操作，这样确保了数据的一致性，但是性能较差通常不使用。