王廷云的博客

DevOps（和Operations的组合词），翻译过来就是开发运维一体化，是一种重视软件开发人员Dev）和IT运维技术人员Ops） 之间沟通合作的文化、运动或惯例。透过自动化软件交付和架构变更的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

这个时候就会发生一连串的连锁反应：一开始获得锁的线程还没有执行完毕，锁就被另一个线程获取了，而第一个线程执行业务逻辑完毕后执行释放锁的操作时就会把第二个线程的锁给释放了，然后第三个线程再次获取锁，就这样陷入了恶性循环。当然，虽然锁失去了作用，但还有个库存校验逻辑，但是偏偏库存校验逻辑不是非原子性的，代码中库存校验方式是先从 Redis 中 get 出库存数量，然后判断库存是否还有，最后再进行库存的扣减。在性能要求极高的场景下，一般数据以缓存为准，支付交易等也是如此，分布式场景下，大多数场景都是最终一致性。

而更新库存数据就是 udate 操作，命中索引时也是行级锁，但是这是个独占锁，所有的操作都要等待前一个释放锁后才能继续 update。在商品促销的时候（比如促销），因为一部分人下了单但没有付款完成订单流程，导致其他用户看到已售罄（实际意义上是有库存的），这样就会在某个时间点阻止其他用户购买。比如，库存只有100件，但有1000个用户成功下单，最后会有900个用户付款失败的，这种体验是很糟糕的，100件商品却超卖出900件。这种方案可以避免掉下单减库存的所有问题，但会产生新的问题，即“

事故场景：因为要在服务器上安装一个服务软件，习惯性地使用了 yum update -y 命令，结果更新完毕后，Docker 上运行的所有服务都挂了，导致后台服务程序全部运行异常，最后检测才发现是 Docker 重启了，但服务没有启动成功。事故原因：这次事故的主要原因是 yum update -y 这个命令，查看 yum 命令的帮助手册可以发现如下解释：update If run without any packages, update will update every currently

一、事故场景线上服务程序突然出现了 OOM（OutOfMemorty），查看日志可以发现以下提示：Exception in thread "http-nio-8080-exec-1012" java.lang.OutOfMemoryError: Java heap space从名称可以看出是 Tomcat 的 NIO 工作线程在处理程序的时候因为无法再堆中分配更多内存而出现了 OOM，还好在 JVM 启动参数中配置了 XX:+HeapDumpOnOutOfMemoryError，该配置参数会在 O

一、事故场景线上用户突然反馈说商品修改了名称之后无法搜索出来。项目为电商项目，商家端在编辑了商品名称之后，C端用户无法在商品搜索栏中使用修改之后的名称搜索该商品，说白了就是修改并没有生效。二、原因排查商品搜索使用的是 ES 搜索引擎，想要搜索商品的话需要生成该商品索引，而生成商品索引的逻辑是，商品添加或编辑之后会触发并发送 MQ 消息到 ES 搜索微服务中，搜索微服务收到消息后根据提供的商品ID到商品表中获取商品信息并生成商品索引数据。根据用户提供的商品ID和大概修改时间，从商品索引生成日志中找到