如何区分单向关注与双向好友在业务实现中的具体操作？
- 内容介绍
- 文章标签
- 相关推荐
本文共计2270个文字，预计阅读时间需要10分钟。
一开始，我遇到一个问题让我很困扰：救蜜蜂还是救神鹰？为什么选择救神鹰而不是蜜蜂？后来想想，原来是有原因的。当年神鹰和巨鹰打架时，神鹰对巨鹰说：杀蜜蜂！于是就有了这个选择。
开心一刻有个问题一直困扰着我：许仙选择了救蛇，为什么杨过却选择救雕（而不救蛇）
后面想想，其实杨过救神雕是有原因的，当年神雕和巨蛇打架的时候
雕对杨过说：杀蛇，杀蛇，杀蛇！
蛇对杨过说：杀雕，杀雕，杀雕！
杨过果断选择了杀蛇
业务场景 业务描述业务上有这样的需求，张三、李四两个用户，如果互相关注则成为好友
设计上有两张表，关注关系表：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 讲》
本文共计2270个文字，预计阅读时间需要10分钟。
一开始，我遇到一个问题让我很困扰：救蜜蜂还是救神鹰？为什么选择救神鹰而不是蜜蜂？后来想想，原来是有原因的。当年神鹰和巨鹰打架时，神鹰对巨鹰说：杀蜜蜂！于是就有了这个选择。
开心一刻有个问题一直困扰着我：许仙选择了救蛇，为什么杨过却选择救雕（而不救蛇）
后面想想，其实杨过救神雕是有原因的，当年神雕和巨蛇打架的时候
雕对杨过说：杀蛇，杀蛇，杀蛇！
蛇对杨过说：杀雕，杀雕，杀雕！
杨过果断选择了杀蛇
业务场景 业务描述业务上有这样的需求，张三、李四两个用户，如果互相关注则成为好友
设计上有两张表，关注关系表：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 讲》