Session 同步问题
rdbsave 进程创建时会从主线程同步 socket 相关的 session 资源。目前社区中 epoll fd 相关的 session 资源没有同步完全，主要是因为 session handle 中包含了各个进程的 worker_index 信息，而 worker_index 是因进程 / 线程而异的，直接从主线程同步过来的 session handle 需要根据 worker_index 做转换才能使用。相关的 patch 目前已经合入社区。
死锁问题
rdbsave 进程退出时需要释放和进程关联的 session 资源，目前是通过主线程捕获 SIGCHLD 信号，在信号处理函数中来释放相关 session 资源。如果主线程在先获取锁 A 的情况下跳转到信号处理函数释放资源，而释放资源的时候也获取了锁 A，则会导致死锁。当然我们可以针对锁 A 的情况想办法解决此问题，但是这种解决方式不彻底，因为主线程可能获取了锁 B 后再去执行信号处理函数释放资源，然后释放资源的时候也获取了锁 B。根源是在于执行信号处理函数之前的主线程状态未知。
所以，我们可以考虑在信号处理函数中不释放资源，而仅仅将待释放的资源索引进行保存，等到后面合适的时机，如执行 epoll_wait 的时候再进行释放。相关的 patch 目前也已经合入社区。
效 果
通过优化后的火焰图看效果：
可见，内核的 socket 读写已经大大降低，还遗留的是用户态协议栈实现中用来在 VCL 和 VPP 之间通知事件的 eventfd 通知。
基于 redis 4.0.9 以及 memtier_benchmark 1.2.17 测试的结果。
QPS 提升 31%，此时内核态 Redis CPU 占用 99%，用户态 Redis CPU 占用 80% 左右。
延迟降低 23.2%，同样此时内核态 Redis CPU 占用 99%，用户态 Redis CPU 占用 80% 左右。
总 结
用户态协议栈可以轻松做到针对 Redis 的无侵入加速，在占用 CPU 资源更少的情况下，相较内核态协议栈可以取得 31% 的 QPS 加速效果，同时延迟降低 23%。
用户态协议栈作为通用的加速组件，理论上可以支持所有 Socket 类应用的加速。目前基于用户态协议栈对网易数帆轻舟微服务 API 网关中 Envoy 的加速已经产品化并在网易严选环境中落地，针对 Sidecar 的加速也相继在内外部客户完成测试，针对 Redis 的加速也完成了 PoC 测试。整个加速组件的数据面基于 Kubernetes 的 DaemonSet 部署，而管控面基于 Kubernetes 的 Operator 部署，部署简单、运维方便。我们也会在后续工作中，持续探索基于用户态协议栈的更多应用场景。
