介绍
多个事件可以描述同一个订单：创建、付款、发货。相关记录被一致路由时，消费者可以在一个分区内跟踪订单顺序。记录键（record key）提供稳定的路由输入，不同于标识单次事件发生的 event_id。
你将向三分区主题发布三个订单交错的事件，打印实际键和位置，并为已有订单添加一个事件。偏移量（offset）是记录在单个分区内的位置。偏移量不是整个主题的全局行号，不同分区中的记录也没有保证的单一全局顺序。
代理和输入数据独立准备，基本终端操作即可。事件值使用可读 JSON 文本；无需 Python、JSON 编程、集群配置或之前主题状态。整个实验保持分区数和客户端路由策略固定。请使用终端。
使用订单键发布交错事件
在这一步中，你将把稳定的订单标识符作为键发送，同时将完整事件保留为值。查看提供的五记录批次：
cd /home/labex/project
cat /home/labex/project/data/keyed-orders.txt
每行形式为 key|value。键是订单标识符。JSON 值在花括号中使用命名字段：event_id 唯一，order_id 与键一致，sequence 是该订单的业务顺序，event_type 描述发生的事情。JSON 文本是值的格式；Kafka 不会自动将其解释为表模式。
创建三个分区、一份副本的主题：
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-keyed --partitions 3 --replication-factor 1
生产者的 --reader-property 选项配置输入行的解释方式。parse.key=true 和 key.separator=| 在分隔符处拆分每条输入行。分隔符本身不成为键或值的一部分。Shell 的 < 将文件提供为标准输入，生产者发送完有限输入后退出：
kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-keyed --reader-property parse.key=true --reader-property 'key.separator=|' < /home/labex/project/data/keyed-orders.txt
文件交错排列订单，因此 order-2001 的事件在输入中不相邻。在相同键路由策略和不变分区数下，相同键路由到相同分区。不同键可以共用分区；三个订单不保证使用三个不同分区编号。
提供的五记录批次只发布一次。重复消费者读取是在检查，重复生产者命令则会追加五条记录。如果发布后继续操作，请进入消费者检查，不要重新发送文件。
你提供了路由输入，没有手动选择分区号。接下来，你将读取实际路由决策，不去猜测。
一起检查键、分区和偏移量
在这一步中，你将为每个值显示记录元数据。控制台消费者的 --formatter-property 选项控制显示，在普通输出中加入键、分区和偏移量，不改变已存储事件内容。新消费者从头读取选项、五消息上限和空闲超时，让这次有限检查可重复。将输出保存到本地：
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-keyed --from-beginning --max-messages 5 --timeout-ms 30000 --formatter-property print.key=true --formatter-property print.partition=true --formatter-property print.offset=true > /home/labex/project/output/keyed-first.txt
cat /home/labex/project/output/keyed-first.txt
每条数据行大致具有以下形式，使用实际数字和完整 JSON 值：
Partition:... Offset:... order-... {"event_id":"...",...}
分隔符是制表符。找到 k1 和 k3：它们的键都是 order-2001，应共用分区，k3 的偏移量更大。k2 和 k4 也应共用 order-2002 的分区。不要要求两个订单使用不同分区。
偏移量属于分区，不属于键。如果其他键共用该分区，一个订单相邻事件的偏移量可能不连续。载荷中的 sequence 字段是应用值，不是 Kafka 生成的偏移量。
消费者可能交错显示不同分区的记录，因此全局显示顺序不一定与生产者文件一致。应通过键、分区和递增偏移量检查相关事件，不要把输出当作一个全局有序列表。
为已有订单添加另一个事件
在这一步中，你将通过另一次生产者调用测试相同路由规则。预测 order-2001 的 shipped 事件：它应进入该订单已有的分区，跟在其先前记录之后。精确偏移量取决于共用分区的其他记录。
第一个 Kafka 实验中的 printf 模式，将一条完整带键行发送到相同控制台生产者设置：
printf '%s\n' 'order-2001|{"event_id":"k6","order_id":"order-2001","sequence":3,"event_type":"shipped"}' | kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-keyed --reader-property parse.key=true --reader-property 'key.separator=|'
读取全部六条保留记录，保存为新观察结果：
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-keyed --from-beginning --max-messages 6 --timeout-ms 30000 --formatter-property print.key=true --formatter-property print.partition=true --formatter-property print.offset=true > /home/labex/project/output/keyed-with-shipped.txt
cat /home/labex/project/output/keyed-with-shipped.txt
找到键为 order-2001、sequence 为 3 的 k6。将它的分区与 k1、k3 比较，将偏移量与它们比较。按分区偏移量顺序查看时，该订单应保持 created、paid、shipped 的顺序。无需固定分区编号。
原来的五记录观察结果仍在 keyed-first.txt。新生产者追加事件，不替换之前事件。主题分区数和路由策略可能影响路由，因此本实验特意保持两者不变。如果后续客户端需要在不同实现之间保持相同映射，就必须选择兼容路由策略。
现在，你拥有稳定按键路由与分区内顺序的证据，没有假设全局事件顺序或每订单独占一个分区。下个挑战将对新批次应用相同主题、保留和带键发布技能。
总结
你提供订单键，检查实际分区和偏移量，并验证追加事件在相同路由规则下跟随该订单先前记录。你区分了事件 ID、订单键、载荷顺序和分区偏移量，避免假设全局顺序。接下来，新批次挑战会把这些技能与主题保留配置结合起来。
