Lost

最近在折腾公司打点日志（trace跟踪日志，类似阿里的鹰眼）的实时分析，大概总结一下。

实时流处理的技术越来越成熟，相对于spark而言，flink的模型已经抽象的很好；幸好我是从beam开始切入了解流处理的，现在回头看一些spark以及spark stream，flink的概念就很好懂了。

最近在梳理公司的大数据处理的流程，运维HBase的同事反馈我们中间件的链路收集日志（类似阿里的鹰眼）给HBase造成的压力最大，问我能不能优化一下。在优化的过程中，梳理了整个链路的反压处理，意识到在流处理，甚至在普通的大流量处理里面，这是一个很重要的问题，结合自己在消息系统的经验，在这里总结一下。

公司某个业务总是发现机器CPU偏高，要求运维扩容，结果扩容后，过了一段时间CPU还是涨了上来，又要求扩容。运维觉得老是这么扩容不是办法，就拉我一起看看问题出在哪儿。

问题定位

在另外一篇文章里，介绍了如何使用perf排查cpu偏高的问题,接到问题后，马上使用perf map agent看了看，很明显就找出来耗CPU的地方：

升级了公司的Dubbo到3.0.0版本，然后推动业务升级，结果，业务反馈升级后，rt拉高了2～3ms，由于业务的整体rt才在7ms左右，所以，这次升级对业务的影响还是很大的，业务决定回滚，而我这边就开始了问题的排查

现象

根据我们的监控，可以很明显看到升级新的dubbo后的rt变化:

看了两篇文章：1,2,主题是“基于Redis的分布式锁到底安全吗？”，作者翻译了分布式大神Martin Kleppmann和Redis的作者antirez之间就发生过一场争论，等有时间我也去看看原文，这里先总结一下文章里面的主要观点，以及关于分布式锁和fencing机制的几种实现。

最近在研究如何提升MQ的性能，了解到了JVM的停顿，一个一个来，先看看Java的偏向锁带来的性能损耗

Java的锁

Java在锁方面做了好多优化，具体的一些介绍,另外，网上也有很多文档，可以自己搜索看看。这里大概摘抄总结下:

奇妙的思维实验

很简单的一本书，里面讲了一些有意思的思维实验。我对其中一个印象很深，记录一下：

在写一个统计qps的组件，收获了不少，在上一篇里面有讲。写完之后想压测下看看，统计下每个方法的耗时。以前用过JProfile，但是，JProfle在linux部署比较麻烦，当然，更关键的是这个是收费的；找了半天，发现阿里出了一个TProfiler，看起来简单好用，还免费，试了试确实还不错。

最近在写一个dubbo组件，用来统计服务的qps等指标，考虑到高并发的场景，就去研究了下Netflix的RollingNumber，收获还不少（也有点杂）。

以色列：一个国家的诞生（知乎十一点半作品

有个项目发现mq消息堆积，上去看了下，发现日志中出现：

1

Caused by: java.lang.OutOfMemoryError: unable to create new native thread

负责公司的DUBBO，业务在压一个DUBBO服务的时候，发现RT逐渐拉长,从最开始的4ms，到后面的18ms，业务觉得比较诡异，怀疑是DUBBO的问题，于是就到了我这

现象

接到问题，马上到业务压测现场，看了下基本的数据：

前一篇写了下MQ HA方案的整体架构，下面介绍一下在实现过程面临的一些问题。

HA主从同步协议

MQ主从同步借助于Netty实现，主从之间的通信协议主要包括两部分：心跳和数据同步。

公司自研的MQ基本功能稳定后，开始提高可用性，首当其冲的就是要做主备。我们的MQ基本上还是借鉴了阿里的rocketMQ的方案，所以在HA这块也差不多。

主备同步方案

主备的数据同步主要由HAService负责：

最近阅读了一片文章：微信红包后台系统可用性设计实践, 主要讲了高可用的一些优化设计，以及如何平行扩所容，细节可以看看原文，我这里主要讲一些我的一些理解。