1. “设备Aの奇怪分身”
时间回到很久很久以前的一个深夜，那时我开发的多媒体广告播放控制系统刚刚投产上线，公司开出的第一家线下生鲜店里，几十个大大小小的多媒体硬件设备正常联网后，正由我一台一台的注册及接入到已经上线的多媒体广告播控系统中。
注册过程简述如下：
每一个设备注册到系统中后，相应的在数据库设备表中都会新增一条记录，来存储这个设备的各项信息。
本来一切都有条不紊的进行着，直到设备A的注册打破了这默契的宁静……
设备A注册完成后，我突然发现，数据库设备表中，新增了 两条 记录，而且是 两条一模一样 的记录！
我开始以为自己眼花了……
仔细一看，确确实实是新增了两条，而且连设备唯一标识（划横线，后面要考）和创建时间都一模一样！
看着屏幕，我陷入了沉思……
为什么会有两条呢？
在我的注册逻辑里，落库之前会先查一遍数据库该设备是否已存在，如果存在就更新已有的，不存在才新增。
所以我百思不得其解，按这个逻辑，第二条一模一样的数据是哪来的？
2. 真相背后的并发请求
经过一番排查及思考，我发现问题可能就出在注册请求上。
设备A在向云端发送http注册请求时，可能会同时发送多个相同请求。
云服务器当时部署在多台Docker容器上，通过查看日志发现，有两台容器同时收到了来自设备A的注册请求。
由此，我推测：
设备A同时发送了两个注册请求，这两个请求分别在同一时间打到了云端的不同容器上，按照我的注册逻辑，这两个容器接收到注册请求后，同时去查询了数据库的设备表，这时候设备表里还没有设备A的记录，所以两台容器都执行了新增的操作，因为速度很快，所以这两条新增记录在 精确到秒 的创建时间上，并没有体现出差别。
3. 并发新增的延伸
既然并发的新增操作会产生问题，那么并发的更新操作是否会有问题呢？
解决方法
解决并发新增
1. 数据库唯一索引（UNIQUE INDEX）
在数据库建表的时候，通过对具有唯一性的字段（比如上述的设备唯一标识）创建唯一索引，或对组合起来后就具备唯一性的几个字段创建联合唯一索引。
这样在并发新增时，只要有一个新增成功，其他的新增操作都会因为数据库抛出的异常（java.sql.SQLIntegrityConstraintViolationException）而失败，我们只需要处理好新增失败的情况就行了。
注意唯一索引的字段需要非空，因为字段值为空时会导致唯一索引约束失效
2. java分布式锁
通过在程序中引入分布式锁，在进行新增操作前需要先获取分布式锁，获取成功才能继续，否则新增失败。
这样也能解决并发插入带来的数据重复问题，只是引入分布式锁的同时也增加了系统的复杂性，如果要落库的数据上有唯一性字段的话，还是推荐采用唯一索引的方法。
在构建分布式锁的过程中，我们需要用到Redis，这里以设备注册时使用的分布式锁为例。
分布式锁简单问答：
Q：锁究竟是什么？
A：锁实质上是存储在Redis中，基于特定规则生成的一个字符串（示例里是固定前缀+设备唯一标识），相当于每个设备注册的时候都有自己对应的一把锁，因为锁只有一把，即使该设备有多个相同的注册请求同时到来，也只有其中获取到那把锁的那一个请求能成功走下去。
Q：什么是获取锁？
A：同一个设备，基于相同的规则生成的字符串（后文以Key代称该字符串）总是相同的，在执行新增操作前，先去Redis中查询这个Key是否存在，如果已存在，就意味着获取锁失败；如果不存在，就将这个Key现存到Redis中，如果存储成功，表示获取锁成功，如果存储失败，还是意味着获取锁失败。
Q：锁是怎么工作的？
A：前面说过，同一个设备，基于相同的规则生成的字符串（Key）总是相同的，在当前线程执行新增操作前，先在Redis中查询这个Key是否存在，如果已存在，表示此时已经有别的线程成功获取了锁，正在做当前线程想要做的新增操作，则当前线程不需要进行后续操作了（是的，你是多余的）
当这个Key不存在时，表示现在还没有其他线程获得锁，则当前线程可以继续进行下一步操作——在Redis中赶紧存入这个Key，当这个Key存储失败时，意味着有别的线程抢先存入了Key成功获取了锁，当前线程晚了一步，想做的工作被别人抢先做了（当前线程可以退下了）
当且仅当在Redis中存入这个Key也成功时，表示当前线程终于获取锁成功，可以安心进行后面的新增操作了，期间别的想做相同新增操作的线程因为获取不到锁，只能全都退场拜拜👋，当前线程执行完后要记得释放锁（从Redis中删除这个Key）。
注册时使用的分布式锁代码如下：
public class LockUtil {
// 对redis底层set/get方法进行了简单封装的工具类
@Autowired
private RedisService redisService;
// 生成锁的固定前缀，从配置文件读取值
@Value(“${redis.register.prefix}”)
private String REDIS_REGISTER_KEY_PREFIX;
// 锁过期时间：即获取锁后线程能进行操作的最长时间，超过该时间后锁自动被释放（失效），别人可以重新开始获取锁进行对应操作
// 设定锁过期时间是为了防止某线程成功获取锁后在执行任务过程中发生意外挂掉了造成锁永远无法被释放
@Value(“${redis.register.timeout}”)
private Long REDIS_REGISTER_TIMEOUT;
/**
-
获取设备注册时的分布式锁
-
@param deviceMacAddress 设备的Mac地址
-
@return
*/
public boolean getRegisterLock(String deviceMacAddress) {
if (StringUtils.isEmpty(deviceMacAddress)) {
return false;
}
// 获取设备对应锁的字符串（Key）
String redisKey = getRegisterLockKey(deviceMacAddress);
// 开始尝试获取锁
// 如果当前任务锁key已存在，则表示当前时间内有其他线程正在对该设备执行任务，当前线程可以退下了
if (redisService.exists(redisKey)){
return false;
}
// 开始尝试加锁，注意此处需使用SETNX指令（因为可能存在多个线程同时到达这一步开始加锁，使用SETNX来确保有且仅有一个设置成功返回）
boolean setLock = redisService.setNX(redisKey, null);
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
总结
大型分布式系统犹如一个生命，系统中各个服务犹如骨骼，其中的数据犹如血液，而Kafka犹如经络，串联整个系统。这份Kafka源码笔记通过大量的设计图展示、代码分析、示例分享，把Kafka的实现脉络展示在读者面前，帮助读者更好地研读Kafka代码。
麻烦帮忙转发一下这篇文章+关注我
可以添加V获取：vip1024b （备注Java）**
[外链图片转存中…(img-tCcdkW1i-1711956459268)]
总结
大型分布式系统犹如一个生命，系统中各个服务犹如骨骼，其中的数据犹如血液，而Kafka犹如经络，串联整个系统。这份Kafka源码笔记通过大量的设计图展示、代码分析、示例分享，把Kafka的实现脉络展示在读者面前，帮助读者更好地研读Kafka代码。
麻烦帮忙转发一下这篇文章+关注我
[外链图片转存中…(img-22agssWT-1711956459268)]
1485
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
