多线程同时访问Redis怎么搞，多个线程抢着用redis的那些事儿

（引用来源：Redis官方文档关于并发处理的说明，以及常见的多线程编程实践经验）

多线程同时访问Redis,这事儿说白了，就是有好几个程序（或者一个程序里的好几个部分）同时想使唤同一个Redis，就像一群人同时想挤进一个小门拿东西一样，处理不好，轻则拿错东西、数据对不上，重则直接把Redis给搞崩溃了，核心问题不是“能不能同时用”，而是“怎么有秩序地同时用”。

最基础也是最关键的一点,Redis本身是“单线程”处理命令的，别误会，这不是说Redis能力弱，恰恰相反，它这个设计就是为了避免多线程带来的复杂锁问题，让所有命令排着队一个一个执行，保证了每个命令的原子性，原子性就是说，一个命令执行的时候，不会被别的命令插队，要么完全成功，要么完全失败，不会出现执行到一半被干扰的情况，这就像是银行只有一个柜台，大家虽然都在排队，但每个人办业务的时候都不会被其他人打扰，账目肯定不会乱。

问题就出在“排队”这个环节上，你的多个线程（我们称之为客户端）是同时向Redis这个“柜台”发送请求的，如果大家只是读数据，那基本相安无事，反正读到的都是同一份数据，麻烦的是当有线程要修改数据的时候。

第一个常见的乱子：数据写丢了。

想象一个场景,库存就剩1件商品了，线程A和线程B同时去读库存，都读到了“1”，它们俩都觉得自己能抢到这个商品，于是都执行“库存减1”的操作，结果，Redis先后收到了两个“减1”的命令，库存最终变成了“-1”，这显然不对，明明只有一件商品，却卖出了两单，这就是典型的“并发写”问题。

怎么解决呢？Redis提供了一种叫做“原子操作”的命令，比如上面的减库存，就不要先读后算了，直接用Redis提供的 INCR 或 DECR 命令，你想减1，就直接发一个 DECR key 命令，这个命令在Redis内部是原子性执行的，在执行过程中不会有其他命令插进来，所以绝对不会出现上述问题，这就好比你不是告诉柜台“帮我看看还剩多少，然后你心算一下再告诉我减掉一个”，而是直接说“帮我办理减掉一个库存的业务”，柜台自己完成整个操作，保证了正确性。

第二个更隐蔽的乱子：竞争条件。

有时候业务逻辑很复杂,不是一两个原子命令能搞定的，你需要先检查某个条件，条件满足了再执行一系列操作，线程A检查条件，满足，然后它正准备执行后续操作的时候，线程B插进来，把条件给改了！等线程A继续执行时，条件其实已经不满足了，但它还蒙在鼓里，导致数据出错。

对付这种情况,就得用上Redis的“武器”——事务 和 乐观锁。

1. 事务（Multi/Exec）：你可以用 MULTI 命令开启一个事务，然后把一系列命令放进去，最后用 EXEC 命令一起执行，Redis会保证这一批命令按顺序连续执行，中间不会被其他客户端的命令打断，这就像是把你要办的多项业务（比如取钱、转账、存钱）一次性告诉柜台，柜台把你这一整套业务办完，才会接待下一个人，这解决了多个命令执行中途被干扰的问题。

2. 乐观锁（Watch）：但事务有个小缺点，它不关心事务开始后、执行前，你关心的数据有没有被别的线程改动过，这时候就需要“乐观锁”了，你可以在 MULTI 之前，先用 WATCH 命令盯住一个或几个关键的键（key），一旦你 WATCH 了这些键，在 EXEC 命令执行之前，如果其中有任何一个键被其他客户端修改了，那么你整个事务都会执行失败（返回nil），你的程序收到失败信号后，可以重试这个业务流程（比如重新读取数据，重新判断条件，再发起新的事务），这叫“乐观”，是因为我们假设冲突不常发生，万一发生了，我们就回滚重来，这就像你去买东西，先把商品拿在手里看着（WATCH），然后去收银台结账（MULTI...EXEC），如果在结账时，营业员发现这个商品已经被别人扫码了（被修改了），就会告诉你交易失败，你得回去重新拿一件。

   

第三个要注意的：连接管理。

每个线程都自己创建一条到Redis的连接,当然可以，但这样开销很大，Redis服务器能支持的连接数是有限的，频繁创建销毁连接也很耗资源，通常的做法是使用“连接池”，连接池就像是一个管理出租车队的公司，当线程需要用Redis时，它不是自己去买车（创建连接），而是向连接池“租”一辆现成的车（获取一个空闲连接），用完了之后，不是把车销毁，而是还回池子里（释放连接），给其他线程用，这样既避免了资源浪费，也提高了效率，常见的Redis客户端（比如Java的Jedis、Lettuce，Python的redis-py）都内置了连接池的功能，配置一下就能用。

性能问题。

虽然Redis本身很快,但如果你的线程太多，疯狂地发送请求，Redis这个单线程的“柜台”也可能忙不过来，导致请求堆积，响应变慢，这时候，可以考虑一些架构上的优化，是不是有些频繁读但不常写的数据，可以在应用本地做个缓存，减少对Redis的直接访问？或者，如果写操作实在太多，是不是可以用Redis的“主从复制”功能，搞几个“副柜台”（从节点）专门负责读，分担“主柜台”（主节点）的压力？

多线程玩转Redis,核心就是“秩序”二字，利用好Redis提供的原子命令、事务和乐观锁，来保证数据操作的正确性；使用连接池来管理资源，提高效率；再根据实际压力，从架构层面思考如何分担负载，理解了这些，你就能让多个线程在Redis面前变得“彬彬有礼”，高效协作，而不是一窝蜂地乱抢了。