开心一刻

  有个问题一直困扰着我:许仙选择了救蛇,为什么杨过却选择救雕(而不救蛇)

  后面想想,其实杨过救神雕是有原因的,当年神雕和巨蛇打架的时候

  雕对杨过说:杀蛇,杀蛇,杀蛇!

  蛇对杨过说:杀雕,杀雕,杀雕!

  杨过果断选择了杀蛇

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

业务场景

  业务描述

  业务上有这样的需求,张三、李四两个用户,如果互相关注则成为好友

  设计上有两张表,关注关系表: tbl_follow 

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  朋友关系表: tbl_friend 

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  我们以张三关注李四为例,业务实现流程是这样的

    1、先查询李四有没有关注张三

    2、如果李四关注了张三,则成为好友,往 tbl_friend 插入一条记录;如果李四没有关注张三,则只是张三单向关注李四,往 tbl_follow 插入一条记录

  看似没问题,可如果我们从并发的角度来看,是不是还正常了?

  如果张三、李四同时关注对方,那么业务实现流程的第 1 步得到的结果可能就是双方都没有关注对方(加数据库的排他锁也没用,记录不存在,行锁无法生效)

  得到的结果就是张三关注李四、李四关注张三,但张三和李四没有成为朋友,这就导致了与业务需求不符!

  问题复现

  相关环境如下

   MySQL : 5.7.21-log ,隔离级别 RR

   Spring Boot : 2.1.0.RELEASE 

   MyBatis-Plus : 3.1.0 

  核心代码如下

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  完整代码见:mybatis-plus-demo

  我们来复现下问题

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  正确结果应该是: tbl_follow 、 tbl_friend 中各插入一条记录

  但目前的结果是只往 tbl_follow 中插了两条记录

  该如何处理该问题,欢迎大家评论区留言

JVM 锁

  既然并发了,那就加锁呗

  JVM 自带的 synchronized 和 Lock 都有同步作用,我们以 synchronized 为例,来看看效果

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

   tbl_follow 和 tbl_friend 中各插入一条记录,问题得到解决!

  但是完美吗?如果项目是集群部署,张三、李四关注对方的请求分别落在了集群中不同的节点上,不能成为好友的问题会不会出现?

分布式锁

  因为 JVM 锁只能控制同个 JVM 进程的同步,控制不了不同 JVM 进程间的同步,所有如果项目是集群部署,那么就需要用分布式锁来控制同步了

  关于分布式锁,我就不多说了,网上资料太多了,推荐一篇:再有人问你分布式锁,这篇文章扔给他

  如果用分布式锁去解决上述案例的问题,楼主就不去实现了,只是强调一个小细节:如何保证 张三关注李四 、 李四关注张三 它们申请同一把锁

  以 Redis 实现为例, key 的命名是有规范的,比如:业务名:方法名:资源名,具体到如上的案例中, key 的名称:user:follow:123:456

  如果 张三关注李四 申请的 user:follow:123:456 ,而 李四关注张三 申请的是 user:follow:456:123 ,那么申请的都不是同一把锁,自然也就没法控制同步了

  所以申请锁之前,需要进行一个小细节处理,将 followId 与 userId 进行排序处理,小的放前面,大的放后面,类似: user:follow:小id:大id 

  那么就能保证它们申请的是同一把锁,自然就能控制同步了

唯一索引

  接下来要讲的实现方式不常见,但是挺有意思的,大家仔细看

  我们改造一下 tbl_follow ,另取名字 tbl_follow_plus 

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  注意字段看字段的描述

  tbl_follow 中 user_id 固定为 被关注者 , tbl_follow 中 follower_id 固定为 关注者 

  tbl_follow_plus 中 one_side_id 和 other_side_id 没有固定谁是 关注者 ,谁是 被关注者 ,而是通过 relation_ship 的值来指明谁关注谁

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  业务实现

  当 one_side_id 关注 other_side_id 的时候,比较它俩的大小

  若 one_side_id < other_side_id ,执行如下逻辑

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  若 one_side_id > other_side_id ,则执行如下逻辑

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  不太容易看懂,我们直接看代码实现

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  执行效果如下

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  我们分析下结果

  tbl_follow_plus 只插入了一条记录

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  relation_ship = 3 表示双向关注

  tbl_friend 插入了一条记录

