多线程怎么搞才能让redis并发操作更快更稳，实操经验分享

想让Redis在多线程环境下跑得又快又稳，光靠想是不行的，得靠一些实实在在的招数，下面这些经验，是很多人踩过坑后总结出来的，你直接拿去用,能少走很多弯路。

第一招，连接池是命根子，一定要配好。

你别每个线程都自己去创建一个新的Redis连接，用完就关，这太傻了，创建和关闭连接本身就很耗时间，在高并发的时候，系统资源一下子就被耗光了，Redis自己也受不了，这就像你去银行办业务，如果每个人都要银行现开一个窗口,那大厅早就乱套了。

你得用连接池，这就像是银行提前开好一批窗口，你来办事，直接从池子里拿一个现成的窗口用，用完了还回去，别人接着用，这样效率就高多了。（这个道理在Java的Jedis、Lettuce这些客户端库里都是通用的）

具体怎么配呢？关键参数有几个：最大连接数、最小空闲连接数、最大等待时间，最大连接数不能设得太小，不然线程一多，大家都等着抢连接，就堵住了；但也不能设得太大，不然Redis服务器内存会被连接占满，这个数你得根据自己业务的并发量慢慢调，比如一开始可以设成50或100，然后看着监控数据调整，最小空闲连接数保证随时有“预备窗口”，来了请求能快速响应，最大等待时间就是设置一个线程等连接能等多长时间，超时了就直接报错，别让它一直傻等,避免雪崩。

第二招，能用管道（Pipeline）就别一次一次地发命令。

你想啊，网络传输是有延迟的，如果你一个线程要执行10次SET操作，你发一个命令，等Redis回复，再发下一个，这中间大部分时间都在等网络来回跑，10次操作,就是10次网络延迟。

用管道（Pipeline）就是把10个命令打包成一个包裹，一次性发给Redis，Redis收到后，按顺序一口气执行完，再把所有结果打包成一个包裹发回来，这样总共就只有一次网络来回的延迟，对于需要批量操作或者一个流程里有很多次Redis交互的场景，速度提升是非常明显的，快几倍甚至几十倍都很正常。（Redis官方文档里也强烈推荐在高负载下使用Pipeline）

但是要注意，管道里的命令别塞太多，不然会占用Redis服务器太多内存，也容易导致网络阻塞，一般建议一批命令控制在100个以内,或者根据数据大小灵活调整。

第三招， Lua脚本搞定复杂原子操作。

有时候你的业务逻辑比较复杂，比如要先判断某个值，然后再决定是增加还是设置新值，如果你用多线程，先读后写，即使用了管道，这两个操作也不是原子的，中间可能被其他线程插队,数据就不准了。

这时候Lua脚本就是大杀器，你可以把一整组复杂的操作写成一个Lua脚本，一次性发给Redis，Redis会保证这个脚本的执行是原子性的，在执行过程中不会被任何其他命令打断，这样就既保证了数据绝对正确，又避免了用悲观锁（比如WATCH）那种可能失败重试的麻烦。（这个特性在Redis处理需要原子性的复杂事务时是核心方法）

第四招，键值对的设计要动脑筋。

Redis是单线程处理命令的（指核心网络IO和命令执行），这是它快的原因，但也成了瓶颈，如果你能把数据分散开，别让所有线程都盯着同一个Key操作,压力自然就小了。

比如有个计数器，叫“网站总访问量”，所有线程都来给这个Key做加一操作，这个Key就成了热点，Redis再快也得一个一个处理，但如果你能按天、或者按业务模块拆成多个Key，访问量:20240527”、“访问量:用户模块”，这样不同的线程可能操作的是不同的Key，并发能力就上去了,这就是一种分片的思想。

第五招，别忘了设置合理的过期时间。

如果你的Redis主要做缓存，一定要给Key设置过期时间，不然内存迟早会被塞满，然后Redis就要启动淘汰机制，淘汰数据本身也会消耗CPU资源，可能就会导致你正常的操作变慢，设置了过期时间，数据会自动清理，内存使用率保持健康,Redis自然就稳。

监控不能少。

你不能配好了就撒手不管，要用Redis自带的INFO命令或者监控工具，经常看看几个关键指标：连接数、内存使用率、每秒操作数（QPS）、延迟时间，如果发现连接数总是满的，可能就是连接池不够大；如果延迟变高了，可能是命令太复杂或者有大的键值对，根据监控数据不断调整优化,才能一直保持又快又稳。

核心就是：用好连接池和管道减少不必要的开销，用Lua脚本保证复杂操作的原子性，通过良好的键设计避免热点，再加上设置过期时间和持续监控，这几招结合起来,你的多线程程序操作Redis就能既快又稳了。