想象一下，在运行kafka进程/代理的机器上，我们有3个分区属于3个不同主题的场景 . 此代理将接收所有三个分区的消息 . 它会将它们存储在不同的日志子目录中 . 我的问题是 Kafka 经纪人如何安排这些写作？它如何决定下一个要写的分区/主题？
对于按请求排序，下图显示了代理在内部处理生成请求的方式：
有许多网络线程可以提取网络层的字节并将其转换为内部请求 . 然后，这些请求被卡在一个fifo请求队列中，io线程从这里请求它们并将包含的消息附加到相关的分区 . 因此，简而言之，消息按接收顺序处理 .
查看代码我不确定，这里是否存在竞争条件的可能性，其中较小的请求可能“超越”紧接在其之前发送的大型请求 . 然而，即使这是可能的，这是一个极不可能的边缘情况，我看不出一个单一的 生产环境 者 . 也许有更好理解代码的人可以在这里权衡一下？
至于在一个请求中对批处理消息的排序，请求在内部将消息存储在HashMap中，HashMap使用TopicPartition作为键，因为据我所知，Scala HashMap不保留插入元素的顺序，我不认为对于一个请求中的多个分区的处理顺序有任何保证 - 这很好，因为只能保证在分区内保留排序 .
在每个分区中，消息按照发送前给 生产环境 者的顺序进行处理 .
1 回答
对于按请求排序，下图显示了代理在内部处理生成请求的方式：
有许多网络线程可以提取网络层的字节并将其转换为内部请求 . 然后，这些请求被卡在一个fifo请求队列中，io线程从这里请求它们并将包含的消息附加到相关的分区 . 因此，简而言之，消息按接收顺序处理 .
查看代码我不确定，这里是否存在竞争条件的可能性，其中较小的请求可能“超越”紧接在其之前发送的大型请求 . 然而，即使这是可能的，这是一个极不可能的边缘情况，我看不出一个单一的 生产环境 者 . 也许有更好理解代码的人可以在这里权衡一下？
至于在一个请求中对批处理消息的排序，请求在内部将消息存储在HashMap中，HashMap使用TopicPartition作为键，因为据我所知，Scala HashMap不保留插入元素的顺序，我不认为对于一个请求中的多个分区的处理顺序有任何保证 - 这很好，因为只能保证在分区内保留排序 .
在每个分区中，消息按照发送前给 生产环境 者的顺序进行处理 .