红色初识里边聊聊Redis配置那些事儿，还有watch功能怎么用的简单观察

网络上关于Redis配置和watch功能的常见讨论与官方文档释义的综合整理）

今天咱们就随便聊聊Redis这个好东西，特别是刚开始接触它的时候，那两个让人有点摸不着头脑但又挺重要的点：一个是那一大堆配置文件该怎么看，另一个是那个听起来很酷的“watch”功能到底怎么用，咱们就用大白话来说,不整那些专业术语。

第一部分：初识Redis配置，就像刚拿到新手机的设置

你第一次打开Redis的配置文件（通常是redis.conf），是不是感觉头都大了？密密麻麻的，像天书一样，别慌，咱们不用一口气全看懂，就像你买了个新手机，也不会一下子把几百个设置项都调一遍，对吧？咱们先挑几个最常用、最重要的来看看。

也是最关键的，门牌号”，也就是端口号，Redis默认住在6379这个端口上（来源：Redis默认配置），为啥是6379？有个挺有意思的说法是，它在手机键盘上对应着“MERZ”，是一个早期广告里的角色，算是程序员的幽默吧，你当然可以改，比如改成6380，但要是没特别需求，用默认的就行,大家都习惯。

然后就是“绑定地址”，默认情况下，Redis只允许本机（就是你运行Redis服务的这台电脑）连接它，配置里写的是bind 127.0.0.1，如果你想让它能被网络上的其他电脑访问，比如你的应用服务器和Redis不在同一台机器上，你就得把这个注释掉，或者改成bind 0.0.0.0（表示允许所有地址连接），但要注意，安全第一！如果你把Redis暴露在公网上，又没有设置密码，那简直就是开门揖盗，所以这就引出了下一个配置：密码。

“requirepass”这个配置项就是用来设置密码的，你找一个地方，把这行注释去掉，然后在后面写上你的密码，比如requirepass my_strong_password，这样，客户端连接的时候，就得先输入密码才能操作了，这就像你家门的钥匙,不能谁都给。

再来说说“数据存在哪儿”，Redis的数据是存在内存里的，但为了防止重启后数据全丢，它有个持久化功能，会把内存的数据写到硬盘上，这里面主要有两种方式，RDB和AOF，RDB就像是给数据拍个快照，隔一段时间拍一张，配置里用save 900 1这样的规则，意思是900秒内如果至少有1个key变了，就拍一张快照，优点是恢复快，文件小；缺点是可能会丢失最后一次快照之后的数据，AOF更像是写日记，把每一个写操作命令都记录下来，这样数据更安全，但文件会比较大，恢复起来也慢点，刚开始，你可能用默认的RDB就够了,等业务重要了再深入研究AOF。

还有其他很多配置，比如最大内存限制（maxmemory，防止内存用爆）、日志级别（loglevel）等等，不用一次搞定所有，用到哪个查哪个,慢慢就熟悉了。

第二部分：Watch功能，像个侦探一样盯着数据

现在咱们聊聊watch这个功能，它不是什么复杂的命令，但想法很巧妙，你可以把它理解成一种“乐观锁”，啥是乐观锁？就是我觉得大概率不会有人跟我抢着改同一条数据，所以我先不着急上真正的锁把数据锁死，那样会影响别人操作，我呢，先派个“侦探”去盯着这个数据。

具体怎么用呢？举个例子，比如你要在一个多人竞拍系统里，处理一个人出价，流程是：先查看当前商品价格，然后判断你的出价是否高于当前价，如果高,就更新价格。

如果没有watch，可能会出问题：你查到的价格是100块，正准备更新成150块的时候，另一个人抢先一步把价格改成了120块，但你不知道啊，你还是用100块这个旧数据去判断，然后成功更新成了150块，结果就是第一个人出的120块被你覆盖了,这显然不对。

这时候watch就派上用场了，你用的时候大概是这么个步骤（来源：Redis事务与Watch命令的常见用法）：

1. 你先WATCH这个商品的key，就像对Redis说：“嘿，帮我盯住这个商品的价格，它有啥风吹草动马上告诉我。”
2. 然后你开始执行你的业务逻辑：获取当前价格,判断。
3. 你开启一个事务（MULTI），把你要更新的命令（比如SET price 150）放进去。
4. 你执行事务（EXEC）。

关键点来了：当你执行EXEC的时候，Redis会去检查一下你之前WATCH的那个key，从你WATCH之后到现在，有没有被别的客户端修改过，如果没人动过，那么好，你的事务顺利执行，更新成功，如果发现这个key已经被别人改动了（比如价格已经从100变成120了），那么Redis就会认为你的操作基于的数据已经过时了，它会直接让你的整个事务失败，EXEC命令返回nil（空）。

这样一来，刚才那个竞拍的bug就避免了，因为当第二个人试图用旧价格100去更新成150时，Redis发现价格已经被第一个人改成了120，于是拒绝第二个人的操作，第二个人程序里收到失败信号后，就可以选择重试整个流程（重新查询价格、判断、出价）。

watch就是一种轻量级的、检查数据是否被篡改的机制，它不像传统数据库的表锁行锁那样霸道，直接不让别人读写了，而是先让你操作，最后提交时再检查，冲突了就算你倒霉，重来一次，这在很多并发不高或者冲突概率不大的场景下,性能会更好。

Redis的配置看着复杂，但核心的就那几条，慢慢摸索就行，而watch功能是一个很实用的并发控制小工具，理解了“乐观锁”这个比喻，就知道它该怎么用了,希望这点简单的观察能帮你对Redis有个更亲切的认识。