如果我在清闲的周末打开了idea编辑器，那不代表我在勤奋的学习，那肯定是该死的产品催进度了，草(一种植物)。
工作多年会觉得对待工作热情日益减退，不像未参加工作的小张同学，对工作充满了期待，期待拿第一份工资，期待职场运筹帷幄，而我现在连下班都不期待了，只期待一个平静的周末，没有人打扰我睡懒觉，窗前的小广场没有清晨长按喇叭的傻逼邻居，没有大早上用力敲打公告铁窗的傻逼孩子，当然也没有bug，在欲望不被满足的时候，那真的，对钱不感兴趣，因为啥？因为当下的几千块工资难以维持我的欲望。
技术经理离职？
接到消息其实有点无奈，因为当下业务很多，大家对自己做过的业务都一句话，简单就那点东西，看下代码就行了，因为当初我也是这么对别人说的，交接的时候我觉得这么简单的东西，一看代码不就会了？但其实自己翻看一个月前的代码没有功能注释往往不会清晰，好在自己喜欢长方法名，做到尽量见名知意，但业务非一两句话说的清楚的，能够接触并且处理到业务才算是对业务的熟悉，能够从容的修理线上数据的时候才算是真正的熟悉，那么技术经理离职的问题是什么？问题就是所有的业务对外对内都要我承担，锻炼业务熟悉程度是一方面，但也重任在肩，能够明白自己对业务是否真正的熟悉，当线上bug，测试问题，开发进度，外部会议，跨部门对接，其他部门测试，都找到你一个人的时候，需要自己调整状态，对事情优先级做一个排列，且内心做到波澜不惊，因为事情总会解决的，只是紧急程度问题，那么能够承担此重任也算是全方面的锻炼，往日只关注自己手里的问题，现在全方面的处理，那就坦然面对。而就在此时我写这篇文章的时候也仍然断断续续的在处理线上问题，仍然要不停的看着数据在刷入库。
线上数据库锁表?
死锁不可怕，谁锁谁尴尬，这个休闲的周末，昨晚数据同步看到凌晨1点，今早凌晨6点被电话叫起来看全国用户的报错，原因在高峰期多省用户同时操作时，未开启异步逻辑，当同步数据插入数据库操作时需记录日志便于数据回滚，但此表历史设计是有联合key作为唯一索引约束的，导致业务上需要先删除再插入，那么高峰时期，对千万级别的数据表频繁删除在插入，此时必然会导致死锁，持有锁的事务去删除还没有释放，那么业务上不能避免吗？此接口响应阈值已经涉及好多业务了，所以除了异步，应尝试下replace，但看下是否支持联合字段的唯一索引吧，最终将线上所有高峰业务变为异步，所有省份恢复正常，故障也就不再报了。查询问题时知道是锁表以及锁等待超时，顺便延长了所等待超时时间。
MySQL版本：Percona MySQL Server 5.7.19
隔离级别：可重复读（RR）
锁等待超时时间：加至3600
业务逻辑：并发下按某个索引字段先delete记录，再insert记录
定位问题：日志下大量输出某表插入等待超时
分析问题：
1.第一时间想到是否是业务没有生成唯一索引所需要的字段导致插入错误，分析日志后排除
2.是否锁等待超时
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
value = 10
3.是否死锁
show engine innodb status\G;
图片
4.查询正在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
5.给出解决方案
图片
公司规范如下
1.避免MyISAM，改用InnoDB。
2.创建合适的索引，尽量不要多个单列索引。
3.避免大事务，长事务。
4.在业务低峰期DDL。
5.执行DDL/备份前，先判断是否有长SQL，未提交事务，及其他的lock wait事件。
为了避免此类错误，可进行异步插入,异步时线程睡眠等操作，尝试使用replace into操作，但因为也同样存在死锁场景，暂时放弃。
MySQL锁定状态查看命令
链接：https://blog.csdn.net/dc_726/article/details/8576151
分布式事务刻不容缓
图片
当流程类接口产生其他服务调用时，甚至1-3个外部服务调用，此时当本服务发生异常回滚时，第三方服务已经产生操作，无法进行回滚，在不影响业务的前提下，需要等待本地所有逻辑正常结束后才能调取第三方服务，当然我指的不是非本系统，而是非本服务之外的，可能是上游也可能是下游，而分布式事务刻不容缓，而Seata无论是接入还是业务侵入成本都是最小的，最大限度的降低了改造成本，当然我是不能决定随意用新组件的，目前还需要技术组评估。
明天就要上线?
昨晚开始思考切换区域后的数据修复问题，简单理了思路，到凌晨1点开始睡觉，21号早上6点30分被叫醒，中午抽时间去了下医院，然后一直忙到晚上1点，在历史逻辑上进行修改的业务，无论是何导致都没有考虑完全，但不是我不想考虑，而是没有人告知我历史业务，我就按着当时的需求来改，当然产生了许多未知问题，但其实改起来很简单，那么这种如何避免？凌晨的我，简直陷入自我怀疑，究竟这种问题能不能避免，避免在深夜再被这种问题所缠身？答案肯定是能的，只要严谨的业务逻辑，严谨的测试，重复的场景测试这种问题是完全可以避免的。而明天要上线的话，那就可以了。
而当我安静的躺在舒服的床上时，脑子里想的不是其他的，而是今晚能不能睡一个安稳的觉。
