总结一下遇到过的网络同步IO导致服务阻塞的问题
这篇讲的是作者在工作中亲身遭遇的两个因同步IO引发服务阻塞的典型问题。第一个场景是fri_svr服务需要向第三方平台（如人人、Facebook）批量拉取用户数据，由于整个HTTP请求/响应周期过长（1s-10s），当并发请求量升高时，按user_id哈希分配的专用线程队列会发生堆积，直接导致服务内存暴涨并无法及时响应前端。 第二个场景则发生在使用ICE同步RPC的数据服务上。作者发现，某个线程队列中只要有一个任务（对应某个用户的请求）被意外阻塞，后续同队列的所有任务都会被拖累，导致部分用户响应延迟几分钟。而哈希到其他队列的用户则不受影响。 为了解决问题，作者将线程模型从“一个线程对应一个队列”调整为传统的线程池（多线程对应一个队列），从而避免了单点阻塞的连锁反应。但核心挑战在于保证同一用户（拥有相同owner）任务的执行顺序。作者设计了一个线程安全的数据结构：内部维护任务队列和一个KV表来记录每个owner是否正在被处理。任务被取出时，会检查并锁定owner状态，从而确保后续任务不会被乱序执行。 作者最后也指出，这种方案会引入额外的check/set开销与线程竞争。如果任务都是执行时间可控的CPU密集型任务，那么最初的一对一线程队列模型可能仍是更优选择。