互联网如何做旅游网站网站开发新闻管理系统的背景

互联网如何做旅游网站,网站开发新闻管理系统的背景,网络结构有哪几种,网站建设中asp文件MySQL死锁排查指南MySQL死锁排查指南一、先搞懂#xff1a;死锁是什么#xff1f;二、经典场景#xff1a;Java业务里的死锁长啥样#xff1f;三、死锁排查#xff1a;核心步骤命令步骤1#xff1a;查看死锁日志步骤2#xff1a;结合Java业务定位代码四、根治死锁#…MySQL死锁排查指南MySQL死锁排查指南一、先搞懂死锁是什么二、经典场景Java业务里的死锁长啥样三、死锁排查核心步骤命令步骤1查看死锁日志步骤2结合Java业务定位代码四、根治死锁Java业务里的落地方案方案1约定统一的加锁顺序最有效流程展示方案2缩短事务范围方案3优化数据库层面(按需)MySQL死锁排查指南作为一名10年经验的Java工程师我会从场景、排查、解决三个维度带你搞定MySQL死锁问题。一、先搞懂死锁是什么死锁是多个事务互相持有对方需要的资源陷入无限等待的僵局。它必须同时满足4个“缺一不可”的条件破坏任意一个就能避免死锁资源独占一个资源如一行数据只能被一个事务持有请求并持有事务持有资源的同时又请求其他资源且不释放已有资源不可剥夺事务已获得的资源不能被强行抢占循环等待事务之间形成“事务A等BB等A”的闭环。二、经典场景Java业务里的死锁长啥样以用户互转余额为例JavaMySQL事务// 事务A用户A给B转账10元TransactionalpublicvoidtransferAtoB(StringaId,StringbId,intamount){// 1. 锁定A的账户更新操作会加行锁accountMapper.updateBalance(aId,-amount);// 2. 尝试锁定B的账户若B此时正在操作A就会等待accountMapper.updateBalance(bId,amount);}// 事务B用户B给A转账20元TransactionalpublicvoidtransferBtoA(StringbId,StringaId,intamount){// 1. 锁定B的账户accountMapper.updateBalance(bId,-amount);// 2. 尝试锁定A的账户此时A已被事务A锁定陷入等待accountMapper.updateBalance(aId,amount);}当两个事务同时执行时事务A持有A的锁等待B的锁事务B持有B的锁等待A的锁→ 死锁产生。三、死锁排查核心步骤命令当业务出现“接口超时、事务卡住”时优先排查死锁。步骤1查看死锁日志MySQLInnoDB引擎最核心的排查命令SHOWENGINEINNODBSTATUS;执行后找到LATEST DETECTED DEADLOCK模块关键信息包括TRANSACTION (1)/(2)冲突的两个事务WAITING FOR THIS LOCK事务等待的锁及对应的SQLHOLDS THE LOCK(S)事务持有的锁及对应的SQLWE ROLL BACK TRANSACTION (X)MySQL自动回滚的事务解决死锁。步骤2结合Java业务定位代码根据死锁日志里的SQL语句找到对应的Java代码比如上述transferAtoB方法分析事务的加锁顺序是否不一致。四、根治死锁Java业务里的落地方案针对Java业务从代码、数据库两个层面解决方案1约定统一的加锁顺序最有效我们约定一个全局规则无论转账方向如何都先锁定 ID 字典序更小的账户再锁定 ID 更大的账户这就是 “统一的加锁顺序”ServicepublicclassTransferService{AutowiredprivateAccountMapperaccountMapper;// 统一的转账方法无论谁转谁都按ID大小顺序加锁Transactionalpublicvoidtransfer(StringfromId,StringtoId,intamount){// 步骤1确定加锁顺序全局统一规则StringlockFirstId;// 先锁这个IDStringlockSecondId;// 后锁这个IDif(fromId.compareTo(toId)0){lockFirstIdfromId;lockSecondIdtoId;}else{lockFirstIdtoId;lockSecondIdfromId;}// 步骤2按统一顺序加锁先锁小ID再锁大ID// 先锁定第一个账户无论它是转出方还是转入方if(lockFirstId.equals(fromId)){accountMapper.deductBalance(lockFirstId,amount);// 转出}else{accountMapper.addBalance(lockFirstId,amount);// 转入}// 再锁定第二个账户if(lockSecondId.equals(fromId)){accountMapper.deductBalance(lockSecondId,amount);// 转出}else{accountMapper.addBalance(lockSecondId,amount);// 转入}}}假设A 的 ID 是user_001B 的 ID 是user_002user_001 user_002。当调用transfer(“user_001”, “user_002”, 10)A 转 B先锁user_001再锁user_002当调用transfer(“user_002”, “user_001”, 20)B 转 A依然先锁user_001再锁user_002两个事务的加锁顺序完全一致不会出现 “你等我、我等你” 的循环等待从根源上杜绝死锁。流程展示用户AID为user_001用户BID为user_002规则user_001的字典序 user_002无统一加锁顺序 → 死锁执行流程当两个事务各自按“转出方→转入方”的顺序加锁时时间线事务1A转B先锁A再锁B事务2B转A先锁B再锁A状态T1执行deductBalance(user_001, 10)成功锁定user_001-事务1持有A的锁T2-执行deductBalance(user_002, 20)成功锁定user_002事务2持有B的锁T3尝试执行addBalance(user_002, 10)需要锁B → 等待-事务1等待B的锁T4-尝试执行addBalance(user_001, 20)需要锁A → 等待事务2等待A的锁T5持续等待B的锁持续等待A的锁死锁有统一加锁顺序 → 无死锁执行流程当两个事务都按“ID从小到大”的顺序加锁时时间线事务1A转B先锁A再锁B事务2B转A先锁A再锁B状态T1执行deductBalance(user_001, 10)成功锁定user_001-事务1持有A的锁T2-尝试执行addBalance(user_001, 20)需要锁A → 等待事务2等待A的锁T3执行addBalance(user_002, 10)成功锁定user_002-事务1持有A、B的锁T4事务执行完成释放A、B的锁-事务1提交锁释放T5-获得A的锁执行addBalance(user_001, 20)事务2持有A的锁T6-执行deductBalance(user_002, 20)成功锁定user_002事务2持有A、B的锁T7-事务执行完成释放A、B的锁事务2提交无死锁这样是不是更清楚了需要我把这个流程做成更简洁的对比表格方便你保存吗方案2缩短事务范围避免事务中包含非数据库操作如RPC调用、日志打印减少锁的持有时间// 坏例子事务包含RPC调用加长锁持有时间TransactionalpublicvoidbadTransfer(StringfromId,StringtoId,intamount){accountMapper.updateBalance(fromId,-amount);rpcClient.notifyThirdParty(fromId,toId,amount);// 非DB操作加长事务accountMapper.updateBalance(toId,amount);}// 好例子事务仅包含DB操作TransactionalpublicvoidgoodTransfer(StringfromId,StringtoId,intamount){accountMapper.updateBalance(fromId,-amount);accountMapper.updateBalance(toId,amount);}// 非DB操作放在事务外publicvoidtransferWithNotify(StringfromId,StringtoId,intamount){goodTransfer(fromId,toId,amount);rpcClient.notifyThirdParty(fromId,toId,amount);}方案3优化数据库层面(按需)加索引确保更新/查询的WHERE条件走索引减少锁的范围避免表锁降低隔离级别业务允许的话将隔离级别从REPEATABLE-READ默认降为READ-COMMITTED减少间隙锁显式加锁优化使用SELECT ... FOR UPDATE显式加锁时确保WHERE条件走索引。