开发 我还是选择 Linux

6.0 以前 从网络 IO 处理到实际的读写命令处理，都是由单个线程完成的。
问题出现 ： 随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。
6.0 以后 Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令，Redis 仍然使用单线程来处理。
为什么 主线程要阻塞 猜测大概 redis 要保证请求是严格按照到达顺序执行。

第一点 ： 两个函数高度相似能不能合并成一个
第二点 ： 可以先行判断的前提条件可以提到前面部分
第三点 ： 可以直接返回的判断是不是可以不用嵌套

我感觉简单改可以按这个改 。

CDN 就可以解决

第一点 ： 不能这么干。

不用了，自己看代码解决了

没什么公平不公平的

取地址 修改

你建个测试库，然后就没有然后了

@young1lin 嘿呀，我只不过是个小学生，想向问问各位哥哥姐姐的，您项目是怎么样的流程能大致说说吗

@wm5d8b 额，可能我没太说明白，当前的场景是 用 grpc 框架 从前端到网关这里是 http1.1 那么从网关到最终的服务都是使用的 grpc，所以这里就是 从 http1.1 到 rpc 的

告诉产品 这个需求不做。

其实是有些定制化的需要,更想要的是一种插件的式的协议转换,现在就是两种选择，第一种就是网关自己写对前端请求的粗力度的接口，然后根据不同的业务线进行拆分成不同的网关。第二种就用一些常见的网关系统对请求进行二次的下沉。所以想找找别人的网关是怎么做的。。。

@Cy1 每加一个路由都是自己做的转发是吗？

@Cy1 是

@Cy1 一种数据传输格式，跟 json 和 xml 是一类产品

@renyijiu 感谢感谢，我去好好看看