qsmiley10的博客

还是上文提到的核心应用，为了提升系统查询性能，我们在观察缓存命中率时，发现整体命中率都比较高，但是其中04集群的某个节点（99:36382）命中率一直比其他节点的命中率低。缓存命中率是我们非常关注的一个点，因为每一次未命中的请求都意味着对数据库的一次压力。

还是上文提到的核心应用，为了保障活动流量，我们对该客户系统进行扩容，应用节点由100扩容到300，过一段时间后，发现Redis监控数据CPU使用率存在热点异常。图中100:36408节点的CPU使用率7.32%，其他只有0.8%，差了近10倍。拉到模拟生产压测时的数据，发现该节点比其他节点稍高一些，但是并没有特别大差距。但是到了活动当天，100:36408节点的CPU使用率达到了20%，相比于其他节点平均值都在2%-3%，还是差了将近10倍。如果任由问题持续，整个缓存将因为热点问题导致部分节点不可用。

公司生产上核心客户系统涉及整个用户信息的管理和维护，QPS在万级别，是非常典型的读多写少的场景。这个系统一直有一个遗留问题：间断性出现某个节点Dubbo线程池满，过一段时间后又自动恢复。

开放平台2.0 GC（ParNew+CMS）会出现频率飙升怀疑接口请求量增加，导致内存占用比较多，造成年轻代频繁进行young gc，但是查看开放平台的请求并没有发现流量的突增。所以并没有什么有效的结论。尝试替换成G1垃圾收集器替换掉（ParNew+CMS），对应gc的参数如下：-Xms4g-Xmx4g-Xss512k-XX:MetaspaceSize=256m-XX:MaxMetaspaceSize=512m-XX:MaxDirectMemorySize=1536m-XX:NativeMe

1、问题  由于公司业务和技术性需求，新上线一个独立支付系统，其中部分退款功能在进行并发测试时出现偶发性mysql死锁：[2021-09-22 15:46:18,760][c.b.a.s.i.ReverseServiceImpl][thread0][ERROR][816fbe90-a4fa-4dea-b52c-719f1f2a8c37][]call [ReverseServiceImpl][refund] EXCEPTION:Cause[org.springframework.dao.DeadlockL

  某应用线上运行较长时间后出现Full GC告警，重启后恢复正常。  由于之前基本上半个月就会发一次版，导致问题一直没有暴露出来，这次较长时间没有对应用进行发版（或重启）。根据现象初步怀疑是由内存泄漏引起。  拉取dump文件分析。发现线程池ConsumerQueryExecuteImpl和NoAccQb2cQueryExecuteImpl引用了大对象，引用的队列LinkedBlockingQueue和FutureTask都存在数量极大的Object，基本证实是由内存泄漏引起。  分析代码，发现Co

1、问题发现  近期，生产上订单系统出现了一笔问题交易：一笔订单调用支付系统进行支付，支付系统返回处理中订单系统异步查询支付结果，被告知订单不存在导致订单失败。最终支付系统支付成功，订单系统启动异常处理机制撤销该支付。2、背景描述  调用链为业务系统->订单系统下单->支付系统支付。  订单系统和支付系统都有幂等的要求，且幂等主键为上游请求系统、请求流水号、请求日期（截取自请求时间）。当查询时传入的请求三要素与下单/支付传入的请求三要素不同时则无法查询到订单。3、问题追踪