关于 RocketMQ ClientID 相同引发的消息堆积的问题

首先,造成这个问题的 BUG RocketMQ 官方已经在 3月16号这个提交中修复了,这里只是探讨一下在修复之前造成问题的具体细节,更多的上下文可以参考我之前写的 《RocketMQ Consumer 启动时都干了些啥?》 ,这篇文章讲解了 RocketMQ 的 Consumer 启动之后都做了哪些操作,对理解本次要讲解的 BUG 有一定的帮助。

其中讲到了:

消息堆积

重复消费自不必说,你 ClientID 都相同了。本篇着重聊聊为什么会消息堆积

继续阅读关于 RocketMQ ClientID 相同引发的消息堆积的问题

ArrayList 从源码角度剖析底层原理

对于 ArrayList 来说,我们平常用的最多的方法应该就是 addremove 了,本文就主要通过这两个基础的方法入手,通过源码来看看 ArrayList 的底层原理。

add

默认添加元素

这个应该是平常用的最多的方法了,其用法如下。

接下来我们就来看看 add 方法的底层源码。

ensureCapacityInternal 作用为:保证在不停的往 ArrayList 插入数据时,数组不会越界,并且实现自动扩容。

继续阅读ArrayList 从源码角度剖析底层原理

RocketMQ基础概念剖析和源码解析

Topic

Topic是一类消息的集合,是一种逻辑上的分区。为什么说是逻辑分区呢?因为最终数据是存储到Broker上的,而且为了满足高可用,采用了分布式的存储。

这和Kafka中的实现如出一辙,Kafka的Topic也是一种逻辑概念,每个Topic的数据会分成很多份,然后存储在不同的Broker上,这个「份」叫Partition。而在RocketMQ中,Topic的数据也会分布式的存储,这个「份」叫MessageQueue

其分布可以用下图来表示。

这样一来,如果某个Broker所在的机器意外宕机,而且刚好MessageQueue中的数据还没有持久化到磁盘,那么该Topic下的这部分消息就会完全丢失。此时如果有备份的话,MQ就可以继续对外提供服务。

为什么还会出现没有持久化到磁盘的情况呢?现在的OS当中,程序写入数据到文件之后,并不会立马写入到磁盘,因为磁盘I/O是非常耗时的操作,在计算机来看是非常慢的一种操作。所以写入文件的数据会先写入到OS自己的缓存中去,然后择机异步的将Buffer中的数据刷入磁盘。

继续阅读RocketMQ基础概念剖析和源码解析

RocketMQ基础概念剖析,并分析一下Producer的底层源码

由于篇幅原因,本次的源码分析只限于Producer侧的发送消息的核心逻辑,我会通过流程图、代码注释、文字讲解的方式来对源码进行解释,后续应该会专门开几篇文章来做源码分析。

这篇博客聊聊关于RocketMQ相关的东西,主要聊的点有RocketMQ的功能使用、RocketMQ的底层运行原理和部分核心逻辑的源码分析。至于我们为什么要用MQ、使用MQ能够为我们带来哪些好处、MQ在社区有哪些实现、社区的各个MQ的优劣对比等等,我在之前的文章《消息队列杂谈》已经聊过了,如果需要了解的话可以回过头去看看。

基础概念

Broker

首先我们要知道,使用RocketMQ时我们经历了什么。那就是生产者发送一条消息给RocketMQ,RocketMQ拿到这条消息之后将其持久化存储起来,然后消费者去找MQ消费这条消息。

RocketMQ操作

上图中,RocketMQ被标识为了一个单点,但事实上肯定不是如此,对于可以随时横向扩展的服务来说,生产者向MQ生产消息的数量也会随之而变化,所以一个合格成熟的MQ必然是要能够处理这种情况的;而且MQ自身需要做到高可用,否则一旦这个单点宕机,那所有存储在MQ中的消息就全部丢失且无法找回了。

继续阅读RocketMQ基础概念剖析,并分析一下Producer的底层源码

Go源码解析-Println的故事


本文主要通过平常常用的go的一个函数,深入源码,了解其底层到底是如何实现的。

Println

Println函数接受参数a,其类型为…interface{}。用过Java的对这个应该比较熟悉,Java中也有…的用法。其作用是传入可变的参数,而interface{}类似于Java中的Object,代表任何类型。

所以,…interface{}转换成Java的概念,就是Object args ...

Println函数中没有什么实现,只是return了Fprintln函数。

继续阅读Go源码解析-Println的故事