使用协程开发流媒体rtsp客户端拉流的利与弊

使用协程带来的最大好处就是流程特别清晰，前段时间用libgo实现rtsp 客户端拉流，确实代码精简了很多，拉一路流一个协程，发送了请求就等着响应。遇到的问题点是：1、关闭流时如果协程阻塞在socket读写，只能close(socket)让它返回，那如果时阻塞在sleep呢，怎样让它跳出阻塞没找到方法。2、拉流时调度线程占cpu很高，这不奇怪，我做的流媒体服务拉流，都是500+路流同时在拉，以G计的流量肯定导致io软中断和上下文切换非常高（题外话，可以用DPDK技术解决，用腾讯开源库f-stack就好）。

为了优化以上，改成rtsp 拉流信令交互部分用协程，信令结束后就直接用epoll或libevent收流，果然服务cpu降低了很多，一个很好的方案。

最终没有用以上方案，一是之前公司没用libgo库，不想再引入，二是libevent用到的功能太少，就epoll回调，而且大家更倾向于使用轻量级的asio（实战性能不错哦，要配合捕获this智能指针使用），然后就改成只依赖asio实现了，性能也很好（rtp/rtcp和码流包的解析都自己写的，解析后记录数据位置，统计出帧长度后再分配空间复制数据，减少一次拷贝）。

对协程的总结：在信令交换上确实是减少流程跳转的好东西，不用再去写状态翻转了，值得一用。但处理的流量大了，还是用异步的网路库，不然读写触发调度线程伤不起。

我也是第一次使用协程，以上分享请多多怀疑去验证。