必须用线程安全双向链表管理proxy连接，因其通过细粒度锁与无锁跳表实现纳秒级操作，支持原子化“摘除→测试→重入”，避免redis方案的锁竞争、同步延迟与序列化开销。
多进程 Proxy 与双向链表的深度结合，关键不在“堆叠功能”，而在于让进程协作和数据管理形成闭环：进程负责并发吞吐，双向链表负责低开销、线程安全的状态调度与连接生命周期管理。HAProxy 的 MT_LIST 就是这一思想的工业级实现范本。
为什么必须用线程安全双向链表管理 Proxy 连接
在多进程 Proxy 场景中（如 ProxyPool 的 getter/tester/server 三进程架构），各进程需共享代理池元数据（如可用性、响应延迟、失败次数）。若用普通列表或 Redis 做中间存储：
- 频繁读写引发锁竞争，成为性能瓶颈
- 跨进程同步延迟高，健康状态滞后，导致请求发往已失效代理
- 无法原子化完成“摘除→测试→重入”这类典型操作链
而 MT_LIST 类型的双向链表，通过细粒度锁+无锁跳表辅助+内存预分配，在单进程内支持纳秒级插入/删除/遍历，并天然适配“按响应时间排序”“按失败次数隔离”等负载策略——这正是高性能 Proxy 节点的底层数据底座。
多进程分工与链表协同的典型架构
以 ProxyPool 为蓝本，但将 Redis 元数据层替换为共享内存中的 MT_LIST 实例：
-
Getter 进程：爬取新代理后，不写 Redis，而是调用原子接口
mt_list_append(&pool, &proxy)直接插入链表尾部 -
Tester 进程：使用
mt_list_iterate_safe()遍历链表，对每个节点发起异步探测；探测失败则mt_list_remove()摘除，成功则更新proxy.latency并触发mt_list_sort_by_latency() -
Server 进程：接收 API 请求时，从链表头部取响应最快且未被标记为 busy 的代理（O(1) 时间复杂度），并置位忙标志；返回后立即
mt_list_move_to_tail()放回链表尾部，保持活跃代理始终靠前
关键实现细节：避免常见陷阱
真正发挥效能，需绕过三个典型误区：
- 不要把整个代理对象存进链表节点：只存指针 + 精简元数据（IP、端口、last_check、latency、state），主体数据放共享内存池，链表仅作索引
- 禁止在遍历时修改非当前节点状态：MT_LIST 的 safe iterator 保证遍历期间可安全删除当前节点，但不可修改其他节点字段，否则破坏链表一致性
- 进程退出前必须显式释放链表资源：多进程共享内存中的链表需由主进程统一销毁，子进程只做业务操作；否则残留节点会阻塞后续启动
对比传统方案的实际收益
某爬虫中控系统实测（10 万代理规模，2000 QPS）：
- Redis 方案：平均获取代理耗时 8.2ms，P99 达 45ms，CPU 在序列化/网络 IO 上占用超 60%
- MT_LIST 共享内存方案：平均获取耗时 0.13ms，P99 为 0.41ms，CPU 占用稳定在 22% 以内
- 故障切换速度提升 17 倍：因健康状态变更无需等待 Redis 同步，tester 摘除节点后 server 下一个请求即避开
