首页
AI Coding
NEW
沸点
课程
直播
活动
AI刷题
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
会员
登录
注册
确定删除此收藏集吗
删除后此收藏集将被移除
取消
确定删除
确定删除此文章吗
删除后此文章将被从当前收藏集中移除
取消
确定删除
编辑收藏集
名称:
描述:
0
/100
公开
当其他人关注此收藏集后不可再更改为隐私
隐私
仅自己可见此收藏集
取消
确定
锁
订阅
小朱先森Ydong
更多收藏集
微信扫码分享
微信
新浪微博
QQ
4篇文章 · 0订阅
Redis 分布式锁 —— Redisson
基于 Redis 的分布式锁优化 基于 setnx 实现的分布式锁存在的问题: 不可重入:同一个线程无法多次获取同一把锁(eg:方法A调用方法B,在方法A中先获取锁,然后去调用方法B,方法B也需要获取
老司机带你玩转面试(6):Redis 分布式锁、并发竞争、双写一致
但是现在突然 A 的网络抖动了一下,导致 A 并不是第一个去 Redis 中写数据的,整个流程的操作顺序变成了 B -> C -> A ,这样数据不就错了么。 这就好比你在网上买东西,加购物车,下订单,支付订单的顺序变掉了,你先下单,再支付,再加购物车,这个流程根本走不下去的好…
详细讲解!从秒杀聊到ZooKeeper分布式锁
经过《ZooKeeper入门》后,我们学会了ZooKeeper的基本用法。 实际上ZooKeeper的应用是非常广泛的,实现分布式锁只是其中一种。接下来我们就ZooKeeper实现分布式锁解决秒杀超卖问题进行展开。 秒杀活动应该都不陌生,不用过多解释。 不难想象,在这种"秒杀"…
基础篇:详解锁原理,synchronized、volatile+cas底层实现
悲观锁,每次去请求数据的时候,都认为数据会被抢占更新(悲观的想法);所以每次操作数据时都要先加上锁,其他线程修改数据时就要等待获取锁。适用于写多读少的场景,synchronized就是一种悲观锁 在请求数据时,觉得无人抢占修改。等真正更新数据时,才判断此期间别人有没有修改过(预…