上一页 1 ··· 10 11 12 13 14 15 16 17 18 ··· 20 下一页
摘要: 当用户发起请求,此时会请求nginx,nginx会访问到tomcat,而tomcat中的程序,会进行串行操作,分成如下几个步骤 1、查询优惠卷 2、判断秒杀库存是否足够 3、查询订单 4、校验是否是一人一单 5、扣减库存 6、创建订单 在这六步操作中,又有很多操作是要去操作数据库的,而且还是一个线程 阅读全文
posted @ 2022-12-01 23:08 kisshappyboy 阅读(134) 评论(0) 推荐(0) 编辑
摘要: 为了提高redis的可用性,我们会搭建集群或者主从,现在以主从为例 此时我们去写命令,写在主机上, 主机会将数据同步给从机,但是假设在主机还没有来得及把数据写入到从机去的时候,此时主机宕机,哨兵会发现主机宕机,并且选举一个slave变成master,而此时新的master中实际上并没有锁信息,此时锁 阅读全文
posted @ 2022-12-01 15:09 kisshappyboy 阅读(568) 评论(0) 推荐(0) 编辑
摘要: 抢锁过程中,获得当前线程,通过tryAcquire进行抢锁,该抢锁逻辑和之前逻辑相同 1、先判断当前这把锁是否存在,如果不存在,插入一把锁,返回null 2、判断当前这把锁是否是属于当前线程,如果是,则返回null 所以如果返回是null,则代表着当前这哥们已经抢锁完毕,或者可重入完毕,但是如果以上 阅读全文
posted @ 2022-12-01 14:37 kisshappyboy 阅读(856) 评论(0) 推荐(0) 编辑
摘要: 在Lock锁中,他是借助于底层的一个voaltile的一个state变量来记录重入的状态的,比如当前没有人持有这把锁,那么state=0,假如有人持有这把锁,那么state=1,如果持有这把锁的人再次持有这把锁,那么state就会+1 ,如果是对于synchronized而言,他在c语言代码中会有一 阅读全文
posted @ 2022-12-01 11:46 kisshappyboy 阅读(878) 评论(0) 推荐(1) 编辑
摘要: 之前的redis分布式锁已经结束了,实际上还有有些问题, 基于setnx实现的分布式锁存在下面的问题: 重入问题:重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中,可重入锁的意义在于防止死锁,比如HashTable这样的代码中,他的方法都是使用synchronized修饰的,假如他在一个方 阅读全文
posted @ 2022-12-01 11:42 kisshappyboy 阅读(229) 评论(0) 推荐(0) 编辑
摘要: 辑说明: 持有锁的线程在锁的内部出现了阻塞,导致他的锁自动释放,这时其他线程,线程2来尝试获得锁,就拿到了这把锁,然后线程2在持有锁执行过程中,线程1反应过来,继续执行,而线程1执行过程中,走到了删除锁逻辑,此时就会把本应该属于线程2的锁进行删除,这就是误删别人锁的情况说明 解决方案:解决方案就是在 阅读全文
posted @ 2022-11-30 22:56 kisshappyboy 阅读(541) 评论(0) 推荐(0) 编辑
摘要: 通过加锁可以解决在单机情况下的一人一单安全问题,但是在集群模式下就不行了。 有关锁失效原因分析 由于现在我们部署了多个tomcat,每个tomcat都有一个属于自己的jvm,那么假设在服务器A的tomcat内部,有两个线程,这两个线程由于使用的是同一份代码,那么他们的锁对象是同一个,是可以实现互斥的 阅读全文
posted @ 2022-11-29 23:06 kisshappyboy 阅读(180) 评论(0) 推荐(0) 编辑
摘要: 需求:修改秒杀业务,要求同一个优惠券,一个用户只能下一单 现在的问题在于: 优惠卷是为了引流,但是目前的情况是,一个人可以无限制的抢这个优惠卷,所以我们应当增加一层逻辑,让一个用户只能下一个单,而不是让一个用户下多个单 具体操作逻辑如下:比如时间是否充足,如果时间充足,则进一步判断库存是否足够,然后 阅读全文
posted @ 2022-11-29 21:42 kisshappyboy 阅读(49) 评论(0) 推荐(0) 编辑
摘要: 秒杀下单应该思考的内容: 下单时需要判断两点: 秒杀是否开始或结束,如果尚未开始或已经结束则无法下单 库存是否充足,不足则无法下单 下单核心逻辑分析: 当用户开始进行下单,我们应当去查询优惠卷信息,查询到优惠卷信息,判断是否满足秒杀条件 比如时间是否充足,如果时间充足,则进一步判断库存是否足够,如果 阅读全文
posted @ 2022-11-28 23:26 kisshappyboy 阅读(188) 评论(0) 推荐(0) 编辑
摘要: 当用户抢购时,就会生成订单并保存到tb_voucher_order这张表中,而订单表如果使用数据库自增ID就存在一些问题: id的规律性太明显 受单表数据量的限制 场景分析:如果我们的id具有太明显的规则,用户或者说商业对手很容易猜测出来我们的一些敏感信息,比如商城在一天时间内,卖出了多少单,这明显 阅读全文
posted @ 2022-11-28 14:40 kisshappyboy 阅读(107) 评论(0) 推荐(0) 编辑
上一页 1 ··· 10 11 12 13 14 15 16 17 18 ··· 20 下一页