【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】OB的libeasy和sql_nio
【 使用版本 】4.x
【问题描述】为什么4.x版本处理mysql请求不使用libeasy通信框架了，而重新封装epoll，自己写了个sql_nio异步事件处理框架。是出于ssl、国密适配等功能考虑还是性能考虑。后续ob是否会出一些ssl、国密适配的文章想要学习一下 
【复现路径】无
【问题现象及影响】代码疑问，无影响。
【附件】无
第一个问题，为什么observer对mysql协议从libeasy切换到sql nio？
直接原因：基于easy封装的mysql协议的网络框架，逐渐发现有两类需求不好实现：
- 大部分sql请求都是一来一回的，也即一个请求一个响应，但是也有例外。在send long data协议里，client会连续多次给server发包，并不要求server有response。很自然地协议要求同一个连接上的多个请求要串行执行，否则语义是不定的。现在easy解包之后直接丢给worker线程池，无法保证多个请求串行执行。
- 大部分sql请求都很小，但是send file local是例外，实际上这个协议本质是流式的，要求worker线程处理过程中源源不断读socket，明显和现在基于easy的封装不匹配。
总结一下，libeasy天然是个异步框架，但mysql协议本质是个同步的协议，会有不匹配的地方。这并不是说libeasy就不能支持，而是一个综合考虑之后的技术决定。
对未来需求的考虑：observer会逐步增加网络框架的租户隔离，限流等高级feature，把libeasy替换成一个更简单的sql nio，从研发成本上看也是值得的。
第二个问题，网络框架是否和SSL，国密适配有关系？基本没有关系。
2 个赞
感谢老师解答，之前对send long data和send file local了解的比较少。不过要串行执行的话可以之前好像可以通过条件变量唤醒对应的工作线程，路由到这个线程继续处理，不知道我的理解对不。