有个问题一直困扰着我：许仙选择了救蛇，为什么杨过却选择救雕（而不救蛇）
后面想想，其实杨过救神雕是有原因的，当年神雕和巨蛇打架的时候
雕对杨过说：杀蛇，杀蛇，杀蛇！
蛇对杨过说：杀雕，杀雕，杀雕！
杨过果断选择了杀蛇
业务上有这样的需求，张三、李四两个用户，如果互相关注则成为好友
设计上有两张表，关注关系表： 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 讲》