比如就一个服务A，部署在服务器1上。
redis部署在服务器2上。
为什么还会需要redis连接池这个东西？我在服务A上维护一个全局变量的redis连接实例，前端请求过来我都是用这个连接实例去执行redis指令，不也可以吗？
redis连接池，无非就是高并发的时候可以支持多个redis连接实例去连接redis，但是redis本身就是单线程的，我多个连接同时去连redis（不还是得排队么），然后执行指令，和我单个全局连接直接去一个个执行redis指令，感觉应该差不多性能吧？
而且如果是全局单个redis连接的话，每次请求过来我还省了连接这个操作，不是又省了点时间么？
同步阻塞IO和IO多路复用的区别，一个形象的比喻就是老师要检查完10个学生作业，你的方式（同步阻塞）是一个一个检查，如果有一个学生还没准备好那后面的就一直等待，另一种方式就是哪个学生做完了举手告诉老师，然后老师直接检查他，检查完了再检查下一个举手的学生。
#5
更多评论
https://studygolang.com/articles/10660
这位同学尝试不用连接池，而是实现应用层面的pipelining（不是redis自身协议层面的pipeline）：
现有的redis客户端都是需要所有goroutine同步对某个redis连接的使用，goroutine A发出请求并收到回复后才能将连接让给其它goroutine使用，而在A等待回复的过程中redis协议是支持可以继续往这条连接发送请求的。可以用一条连接来同步发送所有goroutine的并发请求，然后根据从redis服务端收到的回复按发送顺序逐个回复各个goroutine的请求
连接池就是多个goroutine通过多条连接同时往redis发请求来达到pipelining的效果，试图充分利用redis，不让它空闲。但这样不如直接利用一条连接来实现应用层的pipelining，就像http1.x的pipelining没有真正实现，到http2就彻底实现了，现在的redis服务端就像http1.x的服务端实现是FIFO，也没办法做到像http2那样彻底的pipelining，除非redis再弄个协议
https://hpbn.co/http1x/#http-pipelining
#2
今日阅读排行
一周阅读排行