只有双向关注_反复关注取关

开心一刻

　　有个问题一直困扰着我：许仙选择了救蛇，为什么杨过却选择救雕（而不救蛇）

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

　　雕对杨过说：杀蛇，杀蛇，杀蛇！

　　蛇对杨过说：杀雕，杀雕，杀雕！

　　杨过果断选择了杀蛇

业务场景

　　业务描述

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

　　设计上有两张表，关注关系表： tbl_follow 

　　朋友关系表： tbl_friend 

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

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

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

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

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

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

　　问题复现

　　相关环境如下

　　 MySQL ： 5.7.21-log ，隔离级别 RR

　　 Spring Boot ： 2.1.0.RELEASE 

　　 MyBatis-Plus ： 3.1.0 

　　核心代码如下

　　完整代码见：mybatis-plus-demo

　　我们来复现下问题

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

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

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

JVM 锁

　　既然并发了，那就加锁呗

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

　　 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 

　　注意字段看字段的描述

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

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

　　业务实现

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

　　若 one_side_id < other_side_id ，执行如下逻辑

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

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

　　执行效果如下

　　我们分析下结果

　　tbl_follow_plus 只插入了一条记录

　　relation_ship = 3 表示双向关注

　　tbl_friend 插入了一条记录

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

　　有小伙伴就有疑问了：楼主你只分析了 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 讲》