在开发一个基于Libevent的及时通讯App时，遇到客户端Request包与Server响应的Response包之间出现30s至2min的延迟问题。通过接入层日志分析和Tcpdump抓包，定位到问题是由于Libevent的延迟读回调导致，进一步发现是包堆积在Epoll的LT模式下未被及时处理。解决方案是修改读回调逻辑，检查outbuffer是否有剩余数据并处理。这次经历加深了对Reactor工作模式的理解。
背景描述：
最近做一个Mini项目，实现包括语音的及时通讯App，我负责后台的开发。底层的网络收发框架采用的是Libevent的bufferevent，是一个基于事件驱动的高效异步I/O框架，接口简单易懂，采用linux内核的Epoll实现网络事件触发。经过封装用在项目中，在和终端测试时出现问题：终端发送的Request包，Server回应的Response包居然延迟30s---2min不等。简直不能忍！
问题定位：
由于服务器架构分为介入层+逻辑层+存储层，每个来自终端的请求包，都要经过接入层的转发，在对应的逻辑层进行处理和响应。延迟的时间是在客户端？接入层？逻辑层？一个请求包从终端发出到接受到对应响应包为整个流程，可分为如下几个时间段：
最低0.47元/天 解锁文章
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
