京公网安备11010502063487号三组真实故障转移看投票:3 主 3 从杀 1 个主库,从库发 5 条 auth-req,两个幸存主库各投 1 票(从库不投票)后升主;杀 2 个主库时只剩 1 个主库,被杀主库停在 PFAIL、没有任何从库发起选举,cluster_state 一直 fail;5 主 5 从杀 2 个仍有 3 个主库,两个从库都成功升主。
验证 Redis Cluster 的两种 epoch:新建 3 主 3 从集群 configEpoch 是 1/2/3、current_epoch 6;手工制造两个 configEpoch = 5 的冲突,握手后约 116 ms 内自动分开(一个变 6);冻结旧主库再解冻,新主库的 configEpoch 升到 7,旧主库解冻后仍接受了一次写入(3/3 次),随后 10–13 ms 变成从库,该次被 OK 的写入丢失。
本机3节点集群里开一个事务写3条消息先不提交，验证read_uncommitted立刻读到、read_committed读到0条；提交后read_committed追上来；中止的事务里read_uncommitted瞬间看到过，但read_committed永远看不到。
验证一个读—处理—写循环把输出produce和offset提交塞进同一个事务，模拟处理完但崩溃在提交之前，重试后committed offset和输出内容验证只留下一份结果，没有重复。
用sqlite对比naive双写(DB提交后单独发Kafka，崩溃后事件永久丢失)和outbox模式(订单和待发事件同一事务提交，relay崩溃重试后消息重复但不丢)。
对同一条消息构造三种真实消费方式，验证at-most-once丢失、at-least-once重复、exactly-once物理重试但最终只确认一次的具体差异。
3分区topic用3个key各发10条消息，验证同key消息哈希到同一分区且分区内严格有序，但consumer的跨分区全局到达顺序不等于发送顺序。
直接dump __cluster_metadata内部topic的原始日志，看broker注册、topic创建、故障切换如何变成REGISTER_BROKER_RECORD/TOPIC_RECORD/PARTITION_CHANGE_RECORD等具体记录。
检查本机Kafka 4.3.1安装目录，确认ZooKeeper相关脚本和配置已完全不存在，用老式zookeeper.connect配置启动直接报错缺少process.roles。
kill掉3节点KRaft集群当前的controller quorum leader，验证剩下2/3投票节点完成重新选举，且集群操作在此期间完全未受影响。
客户端只在bootstrap.servers配置一个broker，验证它能学到完整的集群broker列表和分区leader映射，并成功把消息发送到配置里从未出现过的broker。
创建6分区3副本topic观察初始leader的round-robin分布规律，kill一个broker后验证只有受影响的分区换了leader。