我活在当下，我巨他妈勇敢。

举一个场景，蓝胖子之前在服务中做过邮寄服务，由于邮寄需要依靠第三方的接口，并且整个邮寄的逻辑比较复杂，会有许多邮寄过滤条件，并且后续的产品功能持续有对这部分过滤逻辑进行修改，如何在对第三方接口进行容错，如何后续的迭代过程中对 过滤代码进行容错，保证出错后能有办法恢复出错用户的邮寄就成了要思考的问题。，例如，要记录某个用户做了支付行为，你应该要记录用户的id，订单号，甚至可以更详细点，把订单的价格，购买的商品信息都记录下来，以便后续排查问题时能直接通过日志找到用户的支付记录。

大家好，我是蓝胖子，提到监控指标，不得不说prometheus，今天这篇文章我会对prometheus 的架构设计，promql表达式原理和监控图表的绘图原理进行详细的解释。来让大家对prometheus的理解更加深刻。

大家好，我是蓝胖子，说到golang的性能分析，不得不提的就是其自身拥有的pprof，它提供了从cpu，内存，阻塞情况，协程，线程，乃至程序运行轨迹trace的分析，可以说相当强大了。今天我将会用较长的篇幅阐述 应该如何使用pprof工具来 对cpu，内存，阻塞情况，协程，线程 这几个维度去进行分析。其实总结出来Golang pprof的使用方式，可以用下面的思维导图来表示，

大家好，我是蓝胖子,前段时间mysql经常碰到慢查询报警，我们线上的慢sql阈值是1s，出现报警的表数据有 7000多万，经常出现报警的是一个group by的count查询，于是便开始着手优化这块，遂有此篇，记录下自己优化过程中的心得。优化慢sql前，肯定是要懂sql的查询逻辑，所以我先介绍下group by 语句的执行逻辑。

网络问题往往是性能排查中最复杂的一个问题，因为网络问题往往涉及的链路比较长，排查起来不仅仅是看本地机器的指标就可以了。本文将展示一个比较系统的排查网络问题的思路。我们往往都是通过类似prometheus，grafana搭建的监控平台对机器的各项指标进行监控，其中就包括网络性能，当发现指标异常后，你就需要定位到具体的进程了，定位到进程还没完，你还需要定位到进程中是哪段代码引发的这个问题。整个过程你可以看到是一个大范围到小范围逐步定位的过程，大致分为3个步骤：1，系统层面发现问题2，定位到具体异常进程。

在提交表定义阶段，MDL读锁升级为MDL排他锁，以排除旧表定义并提交新表定义。一旦授予，独占MDL锁的持续时间就会很短。可以看到如果使用inplcae 算法，只有在任务提交阶段(时间很短)， ddl才会阻塞dml语句，因为任务提交阶段会持有MDL 排他锁，而DML 语句执行时需要获取MDL读锁，所以在此期间，DML语句会被阻塞。具体哪些ddl操作类型支持Inplace 算法，可以查看官方文档链接，比如下面的mysql5.7的文档。

大家好，我是蓝胖子，今天我们来分析下网络连接中经常出现的RST信号，连接中出现RST信号意味着这条链接将会断开，来看下什么时候会触发RST信号，这在分析连接断开的原因时十分有帮助。本文的讲解视频已经上传在开始分析触发RST的场景之前，我们先来准备下需要的客户端和服务端代码，以方便我们进行测试。服务端代码目前先是在8080端口监听，然后将接收到的消息打印出来。客户端代码，连接8080端口然后打印hello world现在，来让我们测试下触发RST的各种场景。

在之前一篇里，我将性能分析步骤分为3个步骤，这里我再将这3个步骤列举出来：1，系统层面发现问题2，定位到具体异常进程3，定位到进程中引发异常的代码段现在来看看如何在每个步骤里分析cpu的使用情况。你将会像侦探一样，一层层抽丝剥茧，排查过程十分有趣。之所以把cpu和内存放到一起来讲排查思路，是因为它们的排查思路基本一致。

🔥🔥性能优化，服务监控方面的知识往往涉及量广且比较零散，我会持续输出这方面的内容，将这部分知识整理成册，愿以后性能排查不再抓瞎。