我建议您使用一些现成的 kafka client tools （比如官方脚本）直接拉取topic 中的msg 看看，以排除由于外部原因导致消息收不到的可能性。
好的，好的，我去搞一下，谢谢
问题找到了，用了官方的kafka例子，那边当消费到update语句时，抛了eof exception，未打印，导致没有消费到。非常感谢.
顺便问一下消费到的头信息有乱码，我该如何转换 如下
�{“u”:{“adunit_show_id”:{“t”:15,“f”:48,“v”:“8857DF8141EDD73E8B35B5CB0807C09E”}
去除前8位？然后再json parse一下？
cdc 的输出协议中有部分二进制编码，并非是纯粹的 json。
对于 message key，前 8 字节是大端序编码的 int64 类型；后八位是下一个json 的长度（大端序编码的 int64 类型）
对于 message value，前八位是下一个json 的长度
一个 kafka message 可能包含多个 cdc event，需要消费端解析，拆开
详见：
https://docs.pingcap.com/zh/tidb/stable/ticdc-open-protocol#message-格式定义
附：java 语言解析 open protocol demo
https://github.com/pingcap/ticdc/tree/master/demo/java
好的，谢谢
你好问一下我这边运用了官方的demo，但是解析value时报eof exception，key能正常解析
�{“u”:{“adunit_show_id”:{“t”:15,“f”:48,“v”:“A9586D2727D47996E235C7F0FB03DC18”},“cacheTime”:{“t”:246,“f”:193,“v”:“4.00”},“create_time”:{“t”:7,“f”:1,“v”:“2020-09-02 16:33:06”},“enable”:{“t”:1,“f”:65,“v”:0},“enable_end_time”:{“t”:7,“f”:1,“v”:“2020-11-20 16:58:31”},“enable_start_time”:{“t”:7,“f”:1,“v”:“2020-09-26 16:58:28”},“id”:{“t”:3,“h”:true,“f”:11,“v”:5},“other_plat_id”:{“t”:3,“f”:49,“v”:99782},“update_time”:{“t”:7,“f”:33,“v”:“2020-11-17 15:09:42”}}} 此条是value信息
为什么读出来的长度比真实value的长度还大？
跑了一下测试用例里的demo，可以通过，请问一下这是哪里有问题
请移步新的帖子中讨论
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。