请注意，我已经阅读了很多以下文章，并试图在不同的论坛上找到相关信息，但没有成功：https://medium.com/@anishekagarwal/kafka-log-cleaner-issues-80a05e253b8a希望您能理解我的问题并给出一些线索=）
故事是这样的：
几天前，我们在kafka群集上部署了重复数据消除服务。自从我们使用这项服务以来，我们注意到消费者的主题开始增长。原因是日志清理器（用于压缩此主题）确实崩溃，并出现以下错误：java.lang.illegalstateexception:此日志包含的消息大于允许的最大大小1000012
根据我们的理解，我们首先认为这是一个消息大小问题，所以我们增加了max.messsage.bytes（直到超过20mb）值，但随后我们得到了相同的问题（错误消息用新值正确更新）。
因此，我们开始认为这可能是某种“损坏的”消息大小值或“误解的段”（比如kafka log cleaner版本没有正确处理消息）
我们能够分离出引起问题的线段偏移量。这很奇怪，因为当我们使用一个简单的消费者时，记录大约是4k字节，但是消费者只使用这个记录需要7到8分钟（在这个轮询过程中，tcpdump清楚地显示来自代理的许多>1000字节的数据包）。
因此，我们开始使用dumpsegment类来查看段，它看起来是这样的（我替换了一些值以匿名化一点）：

Dumping 00000000004293321003.log

Starting offset: 4293321003

baseOffset: 4310760245 lastOffset: 4310760245 count: 1 baseSequence: -1 lastSequence: -1 producerId: 66007 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 0 CreateTime: 1556544968606 size: 78 magic: 2 compresscodec: NONE crc: 2072858171 isvalid: true

| offset: 4310760245 CreateTime: 1556544968606 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

baseOffset: 4310760295 lastOffset: 4310760295 count: 1 baseSequence: -1 lastSequence: -1 producerId: 65010 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 78 CreateTime: 1556544968767 size: 78 magic: 2 compresscodec: NONE crc: 2830498104 isvalid: true

| offset: 4310760295 CreateTime: 1556544968767 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

baseOffset: 4310760731 lastOffset: 4310760731 count: 1 baseSequence: -1 lastSequence: -1 producerId: 64005 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 156 CreateTime: 1556544969525 size: 78 magic: 2 compresscodec: NONE crc: 3044687360 isvalid: true

| offset: 4310760731 CreateTime: 1556544969525 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

baseOffset: 4310760732 lastOffset: 4310760732 count: 1 baseSequence: -1 lastSequence: -1 producerId: 66009 producerEpoch: 2 partitionLeaderEpoch: 50 isTransactional: true isControl: true position: 234 CreateTime: 1556544969539 size: 78 magic: 2 compresscodec: NONE crc: 1011583163 isvalid: true

| offset: 4310760732 CreateTime: 1556544969539 keysize: 4 valuesize: 6 sequence: -1 headerKeys: [] endTxnMarker: COMMIT coordinatorEpoch: 0

所以我们看到了很多像上面这样的束
然后错误的偏移量使日志更干净崩溃：

baseOffset: 4740626096 lastOffset: 4740626096 count: 1 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 50 isTransactional: false isControl: false position: 50471272 CreateTime: 1557322162912 size: 4447 magic: 2 compresscodec: NONE crc: 3030806995 isvalid: true

| offset: 4740626096 CreateTime: 1557322162912 keysize: 25 valuesize: 4352 sequence: -1 headerKeys: [] key: {"metadata":"MYGROUPID"} payload: {"protocolType":"consumer","protocol":"range","generationId":32,"assignment":"{CLIENTID=[TOPICA-0, TOPICA-1, TOPICA-2, TOPICA-3, TOPICA-4, TOPICA-5, TOPICA-6, TOPICA-7, TOPICA-8, TOPICA-9, TOPICA-10, TOPICA-11], AND THIS FOR ABOUT 10 OTHER TOPICS}"}  ==> approximative 4K bytes

这看起来不像标准的消费偏移数据模式（groupid，topicname，partitionnumber]：：偏移模式），我认为这是因为新服务使用了kafka事务。
我们认为这次崩溃可能是因为我们的kafka群集是0.9.11（或者可能是1.0.1），而我们的重复数据消除服务使用的是kafka 2.0.0 api（并使用事务）。
我有一些审问：
在处理kafka事务时，\u consumer\u offset主题如何处理提交的偏移量？我一点也不懂结构。。似乎有多个提交标记消息（但不知道它是什么主题或分区）。。那么这是如何工作的：/？）总是跟在这个包含元数据标记的非事务nnal记录后面。。有关于这个结构的文件吗？
1.1.0 kafka cluster的log cleaner版本是否可能无法正确处理\uu consumer\u偏移量中的此类事务消息（使用2.0.0 api提供）？
这里欢迎任何线索/更正。
雷加兹，
扬尼克