什么是内存屏障(Memory Barriers)

内存屏障是一种底层原语,在不同计算机架构下有不同的实现细节。本文主要在x86_64处理器下,通过Linux及其内核代码来分析和使用内存屏障

对大多数应用层开发者来说,“内存屏障”(memory barrier)是一种陌生,甚至有些诡异的技术。实际上,他常被用在操作系统内核中,用于实现同步机制、驱动程序等。利用它,能实现高效的无锁数据结构,提高多线程程序的性能表现。本文首先探讨了内存屏障的必要性,之后介绍如何使用内存屏障实现一个无锁唤醒缓冲区(队列),用于在多个线程间进行高效的数据交换。

Kafka数据丢失及最新改进策略

上周在测试环境,无意间连续把两台kafka的磁盘打爆,导致broker相继挂掉。当我清理完磁盘,重启两台broker后,发现很有意思的现象:kafka数据丢失!从我们的处理日志上, 我们观察到有向一个topic的两个partition,分别写入了3条和7条,共计10条消息。但是,当我们恢复两台broker后,通过命令查看,发现这时该topic两个partition消息数量竟然都是0,而从zk上consumer group记录的信息来看,有cg的确已经消费过该topic的数据,且cg在对应partition上的offset分别为3,7。

一次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的一些了解以及常用的一些使用整理于此。

|