有才而性缓，定属大才。有智而气和，斯为大智。

1、全局流水号串联业务链路2、关键处日志打印3、定位：网关，负载、转发网络，数据传输宽带，负载过高，Sql ，磁盘，调用其他服务，其他服务处理过长，中间件的问题，框架这个是，具体问题还是要结合具体情况分析............

链接：https://mp.weixin.qq.com/s/D1Q1C8cGGffPgOMf0TbhXQ假定你已经了解了运行时的数据区域和常用的垃圾回收算法，也了解了Hotspot支持的垃圾回收器场景一：CPU占用过高cpu占用过高要分情况讨论，是不是业务上在搞活动，突然有大批的流量进来，而且活动结束后cpu占用率就下降了，如果是这种情况其实可以不用太关心，因为请求越多，需要处理的线程数越多，这是正常的现象。话说回来，如果你的服务器配置本身就差，cpu也只有一个核心，这种情况，稍微多一点流.

链接:https://mp.weixin.qq.com/s/TnLl2OW9XJLSZihcpgP7VQ今天给大家分享一个这两天排查成功的案例，相信对大家会有些帮助。大多数人应该听过一道经典的面试题：请详细地说出从浏览器地址栏输入 url 到最终呈现出结果的过程，越详细越好，为什么面试官这么喜欢问这道题呢，因为这个题涉及的面非常广，知识点非常多，如果你能完全吃透，非常有助于排查一些疑难杂症，今天我要分享的这个 case 就是个典型，废话不多说，进入正题。问题描述前端同学发现新开发的项目接口.

前段时间我们新上了一个新的应用，因为流量一直不大，集群QPS大概只有5左右，写接口的rt在30ms左右。因为最近接入了新的业务，业务方给出的数据是日常QPS可以达到2000，大促峰值QPS可能会达到1万。所以，为了评估水位，我们进行了一次压测。压测过程中发现，当单机QPS达到200左右时，接口的rt没有明显变化，但是CPU利用率急剧升高，直到被打满。压测停止后，CPU利用率立刻降了下来。于是开始排查是什么导致了CPU的飙高。问题排查与解决在压测期间...

先说总结：读写分离，读有些特定场景要走主库(写库)1.场景：读从库中的数据(状态为10的数据)，加锁去处理业务， 等到业务处理完毕后，更新表字段状态(从10更新为40) 注意我们读写分离是基于主从同步为基础的，主库更新为40的时候，释放锁， 主库同步从库有延迟的话(当时延迟了5s左右)，从库还没来的及同步从库状态，查询出来的数据将会重复执行 所以：在这种场景下读操作要走主库...

线上问题双12之前压测的时候起了很小的量，直接触发了Full GC，吓尿了，因为马上双12大促预热就要开始了，这搞不好妥妥的3.25啦。安琪拉的博客喜欢蹲草的纯粹技术人,用心分享一些互联网的技术41篇原创内容公众号赶紧拉群，把相关同学拉在一起排查问题。第一时间查看GC日志：可以看到原因是超过了Metadata GC的阈值，触发了Full GC，Metaspace从243M 回收到231M，基本没怎么回收掉，所以稍微再来点量，很容易再次触发Metaspace 的

有哪些常见的线上故障？如何快速定位问题？本文详细总结工作中的经验，从服务器、Java应用、数据库、Redis、网络和业务六个层面分享线上故障排查的思路和技巧。较长，同学们可收藏后再看。前言线上定位问题时，主要靠监控和日志。一旦超出监控的范围，则排查思路很重要，按照流程化的思路来定位问题，能够让我们在定位问题时从容、淡定，快速的定位到线上的问题。线上问题定位思维导图一 服务器层面1.1 磁盘1.1.1 问题现象当磁盘容量不足...

线上服务的GC问题，是Java程序非常典型的一类问题，非常考验工程师排查问题的能力。同时，几乎是面试必考题，但是能真正答好此题的人并不多，要么原理没吃透，要么缺乏实战经验。过去半年时间里，我们的广告系统出现了多次和GC相关的线上问题，有Full GC过于频繁的，有Young GC耗时过长的，这些问题带来的影响是：GC过程中的程序卡顿，进一步导致服务超时从而影响到广告收入。这篇文章，我将以一个FGC频繁的线上案例作为引子，详细介绍下GC的排查过程，另外会结合GC的运行原理给出一份实践指南，希望对你有所

你应该从网上看过太多的文章说缓存穿透怎么解决？无非就是布隆过滤器，缓存空值什么的。但是，更深入的一个问题，缓存空值有没有问题？如果缓存的空值太多怎么办？如果用的redis，那么太多的空值会不会打爆你的redis？如果用的本地缓存，会不会打爆你的内存？继而引发的问题就是还是会打爆你的数据库。从线上问题说起前不久，我们线上环境压测，在QPS压倒2W之后RT达到了几十秒，排查后发现是redis的连接数不够导致大量的连接超时。经过考虑之后，我们最终决定弃用redis缓存的方案，改为本地缓存，因为

来自公众号：艾小仙之前负责的一个服务总是在高峰时刻和压测发生大量的redis连接超时的异常redis.clients.jedis.exceptions.JedisConnectionException，根据原有的业务规则，首先会从数据库查询，然后缓存到redis中，超时时间设置为3分钟。并且由于业务的特性，本身未做降级、限流等处理措施，而在巅峰的QPS基本上快达到20000的样子，虽然这个现象只是单纯的一个异常，并不会导致整个主链路的流程不可用，但是我们还是要找出问题的原因并且解决。首先我们.