dispatch_mode影响Worker接收连接方式，共7种模式。模式1轮询适合短连接；模式2固定分配适合长连接粘滞性；模式3抢占式适配协程高并发；模式5基于IP哈希用于会话保持。HTTP服务推荐mode=2或mode=3，TCP长连接可用mode=2/5，UDP建议mode=1或3。配置示例中启用mode=3配合协程提升性能。注意避免mode=1在长连接下的负载不均，优先选用mode=3并结合压测调优。
Swoole的dispatch_mode参数决定了Worker进程如何接收客户端连接和数据，合理设置对服务性能影响很大。这个参数共有7种模式（1-7），不同业务场景适合不同的模式。
1. 理解dispatch_mode的常见模式
模式1：轮询分配（Round Robin）
每个请求按顺序分给下一个Worker。适合短连接、负载均衡要求高的场景，比如HTTP API服务。
模式2：固定分配（Fixed Hash）
根据fd % worker_num把连接固定分配到某个Worker。适合需要连接粘滞性的场景，但可能造成负载不均。
模式3：抢占式（Preemptive）
Swoole 4.4+引入，基于事件驱动自动调度，适合协程+Channel的编程模型，高并发下表现优秀。
模式5：IP哈希分配
根据客户端IP做hash，相同IP总是进入同一个Worker。适用于需要会话保持的TCP服务，比如聊天服务器。
2. 按业务类型选择最合适的模式
HTTP/WebSocket服务（推荐 mode=2 或 mode=3）
- 如果使用同步阻塞代码，mode=2更稳定
- 如果启用协程（如Swoole 4.5+），强烈建议mode=3，能充分发挥协程调度优势
TCP长连接服务（如IM、游戏）
- 若需保证同一连接始终由同一Worker处理，用mode=2或mode=5
- 若使用连接池+协程，可尝试mode=3提升吞吐
UDP服务
- 建议mode=1（轮询）或mode=3，避免因hash导致丢包或乱序
3. 实际配置示例
在Swoole Server创建时设置：
$server->set([
'dispatch_mode' => 3,
'worker_num' => swoole_cpu_num() * 2,
'enable_coroutine' => true,
]);
对于传统同步TCP服务：
'set' => ['dispatch_mode' => 2,
]
4. 注意事项与调优建议
不要盲目使用mode=1
虽然轮询看似公平，但在长连接下可能导致某些Worker负载过高。
mode=3是未来趋势
配合enable_coroutine使用，能实现更高QPS，尤其适合I/O密集型服务。
测试验证最关键
- 用ab、wrk或自定义压测工具对比不同mode下的QPS、延迟、CPU占用
- 观察日志是否出现Worker过载或请求堆积
基本上就这些。多数现代Swoole项目建议从mode=3开始，结合实际压测结果微调，效果最稳。
