摘要
Kafka作为一个消息中间件系统,面临的首要问题就是消息如何持久化,如何方便地进行读写和解析。本文将就Kafka的消息存储问题开一个头,后续将会对重要的代码部分一一讲解。Kafka的消息概念,首先我们在此谈论的不是网络传递中的消息,而更多偏向于记录的意思,也就是消费者和生产者所在意的实际对象。消息是Kafka造作的最小单元,并不允许更改消息的实际内容,一条消息本质上是一个键值可缺省的键值对。
消息格式
下面首先以Kafka 0.10.0版本为例来解释一下其消息格式:
CRC+magic+attributes+wrapperTimestamp(optional)+key(长度+内容)+payload(长度+内容)
下面依次列出每一部分
* 1. 4 byte CRC32 校检值
* 2. 1 byte "magic" 标识符来显示消息格式是否发生了改动,值为0/1(也可以看作是版本号)
* 3. 1 byte "attributes" 标识符,包含以下内容:
* bit 0 ~ 2 : 压缩编码方式
* 0 : no compression
* 1 : gzip
* 2 : snappy
* 3 : lz4
* bit 3 : 时间戳类型
* 0 : create time
* 1 : log append time
* bit 4 ~ 7 : 保留部分
* 4. (可选) 8 byte 时间戳,只有magic为1时才携带该部分
* 5. 4 byte key length, 指定Key部分的长度
* 6. K byte key
* 7. 4 byte payload length, 指定值的长度
* 8. V byte payload
Kafka的消息格式在设计上允许多重嵌套,这种嵌套是通过压缩实现的。试想一下,某个消息的key为空,然后它的value部分是一个压缩后的MessageSet,那么经过解压缩并读取后它就是一个键值对集合了,这有些类似于json了。但实际上Kafka的消息只允许二重嵌套,这并非由其消息格式的局限性决定,而是考虑到读取消息时解析的复杂度决定。嵌套消息使得Kafka传递复杂类型的对象成为可能,但是出于性能因素的考虑,对象序列化和过于复杂的数据格式并不适合消息系统这一业务,或者说kafka在性能方面和表达能力上做了一个漂亮的妥协。
同时,我们还要重点来谈一谈时间戳相关,时间戳有三种取值,分别是-1代表不带时间戳,0代表该消息创建的时间,1代表它持久化时间(也可以理解为入库被kafka处理的时间)。对于嵌套的消息来说,若我们选择时间戳类型为入库时间,则被压缩消息的时间戳和其外层消息一致;若我们选择时间戳类型为创建时间,则应该从字节码流中读取;若magic值为0.则不管如何,都应该认为时间戳为-1,时间戳类型为CREATE_TIME。
Message类的代码设计
虽然看起来消息格式好像比较简单,但实际上代码却相对有些复杂,最重要的问题是1、要兼容magic为0的情况,2、要能为后续的版本升级留出扩展。我们首先思考一下,Message类应该具有哪些功能呢大致分为下面几个部分:
预定义的变量
由于操作的是bytes,大量的取值需要位操作,所以我们应该预定义好一些位操作辅助变量和一些重要的偏移位置。这里面有几个比较重要的预定义变量需要着重强调一下:
key length byte的位置,因为它是头和体的分割点
从attributs byte读取时间戳类型和压缩编码方式的辅助变量
下面上代码
/**
* Specifies the mask for the compression code. 3 bits to hold the compression codec.
* 0 is reserved to indicate no compression
*/
val CompressionCodeMask: Int = 0x07
/**
* Specifies the mask for timestamp type. 1 bit at the 4th least significant bit.
* 0 for CreateTime, 1 for LogAppendTime
*/
val TimestampTypeMask: Byte = 0x08
val TimestampTypeAttributeBitOffset: Int = 3
public byte updateAttributes(byte attributes) {
return this == CREATE_TIME ?
(byte) (attributes & ~Record.TIMESTAMP_TYPE_MASK) : (byte) (attributes | Record.TIMESTAMP_TYPE_MASK);
}
public static TimestampType forAttributes(byte attributes) {
int timestampType = (attributes & Record.TIMESTAMP_TYPE_MASK) >> Record.TIMESTAMP_TYPE_ATTRIBUTE_OFFSET;
return timestampType == 0 ? CREATE_TIME : LOG_APPEND_TIME;
}
def compressionCodec: CompressionCodec =
CompressionCodec.getCompressionCodec(buffer.get(AttributesOffset) & CompressionCodeMask)
各个属性的get方法
这个不用多说,需要注意的就是magic的值不同,有些取值的偏移位置不一样,所以需要事先写好静态方法快捷获得不同magic下的位置偏移。
合法性检查
主要检查以下几个方面:
magic值和时间戳类型和时间戳值的组合是否一致
CRC 校检是否通过
不同magic值下的message相互转换
1. 计算新message需要的空间大小并分配
2. 写入新的magic值
3. 取原来的attribute并用设置的TimestampType更新它,然后写入attribute值
4. 若是0->1则写入时间戳
5.写入原来的消息体
6.计算新的CRC值并填充
一系列的构造方法
主要的构造途径有两条:
主要用于构造嵌套消息,直接传入buffer数据,可以设定时间戳和时间戳类型
主要用于构造原子消息,传入键值对数据,并设定主要参数(magic、压缩编码、时间戳类型、时间戳)
消息相关的主要类
下面就依次介绍每个类的作用
MessageAndOffset:在Message之外附加它处于set中的偏移
MessageAndMeta:主要功能是包装解码器将message解码为Key和Value对象
MessageSet:管理message集合,事先集合的顺序读和批量写,但个人认为其代码的重心在于如何解决消息嵌套的解析
ByteBufferMessageSet:用ByteBuffer来存储序列的Message,主要为了方便读Message的操作
ByteBufferBackedInputStream:将buffer的读写包装成流的模式
Kafka储存消息的文件被它叫做log,按照Kafka文档的说法是:
Each partition is an ordered, immutable sequence of messages that is continually appended to—a commit log
这反应出来的Kafka的行为是:消息被不断地append到文件末尾,而且消息是不可变的。
这种行为源于Kafka想要实现的功能:高吞吐量,多副本,消息持久化。这种简单的log形式的文件结构能够更好地实现这些功能,不过也会在其它方面有所欠缺,比如检索消息的能力。
而Kafka的行为也决定了它的消息格式。对于Kafka来说,消息的主体部分的格式在网络传输中和磁盘上是一致的,也就是说消息的主体部分可以直接从网络读取的字节buffer中写入到文件(部分情况下),也可以直接从文件中copy到网络,而不需要在程序中再加工,这有利于降低服务器端的开销,以及提高IO速度(比如使用zero-copy的传输)。
这也就决定了Kafka的消息格式必须是适于被直接append到文件中的。当然啥都可以append到文件后面,问题在于怎么从文件中拆分出来一条条记录。
记录的划分以及消息的格式
对于日志来说,一条记录以"\n"结尾,或者通过其它特定的分隔符分隔,这样就可以从文件中拆分出一条一条的记录,不过这种格式更适用于文本,对于Kafka来说,需要的是二进制的格式。所以,Kafka使用了另一种经典的格式:在消息前面固定长度的几个字节记录下这条消息的大小(以byte记),所以Kafka的记录格式变成了:
Offset MessageSize Message
消息被以这样格式append到文件里,在读的时候通过MessageSize可以确定一条消息的边界。
需要注意的是,在Kafka的文档以及源码中,消息(Message)并不包括它的offset。Kafka的log是由一条一条的记录构成的,Kafka并没有给这种记录起个专门的名字,但是需要记住的是这个“记录”并不等于"Message"。Offset MessageSize Message加在一起,构成一条记录。而在Kafka Protocol中,Message具体的格式为
Message => Crc MagicByte Attributes Key Value
Crc => int32
MagicByte => int8
Attributes => int8
Key => bytes
Value => bytes
各个部分的含义是
Field |
Description |
---|---|
Attributes | This byte holds metadata attributes about the message. The lowest 2 bits contain the compression codec used for the message. The other bits should be set to 0. |
Crc | The CRC is the CRC32 of the remainder of the message bytes. This is used to check the integrity of the message on the broker and consumer. |
Key | The key is an optional message key that was used for partition assignment. The key can be null. |
MagicByte | This is a version id used to allow backwards compatible evolution of the message binary format. The current value is 0. |
Offset | This is the offset used in kafka as the log sequence number. When the producer is sending messages it doesn't actually know the offset and can fill in any value here it likes. |
Value | The value is the actual message contents as an opaque byte array. Kafka supports recursive messages in which case this may itself contain a message set. The message can be null.
|
MessageSet
之所以要强调记录与Message的区别,是为了更好地理解MessageSet的概念。Kafka protocol里对于MessageSet的定义是这样的
MessageSet => [Offset MessageSize Message]
Offset => int64
MessageSize => int32
也就是说MessageSet是由多条记录组成的,而不是消息,这就决定了一个MessageSet实际上不需要借助其它信息就可以从它对应的字节流中切分出消息,而这决定了更重要的性质:Kafka的压缩是以MessageSet为单位的。而以MessageSet为单位压缩,决定了对于压缩后的MessageSet,不需要在它的外部记录这个MessageSet的结构,也就决定了Kafka的消息是可以递归包含的,也就是前边"value"字段的说明“Kafka supports recursive messages in which case this may itself contain a message set"。
具体地说,对于Kafka来说,可以对一个MessageSet做为整体压缩,把压缩后得到的字节数组作为一条Message的value。于是,Message既可以表示未压缩的单条消息,也可以表示压缩后的MessageSet。
压缩后的消息的读取
就看Message头部的Attributes里的压缩格式标识。说到这个,得说下递归包含的事情,理论上,一个压缩的的MessageSet里的一个Message可能会是另一个压缩后的MessageSet,或者包含更深层的MessageSet。但是实际上,Kafka中的一个Message最多只含有一个MessageSet。从Message中读取MessageSet的逻辑,可以在ByteBufferMessageSet的internalIterator方法中找到:
if(isShallow) { //是否要进行深层迭代 new MessageAndOffset(newMessage, offset) } else { //如果要深层迭代的话 newMessage.compressionCodec match { case NoCompressionCodec => innerIter = null new MessageAndOffset(newMessage, offset) //如果这个Message没有压缩,就直接把它作为一个Message返回 case _ => innerIter = ByteBufferMessageSet.deepIterator(newMessage) //如果这个Message采用了压缩,就对它进行深层迭代 if(!innerIter.hasNext) innerIter = null makeNext() } }
而ByteBufferMessageSet的deepIterator方法就是对这个Message的value进行解压,然后从中按照Offset MessageSize Message的格式读取一条条记录,对于这次读取的Message,就不再进行深层迭代了。下面是deepIterator的makeNext方法,它被不断调用以生成迭代器的元素
override def makeNext(): MessageAndOffset = { try { // read the offset val offset = compressed.readLong() // read record size val size = compressed.readInt() if (size < Message.MinHeaderSize) throw new InvalidMessageException("Message found with corrupt size (" + size + ") in deep iterator") // read the record into an intermediate record buffer // and hence has to do extra copy val bufferArray = new Array[Byte](size) compressed.readFully(bufferArray, 0, size) val buffer = ByteBuffer.wrap(bufferArray) val newMessage = new Message(buffer) // the decompressed message should not be a wrapper message since we do not allow nested compression new MessageAndOffset(newMessage, offset) } catch { case eofe: EOFException => compressed.close() allDone() case ioe: IOException => throw new KafkaException(ioe) } }
KAFKA-1718
至于一个MessageSet中不能包含多个压缩后的Message(压缩后的Message也就是以压缩后的MessageSet作为value的Message),Kafka Protocol中是这么说的
The outer MessageSet should contain only one compressed "Message" (see KAFKA-1718 for details).
KAFKA-1718就是在Protocol里添加这么一个特殊说明的原因。事情是这样的:
报各这个问题的人是Go语言client的作者,他发现自己发的Message明显没有过大,但是发生了MessageSizeTooLargeException。后来跟其它人讨论,发现是因为broker端在调用Log.append时,会把传送给这个方法的MessageSet解压开,然后再组合成一个压缩后的MessageSet(ByteBufferMessageSet)。而Go语言的客户端发送的MessageSet中包含了多个压缩后的Message,这样即使发送时的Message不会超过message.max.bytes的限制,但是broker端再次生成的Message就超过了这个限制。所以,Kafka Protocol对这种情况做了特殊说明:The outer MessageSet should contain only one compressed "Message"。
Compressed Message的offset
即然可以把压缩后的MessageSet作为Message的value,那么这个Message的offset该如何设置呢?
这个offset的值只有两种可能:1, 被压缩的MessageSet里Message的最大offset; 2, 被压缩的MessageSet里Message的最小offset.
这两种取值没有功能的不同,只有效率的不同。
由于FetchRequest协议中的offset是要求broker提供大于等于这个offset的消息,因此broker会检查log,找到符合条件的,然后传输出去。那么由于FetchRequest中的offset位置的消息可位于一个compressed message中,所以broker需要确定一个compressed Message是否需要被包含在respone中。
- 如果compressed Message的offset是它包含的MessageSet的最小offset。那么,我们对于这个Message是否应包含在response中,无法给出"是”或"否“的回答。比如FetchRequest中指明的开始读取的offset是14,而一个compressed Message的offset是13,那么这个Message中可能包含offset为14的消息,也可能不包含。
- 如果compressed Message的offset是它包含的MessageSet的最大offset,那么,可以根据这个offset确定这个Message“不应该”包含在response中。比如FetchRequest中指明的开始读取的offset是14,那么如果一个compressed Message的offset是13,那它就不该被包含在response中。而当我们顺序排除这种不符合条件的Message,就可以找到第一个应该被包含在response中的Message(压缩或者未压缩), 从它开始读取。
在第一种情况下(最小offset),我们尽管可以通过连续的两个Message确定第一个Message的offset范围,但是这样在读取时需要在读取第二个Message的offset之后跳回到第一个Message, 这通常会使得最近一次读(也就读第二个offset)的文件系统的缓存失效。而且逻辑比第二种情况更复杂。在第二种情况下,broker只需要找到第一个其offset大于或等于目标offset的Message,从它可以读取即可,而且也通常能利用到文件系统缓存,因为offset和消息内容有可能在同一个缓存块中。
在处理FetchRequest时,broker的逻辑也正是如此。对FetchRequest的处理会调用到Log#read(startOffset: Long, maxLength: Int, maxOffset: Option[Long] = None)方法,然后调用到LogSegment的read方法,它的之后的调用有很多,所有不贴代码了,它的注释说明了读取的逻辑
* Read a message set from this segment beginning with the first offset >= startOffset. The message set will include
* no more than maxSize bytes and will end before maxOffset if a maxOffset is specified
即,返回的MessageSet的第一条Message的offset >= startOffset。
而在broker给compressed Message赋予offset时,其逻辑也是赋予其包含的messages中的最大offset。这段逻辑在ByteBufferMessageSet的create方法中:
messageWriter.write(codec = compressionCodec) { outputStream => val output = new DataOutputStream(CompressionFactory(compressionCodec, outputStream)) //创建压缩流 try { for (message <- messages) { offset = offsetCounter.getAndIncrement //offsetCounter是一个AtomicLong,使用它的当前值作为这条Message的offset,然后+1作为下一条消息的offset output.writeLong(offset)//写入这条日志记录的offset output.writeInt(message.size)//写入这条日志记录的大小 output.write(message.buffer.array, message.buffer.arrayOffset, message.buffer.limit) //写入这条记录的Message } } finally { output.close() } } val buffer = ByteBuffer.allocate(messageWriter.size + MessageSet.LogOverhead) writeMessage(buffer, messageWriter, offset)//以最后一个Message的offset作为这个compressed Message的offset
Validate Message
什么需要验证?
先看一下消息的哪些特征需要被验证。
首先,网络传输过程中,数据可能会产生错误,即使是写在磁盘上的消息,也可能会由于磁盘的问题产生错误。因此,broker对接收到的消息需要验证其完整性。这里的消息就是前边协议里定义的Message。对于消息完整性的检测,是使用CRC32校验,但是并不是对消息的所有部分计算CRC,而是对Message的Crc部分以后的部分,不包括记录的offset和MessageSize部分。把offset和MessageSize加到CRC计算中,可以对完整性有更强的估证,但是坏处在于这两个部分在消息由producer到达broker以后,会被broker重写,因此如果把它们计算在crc里边,就需要在broker端重新计算crc32,这样会带来额外的开销。
CRC32没有检测出错误的概率在0.0047%以下,加上TCP本身也有校验机制,不能检测出错误的概率就很小了(这个还需要再仔细算一下)。
除了消息的完整性,还需要对消息的合规性进行检验,主要是检验offset是否是单调增长的,以及MessageSize是超过了最大值。
这里检验时使用的MessageSize就不是Message本身的大小了,而是一个记录的大小,包括offset和MessageSize,这个也挺奇怪的,有必要非拉上这俩吗?
而且在broker端检验producer发来的MessageSet时,也没必要检验它的offset是否是单调增长的呀,毕竟leader还要对Message的offset重新赋值。而follower是从leader处拉取的,如果网络或者磁盘出错,通过对offset的单调性检查也可能会漏掉出错了的记录,对于consumer来说也是同理。所以这里有点奇怪。
何时需要验证?
在broker把收到的producer request里的MessageSet append到Log之前,以及consumer和follower获取消息之后,都需要进行校验。
这种情况分成两种:
1. broker和consumer把收到的消息append到log之前
2. consumser收到消息后
第一种情况都是在调用Log#append时进行检验的。
如何验证?
先看下Log#append的方法声明
def append(messages: ByteBufferMessageSet, assignOffsets: Boolean = true): LogAppendInfo
在replica的fetcher线程调用append方法时,会把assignOffsets设成false,而leader处理produce request时,会把assignOffsets设成true。
下面append方法的一部分代码
val appendInfo = analyzeAndValidateMessageSet(messages) //验证消息 // if we have any valid messages, append them to the log if(appendInfo.shallowCount == 0) return appendInfo // trim any invalid bytes or partial messages before appending it to the on-disk log var validMessages = trimInvalidBytes(messages, appendInfo)//trim掉不可用的部分或者残缺的消息 try { // they are valid, insert them in the log lock synchronized { appendInfo.firstOffset = nextOffsetMetadata.messageOffset if(assignOffsets) { //如果需要重新赋予offset // assign offsets to the message set val offset = new AtomicLong(nextOffsetMetadata.messageOffset) try { validMessages = validMessages.validateMessagesAndAssignOffsets(offset, appendInfo.sourceCodec, appendInfo.targetCodec, config.compact) //验证消息并且赋予offset } catch { case e: IOException => throw new KafkaException("Error in validating messages while appending to log '%s'".format(name), e) } appendInfo.lastOffset = offset.get - 1 } else { // we are taking the offsets we are given if(!appendInfo.offsetsMonotonic || appendInfo.firstOffset < nextOffsetMetadata.messageOffset) throw new IllegalArgumentException("Out of order offsets found in " + messages) } // re-validate message sizes since after re-compression some may exceed the limit 对压缩后消息重新验证MessageSize是否超过了允许的最大值 for(messageAndOffset <- validMessages.shallowIterator) { if(MessageSet.entrySize(messageAndOffset.message) > config.maxMessageSize) { // we record the original message set size instead of trimmed size // to be consistent with pre-compression bytesRejectedRate recording BrokerTopicStats.getBrokerTopicStats(topicAndPartition.topic).bytesRejectedRate.mark(messages.sizeInBytes) BrokerTopicStats.getBrokerAllTopicsStats.bytesRejectedRate.mark(messages.sizeInBytes) throw new MessageSizeTooLargeException("Message size is %d bytes which exceeds the maximum configured message size of %d." .format(MessageSet.entrySize(messageAndOffset.message), config.maxMessageSize)) } }
注意到对MessageSize验证了两次,第二次是对重新压缩后的消息。KAFKA-1718里提到MessageSizeToLargeException,就是在这时候检测出来的。
初步检验:analyzeAndValidateMessageSet
具体的检验消息完整性和offset单调增长的逻辑在analyzeAndValidateMessageSet方法里。这个方法的实现里,需要注意几点:
- 它是使用ByteBufferMessageSize的shallowIterator来对这个MessageSet的消息进行迭代,这也意味着并不会对compressed message里边的MessageSet解压后再进行检验,而是把comprssed message作为单个Message进行检验。
- 它计算checksum时,是计算的MagicByte及其以后的内容。
def computeChecksum(): Long = CoreUtils.crc32(buffer.array, buffer.arrayOffset + MagicOffset, buffer.limit - MagicOffset)
- 它比较的是entrySize与MaxMessageSize的大小,来确定这个消息是否太大
def entrySize(message: Message): Int = LogOverhead + message.size --------------------------------- val MessageSizeLength = 4 val OffsetLength = 8 val LogOverhead = MessageSizeLength + OffsetLength
- 它返回的LogAppendInfo中会包括一个targetCodec,指明这个MessageSet将要使用的压缩方式。leader处理produce request时,将使用这个压缩方式重新压缩整个MessageSet。
val targetCodec = BrokerCompressionCodec.getTargetCompressionCodec(config.compressionType, sourceCodec)
config.compressionType就是broker配置里的compression.type的值,如果它是“producer", 就会使用producer request使用压缩方式,否则就使用config.compressionType指明的压缩方式。注意如果一个MessageSet里的Message采用了不同的压缩方式,最后被当成sourceCodec的是最后一个压缩了的消息的压缩方式。
再次检验并且赋予offset :validateMessagesAndAssignOffsets
只有leader处理produce request时,会调用ByteBufferMessageSet的这个方法。 它不会检测analyzeAndValidateMessageSet已经检测的内容,但是会把这个MessageSet进行深度遍历(即如果它里边的消息是压缩后,就把这个消息解压开再遍历),这样它就能做analyzeAndValidateMessageSet不能进行的检测:对于compacted topic检测其key是否为空,如果为空就抛出InvalidMessageException。
另外,它会把深度遍历后获得的Message放在一起重新压缩。
如果MessageSet的尾部不是完整的Message呢?
这是在获取ByteBufferMessageSet的iternalIterator时候处理的。
def makeNextOuter: MessageAndOffset = { // if there isn't at least an offset and size, we are done if (topIter.remaining < 12) return allDone() val offset = topIter.getLong() val size = topIter.getInt() if(size < Message.MinHeaderSize) throw new InvalidMessageException("Message found with corrupt size (" + size + ") in shallow iterator") // we have an incomplete message if(topIter.remaining < size) return allDone() . ... }
注意返回allDone()和抛出InvalidMessageException的时机。
- 如果这个MessageSet剩下部分不到12bytes,那剩下的部分就是下一个MessageSet头部的一部分,是没法处理的,也是没办法检验的,因此就返回allDone。
- 如果够12bytes,就可以读出offset和MessageSize。MessageSize至少会大于Message头里边的那些crc、Attributes, MagicBytes等加起来的大小,因此如果MessageSize比这个还小,就肯定是个entry有问题,所以就抛出异常。这里的问题在于,即使MessageSet最后的那个Message是不完整的,只要MessageSize有问题,也会抛异常,而不是忽略这个不完整的Message。(这个可能是没考虑到,也可能是有别的考虑,不过无论怎么处理最后的这个不完整的Message,都有一定的道理)。
consumer端的验证
consumer(0.9)会检查checksum,不过是可以配置的,原因正如config里说的一样。
public static final String CHECK_CRCS_CONFIG = "check.crcs"; private static final String CHECK_CRCS_DOC = "Automatically check the CRC32 of the records consumed. This ensures no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so it may be disabled in cases seeking extreme performance.";
config的文档说,检查checksum是为了"ensures no on-the-wire or on-disk corruption to the message occurred."即,为了保证没有在网络传输出或者磁盘存储时出现了消息的损坏。但是checksum计算时会带来开销,所以追求最佳性能,可以关掉checksum的检查。
下面来看一下几个与消息格式相关的KIP。为什么需要这些改变呢?为什么之前没有实现这些改变呢?都是因为各种折衷吧,需求与性能折衷,需求与实现所需的工作量的折衷……
下面的几个KIP可能会一起加上去,毕竟都是对消息格式的修改,不能搞冲突了。
KIP-31 - Move to relative offsets in compressed message sets
前边提到了,在leader收到ProduceRequet之后,它会解压开compressed message(也就是是这个KIP里的compressed messageset,这两说说法的确有些乱),然后给里边包含的message set的每条消息重新赋予offset。这个做法也是应该的,乍一看也没什么不好。但是问题在于,不仅是直接改个offset这么简单,在改完之后,需要重新压缩这些消息,还要计算。这么一搞,开销就大了。KIP-31就是想把这部分的性能损失降下来。(这个KIP已经是accepted状态)
做法是把在一个compressed message set里边的每个message的offset里记下当前message相对于外层的wrapper message的偏移。用汉语说这个意思比较费劲,KIP里这么说
When the producer compresses a message, write the relative offset value in the raw message's offset field. Leave the wrapped message's offset blank.
When broker receives a compressed message, it only needs to
- Decompress the message to verify the CRC and relative offset.
- Set outer message's base offset. The outer message's base offset will be the offset of the last inner message. (Since the broker only needs to update the message-set header, there is no need to re-compress message sets.)
注意,这个wrapper message里记的base offset, 是它所含的message set里的最后一个message的offset。这个和当前的compressed message的offset是一致的。
然后当broker收到一个压缩后的消息时,它只需要
- 验证CRC与realtive offset的正确性
- 重新设定外层消息的offset,也就是base offset。
KIP-32 - Add timestamps to Kafka message
在消息里加时间戳。需要注意的是,这个KIP还在讨论中(以下的内容是基于2016年1月7日的版本)。不像上一个已经确定了。
(俺是觉得这个事情早该做了……)
首先,来看一下动机,这个提有意思
Motivation
This KIP tries to address the following issues in Kafka.
- Log retention might not be honored: Log retention is currently at the log segment level, and is driven off the last modification time of a log segment. This approach does not quite work when a replica reassignment happens because the newly created log segment will effectively have its modification time reset to now.
- Log rolling might break for a newly created replica as well because of the same reason as (1).
- Some use cases such as streaming processing needs a timestamp in messages.
说的是这几个原因
1. Log retention会不靠谱。当前log retention是在log segment层面做的,是按照log segment的最后修改时间确定是否要删除一个log segment. 但是,当replica重分配发生时,新被分配的这个replica的log segment的修改时间会被设成当前时间。这么一来,它就不能被按照log retention想要做的那样(实际上是想把一段时间之前的消息删除)被删除。
2. 由于和1同样的原因,对于一个新创建的replica(意思应该是移动位置的replica, 并不是增加分区后新加的replica)log rolling有时候也会不靠谱。
3. 有些场景中需要消息含有时间戳,比如流处理。
感觉,貌似第三个原因才是决定性的,拥抱流处理。
接口的变化
准备在Message里加入timestamp字段
准备增加两个配置
- message.timestamp.type 可以选CreateTime或者LogAppendTime,CreateTime就是这条消息生成的时间,是在producer端指定的。LogAppendTime就是append到log的时间(实现细节没有说明)。
- max.message.time.difference.ms 如果选择了CreateTime, 那么只有当createTime和broker的本地时间相差在这个配置指定的差距之内,broker才会接受这条消息。
纠结之处
之前关于这个KIP的讨论主要是关于使用哪个时间, 是使用LogAppendTime(broker time),还是CreateTime(application time)。
两种都有利有弊:
The good things about LogAppendTime are: 使用LogAppendTime的好处在于
- Broker is more robust. Broker比起用户程序更健壮(更不容易出错,比如用户程序可能有bug,导致CreateTime设置的不正确,想一想KIP-33,如果错得离谱,索引怎么建?)
- Monotonically increasing. LogAppendTime是单调增长的。(但是,follower收到的消息的timestamp该怎么设呢?如果不用leader带来的,就不能确定是否monotonically increasing)
- Deterministic behavior for log rolling and retention.log rolling和retention的行为是确定性的。(如果按消息里的这个timestamp来决定这两个操作的行为,那么让用户指定timestamp的确挺危险的)
- If CreateTime is required, it can always be put into the message payload.如果需要CreateTime,可以加到消息的内容里。(这个的确是……)
The good things about CreateTime are: 使用CreateTime的好处是
- More intuitive to users. 更符合用户的思维(用户当然是想使用自己填进去的时间)。
- User may want to have log retention based on when the message is created instead of when the message enters the pipeline.用户可能更希望用消息被创建的时间来决定log retention的行为,而不是消息进行处理管道的时间。
- Immutable after entering the pipeline.这样,消息的timestamp在进入管道后就不会再改变了。
在俺看来,这两个选择的确挺纠结的。用户肯定是想用自己产生消息的时间,不然很难准确地找到一条消息。但是,如果使用用户指定的时间,broker端的行为就变得复杂了,比如,如果用户指定的时间不是单调递增的,该怎么建时间索引。但是用户产生畸形的时间,倒可以通过配置里max.message.time.difference.ms来控制。或许可以加另一个配置,允许broker在一定范围内修改CreateTime,比如最多可以更改1000ms。这样就能即使消息的timestamp单调增长,也能使用户对消息的时间的估计比较准确。不过,这样可能就需要让broker time的含义变成broker收到消息时间,而不是append到log的时间。否则就难以确定何时该拒绝无法在指定范围内修改timestamp的消息。
KIP-33 - Add a time based log index
动机:
当前按照时间戳查找offset得到的结果是非常粗粒度的,只能在log segment的级别。(对于reassigned replica就差得没谱了。)所以这个KIP提议建一个基于时间的对日志的索引,来允许按timestamp搜索消息的结果更准确。
这个KIP和KIP-32是紧密相关的。这俩KIP都在讨论过程中。