多设备本地媒体播放同步：主从角色自动协商及故障切换问询

这个多节点同时抢当MASTER的问题在分布式局域网场景里太常见了——你的初始PING/PONG逻辑没考虑到多个节点会同时发现MASTER失联，导致大家都觉得自己该补位，最终出现多个MASTER的混乱局面。结合你现有UDP组播+本地媒体的架构，给你几个容易落地的解决方案：

方案1：基于唯一标识的优先级选举（最可靠） #

核心思路是给每个客户端分配一个全局唯一的标识（比如MAC地址、启动时生成的UUID，甚至是客户端的IP地址），选举时让标识“最大”（或最小）的节点胜出，从根源避免冲突。具体步骤：

• 当某个节点2秒没收到MASTER的PONG，先发送一条ELECTION_REQUEST组播消息，带上自己的唯一ID，声明“我要参选MASTER”。
• 其他处于候选状态的节点收到这条消息后，立刻对比自己的ID：
  • 如果自己的ID比消息里的大，就回复一条ELECTION_CHALLENGE组播消息，告诉对方“我ID更大，我来参选”；
  • 如果自己的ID更小，直接退出候选状态，转为SLAVE，等待最终MASTER的通知。
• 发起参选的节点如果在500ms内没收到任何比自己ID大的挑战消息，就发送MASTER_ANNOUNCE组播消息，正式宣布自己成为MASTER；所有节点收到后，统一切换为SLAVE模式，同步新MASTER的播放位置。

这个方案的好处是绝对不会出现多个MASTER，唯一需要注意的是要保证每个节点的ID在局域网内唯一（用MAC地址或者UUID完全能做到）。

方案2：随机延迟退避（最简单，适合局域网） #

如果不想搞复杂的选举逻辑，可以给你的初始逻辑加一层随机延迟缓冲，大大降低多个节点同时触发MASTER声明的概率：

• 当节点2秒没收到PONG，不要立刻宣布自己是MASTER，而是先生成一个100ms到500ms之间的随机延迟时间，进入等待状态。
• 在等待期间，如果收到其他节点发送的MASTER_ANNOUNCE消息，立刻放弃参选，转为SLAVE。
• 如果延迟时间到了，还是没收到任何MASTER的消息，再发送MASTER_ANNOUNCE组播消息，成为MASTER。

这个方案的优势是改动极小，只需要在你的现有代码里加个随机延迟函数就行。局域网内网络延迟很低，随机时间足够让节点们“错开”抢MASTER的时机，基本不会出现冲突。

方案3：租约机制（适合需要稳定MASTER的场景） #

如果你的场景对MASTER的稳定性要求很高（比如不想因为MASTER短暂卡顿就频繁切换），可以引入MASTER租约的概念：

• MASTER每隔1秒发送一条MASTER_LEASE组播消息，相当于“我还在线，我的MASTER身份再续1秒”，租约有效期设为3秒。
• 所有SLAVE节点持续监听租约消息，如果连续3秒没收到，就认为MASTER失联，进入候选状态。
• 候选节点发送LEASE_REQUEST组播消息，同样可以结合方案1的ID优先级，让ID最大的节点获得租约，成为新MASTER。

这个方案能避免因为网络短暂抖动导致的误选举，保证MASTER角色的连续性，适合对播放稳定性要求高的场景。

额外优化建议 #

• 选举期间，SLAVE节点可以暂时暂停播放，或者保持当前播放速度，等新MASTER的同步消息到来后再调整，避免播放混乱。
• 所有选举相关的消息（ELECTION_REQUEST、MASTER_ANNOUNCE等）都用UDP组播发送，确保局域网内所有节点都能收到，不需要点对点通信。
• 测试时可以模拟极端场景：比如同时启动10个客户端，或者突然拔掉MASTER的网线，观察选举是否能快速完成且无冲突。

内容的提问来源于stack exchange，提问作者ulvesked