记一次有意思的业务实现 → 单向关注是关注,双向关注则成好友-LMLPHP

  同时关注 这个业务就实现了

  有小伙伴就有疑问了:楼主你只分析了 one_side_id 关注 other_side_id 的情况,没分析 other_side_id 关注 one_side_id 的情况呀

  大家注意看 tbl_follow_plus 表中各个列名的注释, one_side_id 和 other_side_id 并不是具体的 关注者 和 被关注者 ,两者的业务含义是等价的

  至于是谁关注谁,是通过 relation_ship 的值来确定的,所以 one_side_id 关注 other_side_id 和 other_side_id 关注 one_side_id 是一样的

  至于适不适用单向关注的情况,大家自行去验证

  原理分析

  虽然业务需求是实现了,但却难以理解,让我们一步一步往下分析

  1、为什么要比较 one_side_id 和 other_side_id 的大小?

     tbl_follow_plus 有个唯一索引 UNIQUE KEY `uk_one_other` (`one_side_id`,`other_side_id`) 

    比较大小的目的就是保证 tbl_follow_plus 的 one_side_id 记录的是小值,而 other_side_id 记录的是大值

    例如 123 关注 456 , one_side_id = 123 , other_side_id = 456 , relation_ship = 1 

       456 关注 123 , one_side_id = 123 , other_side_id = 456 ,但 relation_ship = 2 

    那这有什么用?

    还记得我在上面的 分布式锁 实现方案中强调的那个细节吗

    这里比较大小的作用也是为了保证 123 关注 456 与 456 关注 123 在唯一索引上竞争的是用一把行锁

  2、insert … on duplicate key update

    其作用简单点说就是:数据库表中存在某个记录时,执行这个语句会更新,而不存在这条记录时,就会插入

    有个前置条件:只能基于唯一索引或主键使用;具体细节可查看:记录不存在则插入,存在则更新 → MySQL 的实现方式有哪些?

     insert ... on duplicate 确保了在事务内部,执行了这个 SQL 语句后,就占住了这个行锁(先占锁,再执行 SQL)

    确保了之后查询 relation_ship 的逻辑是在行锁保护下的读操作

  3、relation_ship=relation_ship | 1(relation_ship=relation_ship | 2)

    这个写法就有点巧妙了,这里的 | 指的是 按位或运算 

     relation_ship 的值是在业务代码中指定的,只能是 1 或者 2

    因为在 MySQL 层面有个唯一索引的 行锁 ,所以 123 关注 456 和 456 关注 123 的事务之间存在锁竞争,必定是串行的

    3.1 若先执行 123 关注 456 的事务, relation_ship 传入的值是 1,事务执行完之后, relation_ship 的值等于 1 | 1 = 1 ;

      再执行 456 关注 123 的事务, relation_ship 传入的值是 2,事务执行完之后, relation_ship 的值等于 1 | 2 = 3 

    3.2 若先执行 456 关注 123 的事务, relation_ship 传入的值是 2,事务执行完之后, relation_ship 的值等于 2 | 2 = 2 ;

      再执行 123 关注 456 的事务, relation_ship 传入的值是 1,事务执行完之后, relation_ship 的值等于 2 | 1 = 3 

    这里也可以看出 relation_ship 的枚举值也不是随意的,当然也可以选择其他的,但是需要满足如上的位运算逻辑

  4、insert ignore into friend

    其作用简单点说就是:数据库表中存在该记录时忽略,不存在时插入

    同样也是基于主键或唯一索引使用

  另外,在重复调用时,按位或(|)和 insert ignore 可以保证幂等性

总结

  1、就文中这个业务而言,唯一索引的实现可读性太差,不推荐大家使用

  2、 insert into on duplicate key update 和 insert ignore into 还是比较常见的,最好掌握它们

参考

  《MySQL 实战 45 讲》

06-06 10:46