目录

前言

一、CRUD

1、增加

2、查询

3、修改、删除

---

前言

CRUD分为两部分：读、写。 其中「读」是：查询，「写」是：增加、删除、修改。

- 针对「读」的编码是相对而言比较容易的，我们需要留意一下查询性能；

- 针对「写」的编码就更需要用心了，因为需要考虑并发。

一、CRUD

1、增加

增加是比较麻烦点的，因为你需要考虑幂等。此处，我是借助数据库的唯一索引实现幂等操作（这种方式也可以用作MQ处理幂等）。

 

步骤：

1、先从数据库中查询，如果已经查到，说明该记录数据库已经存在，则return；

-- 这一步可以解决大部分的并发问题，但是有一种场景解决不了：数据库在「可重复读」隔离级别下，事务1已经插入数据库但是事务1还没有commit，此时事务2来读的时候是读取不到的，此时138行的info为null（实际事务1已经把数据插入到了数据库），那么事务2将再次执行一个插入操作。

2、为了解决上面的场景，我们给数据库中的auditInfoId(雪花算法计算出的唯一值)添加唯一索引，那么当事务2执行插入操作，就会报DuplicateKeyException异常，我们catch住，做个日志输出即可。

2、查询

1、留意输出一下日志；

3、修改、删除

我们一般用的都是「逻辑删除」，此处把删除和修改归为一类。

步骤：

1、修改之前，我们需要确保数据库中该数据是否真实存在？

2、查询出结果之后，将该数据的version记录下来，使用乐观锁的方式进行修改；

3、最后，再执行我们的修改操作。

思考：

        以上代码的业务背景是：管理员来对工单进行审核(修改)，并发量很低。并且，你可以理解为是「非计数性的修改」(非++、--操作)。

        扩展点来想：如果是几千个用户，对一类商品进行下单，此处代码是来处理库存，那么就是「计数性的修改」(可以理解是++、--操作)，那么上面的代码肯定不符合要求。

        我们必须搞明白：并发是针对临界资源的，也可以理解是共享资源。根据用户行为来分析：如果几千甚至上万个用户只是来修改各自的用户名、性别，那么这些数据对整个系统而言都是用户私有的，用户数量多造成QPS高但是并发不是很高(因为修改自己的用户名等不涉及共享资源)；如果是几千甚至上万个用户来抢10个手机，那么10就是共享资源，这时候的修改操作可不再是上图简单的实现了。