这又是一个线上大规模故障引发的案例，而且居然是罕见的“脑裂”故障，只能说这又是一次搞懂 Redis集群 原理的好机会！

前言 最近闲来没事，一直在掘金上摸鱼，看了不少高并发相关的文章，突然有感而发，想到了几年前做的一个项目，也多少和高并发有点关系。 这里我一边回忆落地细节一边和大家分享下，兴许能给大家带来点灵感。 正文

本文通过一封618前的R2M(公司内部缓存组件，可以认为等同于Redis)告警，由浅入深的分析了该告警的直接原因与根本原因，并根据原因提出相应的解决方法，希望能够给大家在排查类似问题时提供相应的思路。

双 11、618 期间，系统要尽可能多地卖出商品，尽可能多地收订单，又不能超过库存。在这种高并发、大流量场景下，整个系统的瓶颈点出现在数据库上，本篇文章就库存更新这一场景下讨论如何优化事务 SQL。

本次文章完全使用mysql自带的show命令实现获取，从connects、buffercache、lock、SQL、statement、Database throughputs、serverconfi

前言 最近公司某项目上反馈mysql主从复制失败，被运维部门记了一次大过，影响到了项目的验收推进，那么究竟是什么原因导致的呢？而主从复制的原理又是什么呢？本文就对排查分析的过程做一个记录。 主从复制原

网上博客常说，kafka的topic数量过多会影响kafka，而RocketMQ不会受到topic数量影响。 但是，果真如此吗？ 最近排查一个问题，发现RocketMQ稳定性同样受到topic数量影响

对公司的 ELK 日志系统做过性能优化，也对 SkyWalking 使用的 ES 存储进行过性能优化，在此做一些总结。本篇主要是讲 ES 在 ELK 架构中作为日志存储时的性能优化方案。

研发人员在项目开发中不可避免地要使用日志，通过它来记录信息和排查问题。Apache Log4j2提供了灵活且强大的日志框架，虽然上手比较快，但稍有不慎也非常容易踩“坑”。