一次Golang程序内存泄漏分析之旅

最近在开发升级PubSub系统,目标是支持更新版本的kafka(从原来的支持kafka 0.8.2.2升级到支持较新版本的kafka 0.10.1.1)。由于kafka在0.9版本上对consumer group相关的结构进行了重构,原来使用的基于zk进行rebalance的consumer group client:wvanbergen/kafka已经不再适用。为此,我们调研并最终选用了支持新版kafka consumer rebalance的consumer group client:sarama-cluster。功能开发已基本结束,目前已进入系统压力测试阶段。

Kafka Consumer Rebalance的演进

Kafka引入了Consumer Group的概念。在一个Consumer Group中的若干Consumer,会按照一定规则(均匀)分配同一topic下的所有partition,各自在相应partition上执行sub工作。当一个Group中有Consumer退出时,Group中的其他Consumer会对topic下的partition进行重新分配,并基于重新分配的结果继续执行sub工作。这个重新分配的过程被称为Rebalance。

对于Sub方的应用而言,Rebalance过程是透明的,Consumer Group Rebalance实现也经历了几个版本的演进,本文对Rebalance的实现方案进行大致的梳理和总结

为什么没有收到预期的413状态码

HTTP状态码413的含义是请求实体过长,RFC7231对413状态码的定义如下:

6.5.11. 413 Payload Too Large
The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

Kafka与传统消息中间件的差异

因工作关系,之前稍微接触、了解过一些传统的消息中间件(RabbitMQ, ActiveMQ, ZeroMQ, Tibco EMS/FTL, IBM MQ/LLM以及我们自研的消息中间件)。最近的工作则一直是基于Kafka展开的。Kafka的很多设计和理念和传统的消息中间件不太一样,谈谈自己的浅薄认识。

ElasticSearch总结

前段时间对分布式追踪相关的实现方案进行了一些调研,了解到近期对于大数据的日志检索、分析从原来基于hadoop的实现逐渐过渡到基于es的方案上来。近期在消息审计追踪相关的项目上也尝试的使用了类似的方案。这里对es的一些了解以及常用的一些使用整理于此。

多维索引容器(multi_index_container)的使用

C++ STL库为我们提供了vector/list/queue/(unordered)set/(unordered)map等各类容器,这些容器各自有各自的特点。有的提供链表类型的连续访问(vector/list/queue),有的提供平衡二叉树的数据组织结构(set/map),有的提供基于Hash的随即定位访问(unordered_set/unordered_map)。但有些时候,单一类型的访问并无法满足我们的需求,例如,有这样一个需求,需要我们实现一个LRU Cache。LRU的意思是:Least Recently Used,即最近最久未被使用的意思。LRU Cache的意思是:如果一个数据在最近一段时间没有被访问到,那么在将来它被访问的可能性也很小,基于这个原则,我们希望该类Cache的空间已经存满数据时,应当把最久没有被访问到的数据淘汰。

Golang程序调试工具介绍(gdb vs dlv)

通过log库输出日志,我们可以对程序进行异常分析和问题追踪。但有时候,我也希望能有更直接的程序跟踪及定位工具能够帮助我们更方便快捷的追踪、定位问题,最直观的感觉还是使用调试器。Linux平台下,原生的C/C++程序,我们往往使用gdb进行程序调试,切换到Golang,我们同样还是可以使用gdb进行调试。同时我们还可以使用golang实现的调试器dlv进行调试。以下内容是我对gdb以及dlv使用及对比总结

|