绍兴网站建设优化保定网站推广哪家好

绍兴网站建设优化,保定网站推广哪家好,企业全网推广,创建公司网站内容总结0x01 事故背景2025年7月9日17时有余#xff0c;笔者正准备结束疲惫的一天#xff0c;关机走人之时#xff0c;桌面右下角安静了一天的内部通讯软件图标突然亮起#xff0c;内心顿感不妙……打开一看#xff0c;原来是运维小哥找过来了#xff0c;说是某接口服务连续多次调…0x01 事故背景2025年7月9日17时有余笔者正准备结束疲惫的一天关机走人之时桌面右下角安静了一天的内部通讯软件图标突然亮起内心顿感不妙……打开一看原来是运维小哥找过来了说是某接口服务连续多次调用超时或失败触发告警阈值具体原因不明请求支援。临下班出事似乎已成为一种规律0x02 事故分析该服务是一个基于 SpringBoot JDK 1.8 的 API 服务提供了几个信息查询接口没有复杂的业务逻辑也不涉及第三方接口调用仅依赖于数据库进行简单的 CURD 操作。第一时间让运维拷贝和固定了事故系统日志及生产版本应用包。发现该服务在一周前升级部署过不排除是版本升级引起的问题。于是先留一手招呼运维小哥做好随时进行版本回退的准备以免不能及时修复问题。运维小哥已经排除了是网络和线路的问题也尝试按照常见故障应对手册重启过应用服务短暂恢复正常但是随着请求压力上来以后又会频繁失败触发告警。为了避免事故进一步扩大运维小哥选择迅速摇人。秉着先易后难的顺序先快速扫描了一遍应用日志常规日志未见明显ERROR、WARN以及Exception等信息SQL日志未见慢查询和连接池异常。随后检查数据库压力发现数据库活跃连接数不高也未见死锁和异常会话。jps找到服务进程对应的PID使用top命令查看进程的资源占用情况发现服务的 CPU 和内存资源占用不高。ss -antp|grep :9999| wc -l查看对应端口的连接情况大约两百多个活跃连接属于正常范围内。磁盘监控未见明显压力看来基本可以确定是应用本身的问题。于是使用jstack -l保存了第一次线程快照然后让运维小哥重启接口服务果然如小哥所说接口调用短暂正常以后很快又出现异常。为了排除偶然因素干扰这时做了第二次线程快照用于对照分析同时使用jmap抓取了 dump 文件备用。完成以上步骤以后果断让运维小哥将服务回退到历史版本应急解决故障。仔细分析两次抓取的线程快照发现大量的线程处于BLOCKED状态且拥有高度相似的调用栈thread-3197 Id4959 BLOCKED on java.util.concurrent.ConcurrentHashMap$ReservationNode1b1f101f owned by TaskExecutor-827 Id936at java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1868)- blocked on java.util.concurrent.ConcurrentHashMap$ReservationNode1b1f101fat com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2404)at com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2387)at com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:108)at com.github.benmanes.caffeine.cache.LocalLoadingCache.get(LocalLoadingCache.java:56)(这里省略部分信息)看起来是高并发的时候 Caffeine 缓存的处理出现了竞态争抢问题初步定位需要进一步分析事故原因。0x03 事故原因简单 review 了一下变更的代码发现同事A为某个关键系统参数的查询添加了秒级的短时缓存减少高并发下的数据库查询调用并且使用有界的LoadingCache来加载和刷新相关数据关键的Bean定义如下BeanConditionalOnBean(ParameterRepository.class)public LoadingCacheString, ParameterEntity parameterCache(ParameterRepository parameterRepository,Executor refreshExecutor) {return Caffeine.newBuilder().maximumSize(256).refreshAfterWrite(Duration.ofSeconds(3)).expireAfterAccess(Duration.ofSeconds(7)).executor(refreshExecutor).build(bssSysparmRepository::getById);}乍看之下似乎很合理。但是为何会出问题呢在高并发场景下多个线程同时请求缓存中不存在的数据导致多个线程都需要去加载数据而LoadingCache的刷新策略是按需刷新即只有当缓存中的数据过期时才会触发刷新。如果多个线程同时触发刷新就会导致多个线程同时去加载数据并使用相同的Key值调用ConcurrentHashMap.compute方法加载和刷新数据从而导致竞态争抢。这种机理导致LoadingCache或者说ConcurrentHashMap在JDK1.8里面并不适合用在需要高并发频繁刷新的缓存场景。有意思的是这个锅其实跟JDK中ConcurrentHashMap的实现机制有关存在同样问题的还有computeIfPresent方法具体可见。解决的方法不难就是使用AsyncLoadingCache来代替LoadingCache异步加载数据避免竞态争抢。修改下代码BeanConditionalOnBean(ParameterRepository.class)public AsyncLoadingCacheString, ParameterEntity parameterCache(ParameterRepository parameterRepository,Executor refreshExecutor) {return Caffeine.newBuilder().maximumSize(256).refreshAfterWrite(Duration.ofSeconds(3)).expireAfterAccess(Duration.ofSeconds(7)).executor(refreshExecutor).buildAsync(parameterRepository::getById);}取用时从LoadingCache.get()方法改为AsyncLoadingCache.synchronous().get()方法即可。优化版本上线后各方人员情绪稳定。0x04 事故复盘比起追究责任更重要的是带给我们的启发没有基准的性能优化都是耍流氓上线前需要先进行性能回归确认优化后的性能是否符合预期。0x05 事故影响