一次CMS问题排除
定位问题最近在做扩容演练，注意到一个问题，每次docker启动都会触发一次CMS GC，刚开始以为是docker性能不好，后来看了下线上物理机分配给每个应用的内存也比较小（4G），所以感觉不是这个问题，就认真看了一下。
接着查看了下其他的docker机器发现也有CMS GC，于是对比了docker机器和物理机的CMS GC次数，发现都是每个3天左右触发一次，...
架构演化的思路
最近我们在讨论B端和C端的整体架构，收获不少，本文就共性的东西总结一下，指导后面其他架构的演化。
任何脱离业务的架构都是耍流氓相信我们都听过这句话，评价一个架构的好坏，一定要讨论背后所支撑的业务；而业务并不是一开始就是这个样子，业务是一天天累积扩大的，那么架构也应该是逐渐演化的。那如何让架构进行演化呢？
经过我们几轮的讨论，我觉得可以抽取的一个模式如下图：
...
核心链路的稳定性
最近在推荐我们业务线的核心链路稳定性，将中间所做的工作的总结梳理一下。
核心链路梳理第一步要做的，就是要理清楚自己业务的核心链路包括哪些，作为一个后端开发人员，总会自己感觉这一块比较简单很容易说出口，但是，有两点需要注意的：
核心链路要全盘梳理，不要只关注自己的模块。比如，在A模块的核心链路里面依赖了B的一个功能，而B模块在梳理的时候觉得这个功能不是核心的...
内网HTTP请求触发限流的排查
最近在做全链路的压测，当前晚上压测的时候，总是触发第三方业务的限流机制，虽然我们确实压的流量比较大，可以跟第三方简单沟通后，没有找到一个确切的原因；后面经过排查理了一个大概的思路，下面就讲一下具体的问题。
先看一下我们的整个流程（简化版的），如图：
我们的业务通过HTTP访问接入层，接入层部署了10台nginx集群，经过nginx的负载均衡后再请求第三方业...
全链路压测的大概思路
参与了我们业务的全链路压测，虽然过程磕磕绊绊，压测的当天晚上还在写压测脚本，但是核心链路的压测还是做了起来，效果也不错，当前晚上就爆出了一个P1级的bug。这篇文章就总结下如何做核心链路的全链路压测。
时机首先要清楚的一点就是，什么时候开始做全链路压测？我们有另外一个业务线，现在就没有打算做，那个业务线的日均单不到十万，而要压测的业务线的日均单到了200万，...
一个加锁粒度引起的问题
记录一个因为锁粒度不当导致的问题。
场景是这样的：
线上每天会在凌晨3点定时清理数据，但是，由于没有加limit, 导致每次清理DB的IO压力就特别大，于是开发简单的改了一版：清理数据的时候加limit限制，然后循环清理。
因为时间比较紧（当前晚上就要起作用），所以没有交给测试，另外，也考虑到修改的逻辑很简单，应该不会出问题，开发就发布上线了。
结果，早上收...
关于Netty的OutOfDirectMemoryError
最近帮一个业务排查问题，发现业务日志里面好多下面的错误：
1io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 520093983, max: 536870912)
看日志就知道是Direct B...
两阶段加锁
在分布式领域，熟悉一些基本的概念，比如，2PC，3PC，最近在优化一个项目的数据访问，接触到一个概念：2PL，两阶段锁, innodb引擎里面的加锁协议，保证单机事务的隔离和一致性。
例子先看下面两个方案：
方案一:
12345678begin; //1. 扣减库存update item_stock set count=count-1 where ...
MappedByteBuffer的一点优化
最近在参考阿里的rocketMQ来优化我们自己的mq，发现一段有意思的代码:
1234567891011121314MappedFile.javapublic AppendMessageResult appendMessage(final MessageExtBrokerInner msg, final AppendMessageCallback cb) &...
