先说个我自己的经历。刚转行做后端那会儿领导扔给我一台Mac电脑第一件事就是把Redis装上配好项目要用了。我当时觉得很简单brew install redis一条命令跑完再brew services start redis测了一下redis-cli ping返回PONG就以为完事了。后来才知道真正用到Redis的时候面对的是一整套配置问题这份redis.conf到底加载的是哪一份数据重启之后会不会丢局域网同事怎么连不上日志塞在哪个目录占了好几个GB这篇文章就是围绕macOS上安装并配置Redis这个主题把我从安装、配置文件、验证、日常使用到踩坑的完整过程整理出来每一步都尽量讲清楚为什么要这么做。适合刚接触Redis的开发者也适合已经装了Redis但配置一直一知半解的朋友。1. 动手安装之前先弄清楚Redis在你机器上扮演什么角色1.1 别只把它当缓存Redis是内存数据结构服务器很多人提到Redis第一反应就是缓存。这不算错Redis最出名的用法确实是给数据库挡流量、给接口加速但它的定位其实比缓存宽得多。Redis把所有数据存储在内存里所以读写速度能到每秒十万次以上同时它又提供了足够丰富的数据结构字符串、哈希、列表、集合、有序集合后面还加了Stream、GEO、Bitmap这些扩展类型。你可以把它当缓存用也可以拿它做会话保持、排行榜、消息队列、分布式锁甚至当成一个轻量级的数据库。我在实际项目里最常见的组合是MySQL存全量Redis存热点。MySQL像仓库什么都放得下但每次拿货都慢Redis像前台储物柜常用的东西摆在手边取用很快但要清楚它也是占地方的内存容量有限所以放进Redis的数据最好都是短平快的数据有明确的过期时间或者淘汰策略。这个概念没建立起来后面配置数据结构和淘汰策略的时候就容易随手乱写。1.2 三种安装方式Homebrew、源码编译、Docker在macOS上装Redis通常有三条路。第一条是用macOS的包管理器Homebrew命令最少和系统结合最好还能用brew services把Redis注册成开机自启的后台服务这也是我推荐大多数人走的路线。第二条是从官网下载源码自己编译能控制版本和编译选项但需要装Xcode Command Line Tools要自己处理启动脚本和配置文件纯属给自己加活。第三条是Dockerdocker run redis就能跑一个完整的Redis实例隔离性最好还能一条命令搭出主从、哨兵但它绕开了macOS的本地服务机制日常写代码调试时还得管理容器生命周期反而多一层。三种方式各有适用场景。我个人的选型逻辑很简单如果只是本机开发调试用Homebrew最省心如果是为了复现某个环境问题、要同时测试多个Redis版本或者搭主从演练用Docker更干净只有当需要定制Redis源码比如改内存分配器、编译时加模块时才考虑源码编译。这篇文章的主体以Homebrew为准往下讲想走其他路的朋友原理是一样的区别主要在启动方式和文件路径。2. Homebrew安装Redis的完整流程命令背后的关键选择2.1 先确认芯片架构再找对应的目录这一步我当时忽略了后面浪费了不少时间。Intel芯片的MacHomebrew默认装在/usr/local目录下M1、M2、M3这些Apple Silicon芯片的MacHomebrew装在/opt/homebrew目录下。两边的可执行文件、配置文件和日志目录都不一样查资料时如果混着看很容易把路径搞错。先跑一条命令确认uname -m如果输出是x86_64那Homebrew前缀大概率是/usr/local如果输出是arm64那大概率是/opt/homebrew。实在不放心用brew --prefix看一下Homebrew会直接告诉你它自己装在哪。后面所有和路径相关的操作都以这个前缀为准比如Intel上配置文件通常是/usr/local/etc/redis.confApple Silicon上则是/opt/homebrew/etc/redis.conf。2.2 安装三步走brew update、brew install、brew services start第一步刷新一下Homebrew自己的仓库索引brew update注意保持Homebrew和Redis版本都新一些不然后面可能碰到老版本配置文件格式不兼容之类的问题。第二步brew install redis这一步会把redis-server、redis-cli、redis-benchmark这些可执行文件全都装好不需要手工下载源码或者配置环境变量。第三步启动服务。这里有两个选择直接跑redis-serverRedis会以前台进程的方式运行终端窗口一关它就没了适合临时调试另一个是brew services start redis这是把Redis注册成一个由macOS launchd管理的后台服务开机自动启动、意外退出会被拉起日志统一输出适合日常开发环境。我建议日常开发用后者因为它省去每次开机手动启动Redis的麻烦。跑完brew services start redis用redis-cli ping验证一下返回PONG说明服务已经在跑了。2.3 brew services与redis-server的关系daemonize保持no的原因很多人在教程里看到Redis配置文件里有daemonize yes就照着改成yes结果启动后反而怪怪的。这里要理清楚daemonize yes的含义是让Redis自己fork到后台运行。如果你用brew services来管理服务后台化这件事已经由launchd做了Redis只需要以前台进程的方式跑着把日志交给launchd重定向就行。如果这时候再开daemonize yes会出现进程管理混乱的问题所以Homebrew生成的redis.conf里daemonize这一项是no。你用命令redis-cli shutdown关停服务时也是走brew services的逻辑下次启动还是由brew services接管。2.4 安装后先看一眼这份目录表不同芯片架构的常用路径我整理成一张表方便对照检查项目Intel MacApple Silicon MacHomebrew安装目录/usr/local/opt/homebrew配置文件redis.conf/usr/local/etc/redis.conf/opt/homebrew/etc/redis.confRedis可执行文件/usr/local/opt/redis/bin/redis-server/opt/homebrew/opt/redis/bin/redis-server服务日志常见位置/usr/local/var/log/redis.log/opt/homebrew/var/log/redis.log持久化数据目录以redis.conf中的dir为准以redis.conf中的dir为准最后一行是重点Redis的数据文件dump.rdb、appendonly.aof存在哪取决于配置文件里dir这一个参数不是约定俗成的固定目录。我见过有人找了半天数据文件找不到最后用redis-cli CONFIG GET dir一看原来落在启动目录里。安装完成后先用CONFIG GET dir和CONFIG GET logfile确认实际值心里有数了再往下配。3. 手工接管redis.conf与macOS环境强相关的几个配置项3.1 第一步永远是备份然后确认加载的配置改配置文件之前我强烈建议先复制一份备份命令很简单cp /opt/homebrew/etc/redis.conf /opt/homebrew/etc/redis.conf.bakIntel芯片就把路径换成/usr/local。这一步花十秒钟却能省下改坏了恢复的麻烦。然后确认当前Redis实际加载的配置来自哪个文件。方法很多可以用ps aux | grep redis看启动参数如果是brew services管理的进程里通常能看到配置文件的绝对路径。更直接的办法是连上Redis之后执行redis-cli CONFIG GET dir redis-cli CONFIG GET logfile redis-cli CONFIG GET requirepass这些命令拿到的就是当前运行实例的真实配置值比你在配置文件里猜半天靠谱得多。改完配置之后记得用brew services restart redis重启服务再用CONFIG GET去验证。3.2 安全三件套bind、protected-mode、requirepassRedis装上之后默认配置是只允许本机连接的这对本地开发其实是安全的选择。配置里跟安全强相关的三样东西我逐个说清楚。第一是bind。默认情况下redis.conf里是bind 127.0.0.1 -::1意思就是只有本机的回环地址和IPv6回环地址能连上来。如果你只是自己本机用这个默认值完全不用动。第二是protected-mode。这个模式解读起来有点绕在没有显式配置密码、并且bind没有限制到内网网段的情况下Redis会拒绝来自非本机的连接。它本质上是给你兜底的保护防止你把一个没有密码的Redis裸奔到局域网里。第三是requirepass。如果哪天你需要让局域网里的其他机器连这个Redis有两条路要么改bind加上内网段地址要么直接bind 0.0.0.0同时必须配好requirepass。比如requirepass yourstrongpassword客户端连接时用redis-cli -a yourstrongpassword或者在交互环境里先AUTH yourstrongpassword。我自己的习惯是尽量不用命令行参数传密码因为进程列表里会暴露明文更稳妥的方式是设置环境变量REDISCLI_AUTHredis-cli会自动读取它来完成认证。这里要特别提醒一旦你为了局域网访问把bind改成0.0.0.0却没有设requirepass或者密码设成了弱密码Redis基本就是在网里裸奔任何扫到6379端口的人都能连进来读写数据。这可不是危言耸听网上有大量因为Redis无密码被入侵的事件。3.3 日志与数据目录排查系统数据占用过大时记得看一眼RedismacOS用户经常发现系统数据这个存储分类越占越大排除掉Xcode缓存、iOS备份镜像这些大头之外有时候Redis也要背一部分锅。Redis的日志文件如果长期不轮转大到几个GB很正常持久化文件dump.rdb或者appendonly.aof如果数据量大也会躺在一个隐蔽的目录里。建议在排查空间时跑一下du -sh /opt/homebrew/var/log/redis.log /opt/homebrew/var/db/redis 2/dev/null如果你自己改过logfile或dir以CONFIG GET返回的路径为准。处理手段也很直接日志可以清空或者交给logrotate轮转数据文件如果确认是Redis产生的且不需要保留可以让Redis停住再把文件清掉。不过要小心删掉持久化文件等于把当前内存数据之外的最后一道保险也拆了删之前一定要确认有没有备份。3.4 RDB和AOF持久化配置是新手最容易忽略的命门Redis的数据默认存在内存里但内存一断电就没了所以Redis设计了两种持久化方案RDB是定期把内存里的数据拍个快照存到磁盘里AOF是把每次写命令追加到一个日志文件里。RDB恢复快但两次快照之间的数据可能丢AOF丢数据少但文件会越来越大还需要重写压缩。redis.conf里默认有一段类似这样的RDB触发条件save 900 1 save 300 10 save 60 10000意思是900秒内至少有1次写操作就存一次快照300秒内至少有10次写操作60秒内至少有10000次写操作。所以如果项目里写入频率很低可能很久都不触发RDB重启后数据丢了就很正常。想减少数据丢失就把这一行打开appendonly yesAOF开启之后Redis会把每一条写命令追加到appendonly.aof文件里配合appendfsync everysec最多丢最后一秒的数据这对大多数场景足够用了。我自己踩过最惨的一次是本机Redis里放了一些半成品的缓存数据想着反正Redis嘛重启不会丢结果Mac重启之后里面空空的原因就是当时只靠默认RDB快照根本没到触发条件。后来我无论本地还是服务器只要数据有一点恢复价值一律先开appendonly yes。这行配置的成本很低带来的安全感却很高。4. 配置完之后不要急着开心按这套方法验证一遍4.1 命令行三连ping、INFO server、CONFIG GET安装和配置做完先别急着关终端用redis-cli做一轮快速的健康检查。第一条redis-cli ping正常会得到PONG这只能说明服务进程活着所以如果配置了requirepass先AUTH或者直接redis-cli -a 你的密码。第二条redis-cli INFO server这条命令返回一大段信息里面重点看redis_version和process_idversion能确认当前用的版本是不是自己预期的那版。第三条redis-cli CONFIG GET maxmemory redis-cli CONFIG GET maxmemory-policy这两个值在默认配置里通常一个为0不限制一个为noeviction不淘汰。如果你准备拿Redis做缓存得先把maxmemory按机器内存情况设定再选一个淘汰策略不然内存被打爆的后果是Redis直接报OOM错误写入全部失败。4.2 重启恢复验证写入、优雅关闭、再启动真正能验证持久化配置有没有生效的是一个重启恢复实验。步骤也很简单redis-cli进入交互模式之后SET boot_test hello GET boot_test然后执行redis-cli shutdown这会触发Redis优雅退出期间会尝试保存RDB如果开了AOF也会把缓冲区刷到AOF文件。接着brew services start redis或者用brew services restart redis也一样。再进去执行GET boot_test如果能拿回hello说明数据落盘成功。如果拿到了nil先确认持久化配置和写入时是否设置了EX过期。这个小实验花不到一分钟但能让你摸清自己这套配置的脾气后面真出问题时心里就不慌。4.3 redis-benchmark一把尺子量一下本机性能Redis自带的redis-benchmark工具可以快速压一下本机性能命令形如redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -d 100意思是用50个并发连接发10万次请求每个value 100字节测完会输出一堆requests per second数字。M系列芯片的Mac跑本机Redis常见的QPS水平在十万到几十万之间具体数值受机器和版本影响不用太较真。这个工具更大的价值是验证Redis跑起来确实很快以及机器IO或者网络配置有没有明显拖后腿。如果性能数据低到了异常程度回头就要查一下是不是日志级别太高、内存swap了或者持久化配置过于激进。5. 日常连接与管理从命令行到桌面客户端5.1 redis-cli是基本功桌面工具用来提效率命令行工具redis-cli一定是基本功不管用什么客户端最终排查问题时都会落回到它身上。但日常开发里盯着key-value列表看命令行确实不够直观所以配置一个顺手的桌面客户端很值得。我自己用过三类RedisInsight是官方出品的全功能、免费适合喜欢界面操作的开发者Another Redis Desktop Manager是开源跨平台的老牌选择支持批量操作、数据筛选适合Windows和Mac都用的朋友还有老的Redis Desktop Manager早期很流行但项目更新节奏慢新版本需要授权我后来换掉了。这些工具本质都一样只是把Redis协议包了一层可视化所以就算用了GUI也要保证自己能看懂redis-cli的结果。连接配置里无非是host、port、auth和上面讲的安全三件套里提到的信息对得上就能连上。5.2 高频概念速查数据类型、过期策略、分布式锁日常用Redis有几组概念会被反复问到尤其是面试和项目评审时。第一组是数据类型。Redis最核心的五种类型String能存任意字符串常用于缓存、计数、分布式锁的value。Hash适合存对象字段类似一张小表。List可以当队列用LPUSH/BRPOP是很经典的轻量消息队列。Set擅长去重和集合运算比如共同好友。ZSet多了score排序排行榜场景必选。用的时候先想清楚数据长什么样再选类型顺序反了后面代码会绕很多圈。第二组是过期与淘汰。Redis可以为每个key设置过期时间EXPIRE key seconds到期自动删除。如果内存达到maxmemory就轮到淘汰策略登场常见的有allkeys-lru对所有key做LRU淘汰、allkeys-lfu按访问频率淘汰、volatile-lru只对设了过期时间的key淘汰。做缓存治理时这一组参数直接决定线上缓存命中率和数据一致性值得花时间研究。第三组是分布式锁。多实例抢同一份资源时最简单的方案是SET lock_key unique_value NX EX 30只有key不存在时才能设置成功配合过期时间防止死锁。分布式锁的坑主要在持有时间到了但业务没跑完这类问题上光看用法几分钟就懂真做复杂了还得引入看门狗续期机制。5.3 本地开发环境别硬套生产配置同一份redis.conf本地开发和生产服务器最好用两套配置。本地调试时为了省事可以把密码关掉、持久化开着反正硬盘大、把maxmemory调高即使崩溃了也不心疼。生产环境就完全不同了必须开requirepass、bind要精确到需要的网段、appendonly要开、daemonize交给systemd或容器的进程管理、尽量禁用KEYS这类阻塞命令还要做好监控告警。我见过不少新手把本地配置文件直接scp到服务器结果发现Redis裸奔在公网IP上那一刻是真的会冒冷汗。我的习惯是写两个配置文件模板一个是local.conf一个是prod.conf内容分开维护绝不混用。6. 我在macOS上反复踩过的Redis坑排查笔记6.1 brew upgrade之后配置文件和数据文件版本对不上Homebrew的整体升级对Redis用户来说是双刃剑升级完Redis版本有时候旧版本的RDB文件在新版本里还能读但跨大版本时可能遇到报错提示RDB文件版本过旧或过新。另外Homebrew在更新formula时有可能把etc目录下的redis.conf用新版本默认内容替换掉你自己辛苦改的配置就被覆盖了。应对方法很朴素每次升级前先备份数据文件和配置文件升级完用redis-cli INFO server确认版本再用CONFIG GET验证自己的关键配置还在不在。如果有差异立刻用备份恢复。这事的教训就是不要以为brew upgrade是很无感的事情在Redis这里它真的会把配置环境微调一下。6.2 局域网连接不上别先怪防火墙先查bind和protected-mode有个朋友遇到过这么个场景macOS上的Redis已经跑着手机想连同一个局域网下的Redis做联调怎么都连不上。他第一反应是macOS防火墙拦截了6379端口折腾半天配置防火墙。其实大概率不是防火墙而是Redis默认只监听127.0.0.1。排查顺序应该是先在本机redis-cli ping确认服务正常再用lsof -i :6379看Redis进程究竟listen在哪些地址上然后检查redis.conf里的bind和protected-mode。如果需要局域网内访问把bind改成0.0.0.0或者具体的内网IP同时设好requirepass重启服务后再测。macOS防火墙确实也有可能拦截入站连接但那是排在最后的一步而且大多时候根本没有开防火墙或者首次弹窗时被拒绝了。6.3 内存数据文件越大系统数据占用越离谱我前面提到的系统数据占用过大问题在Redis场景下最典型的排查方式是用du -sh把Redis可能涉及的目录全列一遍。之前我在一台Mac上排查存储占用发现/opt/homebrew/var/db/redis下面有一个巨大的dump.rdb足有十几个GB那是之前测试批量写入留下的快照加上AOF文件也不小愣是把系统数据撑大了。处理方式不复杂确认没有需要保留的历史数据后清掉持久化文件重新规划dir路径到单独的数据目录并在配置文件里设置合理的maxmemory防止数据无脑膨胀。这件事最好的启示是安装完Redis的第一天就该把dir、logfile这些参数的目录路径规划好而不是等系统提示磁盘将满才想起来。6.4 改了redis.conf但就是不生效多半是重启方式和路径不对最后一个高频坑是配置改了服务也重启了但没生效。绕来绕去原因就两类。第一改错了配置文件。Intel和Apple Silicon路径不一样有人同时存在两份redis.conf改了一份brew services启动用的却是另一份。第二改了之后没有真正重启。直接redis-server启动的进程改配置文件不会自动热加载就算是brew services管理也得brew services restart redis单纯start在服务已经在运行的情况下是不会重新读取配置的。验证方法永远是靠CONFIG GET和实际的连接行为不要靠我感觉已经生效了。最后说一个我保持了很多年的习惯。每次换Mac或帮新同事搭环境我都会按固定顺序做三件事先备份redis.conf再用CONFIG GET dir和logfile确认数据到底落在哪最后把requirepass设好、appendonly打开。做完这三步这台Mac上的Redis基本就能安安静静跑很久。装Redis本身只是几分钟的事真正的门槛在配置逻辑。希望这份macOS安装配置Redis的实操记录能帮你把这条不算长但有不少弯的路走顺。