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

打印 上一主题 下一主题

主题 647|帖子 647|积分 1941

开心一刻

  有个问题一直困扰着我:许仙选择了救蛇,为什么杨过却选择救雕(而不救蛇)
  后面想想,其实杨过救神雕是有原因的,当年神雕和巨蛇打架的时候
  雕对杨过说:杀蛇,杀蛇,杀蛇!
  蛇对杨过说:杀雕,杀雕,杀雕!
  杨过果断选择了杀蛇

业务场景

  业务描述

  业务上有这样的需求,张三、李四两个用户,如果互相关注则成为好友
  设计上有两张表,关注关系表: 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 讲》

来源:https://www.cnblogs.com/youzhibing/p/16273601.html
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

勿忘初心做自己

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表