面试官问到这个题的时候，我第一反应是：这哥们儿是真的用过Redis，还是只看过八股文？因为“最大可用内存”和“数据库数量”这两个参数，单看名字都很简单，一个叫maxmemory，一个叫databases，但真要在生产环境里给出一套合理配置，背后牵扯的是内存淘汰策略、持久化机制、实例规格、业务隔离方式，甚至还有Redis Cluster的天然限制。不是简单地回答“设多少G、设多少个库”就完事儿的。
1. 先把这两个参数搞清楚：它们到底管的什么事
1.1 maxmemory：Redis能吃掉多少内存，谁说了算
maxmemory这个配置项，字面意思是Redis实例允许使用的最大内存上限。默认情况下它是0，在64位系统上这个0表示不限制，也就是说Redis会尽可能多地使用物理内存，直到把机器内存吃光。
这里有个很容易被忽略的细节：maxmemory限制的是Redis自身存储数据所占用的内存，也就是used_memory那一部分，它不包含jemalloc分配器为了性能而预留的内存池，也不包含操作系统的页缓存。所以你在INFO memory里看到的used_memory和maxmemory之间，通常会有一段差值，这是正常现象。
关键问题在于，当used_memory达到maxmemory上限之后，Redis不会直接拒绝写入——除非你把maxmemory-policy设置成了noeviction。默认的策略其实是noeviction，在这种情况下，所有会增加内存占用的命令（比如SET、LPUSH、SADD等）都会返回错误，而读操作和DEL这类删除操作不受影响。
很多人实际踩过的坑是：上线的时候根本没配maxmemory，或者图省事直接设了一个很大的值，等到内存真的涨上去了，才发现连DEL大Key都开始卡了。为什么？因为DEL一个巨大的集合或列表，Redis需要异步释放内存，如果你的maxmemory设得太靠近物理内存上限，操作系统在内存分配上会变得保守，导致fork子进程做持久化时直接失败，或者触发OOM Killer把Redis进程干掉。这就是为什么行业里有个约定俗成的说法：maxmemory不建议超过物理内存的70%~80%，要留出给fork、给AOF重写、给系统页缓存的空间。
1.2 databases：16个库听着很多，实际能乱用吗
databases配置项控制的是Redis实例中有多少个逻辑数据库，默认是16，也就是0~15号。你可以在redis.conf里改成任意数字，比如databases 32，然后用SELECT命令切换。
但这里有个很残酷的现实：databases这个参数只在单机模式的Redis里生效。一旦你上了Redis Cluster，这个参数就算改成了128也没用，因为Cluster模式的数据库固定为0号，而且客户端访问的时候，集群模式下SELECT命令会导致错误。很多人做集群迁移的时候，发现自己原来在1号库里存的数据全部“不见”了，其实不是丢了，而是Cluster根本不认非0库。
而且即便是单机模式，我也强烈不建议在一个Redis实例里开多个库来隔离业务。官方文档和社区的主流看法都是：Redis多库主要是在早期内存紧张、硬件成本高的年代被当作“穷人的命名空间”来用，现代应用完全可以用不同的Redis实例、或者给Key设计统一前缀来隔离业务。原因有几个：
SELECT切换库是有开销的，而且在高并发连接池场景下，连接切换数据库会让连接状态变得不确定，调试困难。- 多个库共享同一个
maxmemory和同一套淘汰策略，一个业务把内存打满，会拖垮所有库里的其他业务。 - 运维监控维度简单，
INFO keyspace按库统计还好，但到了redis-cli --bigkeys、慢查询日志、热Key分析这些场景，多库会让问题定位变得复杂十倍。
所以说到底，databases不是越大越好，默认的16个库已经够用了，甚至绝大多数项目只用0号库就够了。
2. 最大可用内存到底该怎么设：不是拍脑袋，是计算出来的
2.1 先确定你的数据总量和增长模型
设置maxmemory的第一步，不是看服务器有多少G内存，而是先估算业务需要往Redis里放多少数据。你必须清楚三类数据：缓存数据、计数器/临时数据、以及那些“理论上可以无限增长”的集合类数据。
假设你的缓存Key大约有500万个，每个Key的平均长度约50字节，Value平均长度约200字节，那么单是这份数据就是500万×250字节，约1.25GB。再加上Redis内部对每个Key的字典表开销（redisObject、dictEntry、SDS头等，通常每个条目额外占50~100字节），实际要预留2GB左右才安全。
然后是增长模型。如果业务增速是每月20%，你至少要预留3~6个月的余量。所以一个简单粗暴的公式是：
建议
maxmemory= (预估基础数据量 + 峰值缓冲) × 1.3 ~ 1.5系数 / 0.8
最后除以0.8，是给内存淘汰和碎片整理留出空间，给lastest memory的波动留出余地。
举一个我实际做过的案例：一台8GB内存的云主机，系统占用约1.2GB，Redis本身进程约0.3GB，剩余可用约6.5GB。按照不能超过物理内存80%的原则，天花板大约是6.4GB。但我的业务数据预估是2.5GB，加上峰值缓冲到3.5GB，再乘1.3系数是4.55GB，最后除以0.8大约是5.7GB。所以我把maxmemory设成了5gb，而不是6GB甚至更大。实践下来，Redis长期维持在4GB水位，used_memory峰值接近5GB时，淘汰策略已经开始工作，但整个系统的fork和AOF重写依然平稳，没有出现过OOM和卡顿。
2.2 淘汰策略必须和maxmemory一起设计
只设maxmemory而不配maxmemory-policy，等于给车装了个限速器但又不踩刹车——一旦到了上限，写入直接报错，线上事故立刻出现。
在Redis 4.0之后，主要有以下几种淘汰策略：
| 策略 | 行为 | 适用场景 |
|---|---|---|
noeviction | 不淘汰，写入报错 | 强一致、不可丢失数据的场景 |
allkeys-lru | 对所有Key按LRU近似算法淘汰 | 通用缓存，最常见 |
volatile-lru | 仅对有expire的Key按LRU淘汰 | 混合存储（部分可丢、部分不可丢） |
allkeys-lfu | 所有Key按LFU访问频率淘汰 | 访问热点集中的场景 |
volatile-lfu | 仅对有expire的Key按LFU淘汰 | 缓存和持久数据混合 |
allkeys-random | 所有Key随机淘汰 | 数据访问均匀、无热点 |
volatile-random | 仅对有expire的Key随机淘汰 | 冷热均匀的可失效率场景 |
volatile-ttl | 淘汰剩余TTL最短的Key | 想让快过期的Key先走 |
我自己的习惯是：如果Redis里全部是缓存数据，直接上allkeys-lru，这也是95%以上项目的选择。如果Redis里还存了不能丢的会话、任务状态之类的数据，那我建议要么拆实例，要么用volatile-lru，并且给那些“不能丢”的Key不设置过期时间，让它们永远不被淘汰。
还有一个小技巧，很多人不知道：maxmemory-policy是可以在运行时用CONFIG SET动态修改的，所以当遇到内存暴涨、旧策略导致大量Key被误淘汰的时候，可以临时切换到allkeys-lru止损，然后再慢慢清理数据，不用重启实例。
2.3 不要忘记持久化对内存的额外需求
很多人在算maxmemory的时候只盯着业务数据，完全忽略了RDB和AOF对内存的临时性需求。
- 如果开了
RDB快照，bgsave的时候Redis会fork出一个子进程。虽然子进程共享父进程的内存页，但fork本身需要复制父进程的页表，内存越大，页表越大，fork的耗时和内存开销就越高。在超大实例上（比如几十GB），fork瞬间可能阻塞主线程好几毫秒甚至更久。 - 如果开了
AOF重写，同样需要fork子进程，而且重写期间如果有大量写入，父进程会维护一个AOF重写缓冲区，这个缓冲区可能额外消耗数百MB内存。 - 所以一个16GB内存的机器，
maxmemory如果设成14GB，那么一旦触发bgsave或AOF重写，内存很可能会瞬间冲破物理上限，轻则重写失败，重则直接被系统OOM Killer点名。
我的经验值是：maxmemory最大不要超过物理内存的75%。如果持久化用AOF且appendfsync策略是everysec，可以适当放宽到80%，但再高就非常危险了。8GB机器设5gb、16GB机器设12gb，这基本是安全线附近。
3. 数据库数量该怎么设：16个是默认，但不是让你真的去用16个
3.1 先搞清楚databases的底层含义
databases参数在Redis内部对应的是一张大小为N的redisDb数组。每一个库都是独立的键空间，也就是说同一个Key可以同时存在于0号库和1号库，两者互不影响。每个库有自己独立的expires字典、watch通知、阻塞Key等。
这个设计的初衷是：在一台物理机内存有限、Redis实例数受限的历史时期，通过一个Redis进程提供多个逻辑隔离的数据空间，减少进程数、节省端口、节省内存。但代价是所有这些库共用同一个单线程事件循环，也就是说，一个库里的慢查询或大Key操作，照样会阻塞其他库的命令处理。所以它的“隔离”非常有限，远不如独立实例彻底。
3.2 被滥用的多库：灾难的源头
我在排查过好几个生产事故，都和滥用多库有关。最典型的一个场景是：开发环境里Redis 0号库放缓存，1号库放Session，2号库放消息队列，3号库放限流计数器。一开始确实相安无事，等到某个大促活动，缓存Key瞬间暴增，allkeys-lru策略直接把1号库里所有Session都给淘汰了——因为根本没有区分“哪些库的Key可以被淘汰”，LRU是针对所有Key的。
还有一个坑是误操作。用过redis-cli的人都知道，默认连上的是0号库。如果你习惯了用0号库，哪天不小心SELECT 2之后忘了切回来，你执行FLUSHDB或者KEYS *的时候，清掉的就是2号库的数据。更可怕的是FLUSHALL，它会把所有库全部清空，连后悔的机会都没有。用多库，等于是把多个业务的数据安全绑定在同一个实例上，任何一个误操作都可能让所有业务一起遭殃。
所以我的结论是：databases保持默认的16不用动，但在应用层面坚持只用0号库。如果需要隔离，用不同的Key前缀（如cache:、session:、mq:）或者干脆起新的Redis实例。这样运维的监控、备份、扩容都简单很多。
3.3 当你真的需要调整databases时
当然，有些场景下你会想把databases改大或改小。比如某些开箱即用的第三方组件，默认会创建32个库来“分片”，这时候你就得把databases改到32。还有一些企业安全规范里要求业务必须使用指定库号来隔离，那也属于业务合规驱动。
改databases的时候要注意两点：
- 必须在
redis.conf里改，并重启生效。CONFIG SET databases是不支持的，这个参数不能动态调整，因为Redis启动时就要分配redisDb数组。 - 它只影响新建的Key落在哪个库，不影响已有Key。也就是说，你把
databases从16改成8，原本存在9号库里的数据并不会自动消失，只是现在没法通过SELECT 9访问了，重启后这些库仍然存在，只是不能主动切换进去。如果还配置了持久化，重启后老数据还在，新数据也无法写入9号库，这种不一致状态很坑。
所以，除非有明确需求，别瞎调这个参数。默认16够用，改大了浪费内存（每个库就是一个空的字典结构，但堆在一起也有开销），改小了可能影响依赖多库的旧应用。
4. 是不是越大越好？聊聊“适度”背后的工程哲学
4.1 maxmemory越大，风险越大
可能有人会说：“内存反正便宜，我把maxmemory设大一点，缓存命中率不就高了嘛。”这话听着有道理，但忽略了三个隐性成本：
第一是故障恢复时间。Redis内存越大，启动时加载RDB、或者AOF重放的时间越长。一个10GB的RDB文件，加载可能要几十秒；但一个40GB的RDB，加载时间直接奔着几分钟去了。再加上重启后的缓存预热期，你的缓存命中率会经历一个漫长的低谷，数据库压力会非常大。
第二是内存碎片率和内存效率。当Redis内存使用达到10GB以上，jemalloc分配器的碎片率通常会明显上升。碎片率超过1.5的时候，实际可用容量和maxmemory之间的差值会让你很被动，你需要频繁用MEMORY PURGE或在低峰期重启来回收碎片。
第三是慢查询和大Key的放大效应。内存越大，越容易堆积大Key。而大Key的删除、迁移、序列化、网络传输，都会在主线程上产生毛刺。我见过一个线上事故：一个几十MB的Hash Key，每次HGETALL耗时几十毫秒，由于某个巡检脚本每隔几秒就全量拉取这个Key，直接把Redis主线程拖成了“半瘫痪”状态。
所以maxmemory的设计目标不是“越大越好”，而是“够用且留有余量”。让淘汰策略有活可干，让持久化有空间可要，让故障恢复有边界可控，这才是合理的。
4.2 databases越多，心智负担越重
把话题收回到databases，“越大越好”这个直觉在这里也完全不适用。
一个实例如果开了64个库，你首先面对的是运维复杂度飙升。监控上看INFO keyspace，一长串的db0到db63统计信息，哪个库的Key在涨、哪个库有异常大Key，光靠肉眼看要挤爆眼眶。更麻烦的是，当你需要备份某个库时，redis-cli --rdb只能备份整个实例的内存数据，不能被按照库细分。
其次是脚本和工具链的混乱。你的业务代码如果写死了SELECT 7，另一个团队写了一个清理脚本，默认操作0号库，两边同时跑的时候互不可见，出现“数据怎么又回来了”这种诡异现象。调试的时候，redis-cli连上去默认在0号库，你执行KEYS *发现什么都没看到，以为数据丢了，实际上是找错了库。
最后是分布式环境下的不可移植性。你可以在单机Redis上玩64个库玩得很爽，一旦需要迁到Redis Cluster，全部归零到0号库，意味着你必须重写所有使用SELECT的代码，这种迁移成本几乎是灾难级别的。所以从一开始就避开多库，是给自己未来留条后路。
4.3 面试官真正想听到的是什么
把这个题目放到面试场景里，面试官其实不是想听你背出maxmemory和databases的默认值。他真正想听到的是你如何理解“资源配置”和“容量规划”之间的关系，以及你在实际项目中是否踩过坑、有没有自己的判断标准。
一个让面试官满意的回答，通常会包含这几个层次：
maxmemory的设值逻辑：需要考虑物理内存、数据量预估、持久化fork开销、淘汰策略配合，给出一个具体的计算公式和案例数字。databases的设值逻辑：承认默认16是合理的，但强调生产环境应尽量不用多库或只用一个库，除非有特殊需求或历史包袱。- 对“越大越好”的纠偏：分别说明两者过大会带来什么问题，给出更符合工程经验的“够用 + 留余量”设计。
- 补充性能指标：比如用
INFO memory里的used_memory、mem_fragmentation_ratio来判断是否需要调整；用CONFIG GET maxmemory确认当前设置是否生效。
5. 实操配置清单：照着调就能落地
5.1 单机缓存场景的推荐配置
假设你有一台8GB内存的云主机，主要跑一个日活20万的Web应用，用Redis做缓存、Session、限流：
# redis.conf 关键配置 maxmemory 5gb maxmemory-policy allkeys-lru databases 16 # 保持默认，业务固定用0号库 appendonly yes appendfsync everysec再配合一个内存监控脚本，当used_memory超过maxmemory的80%时报警：
redis-cli INFO memory | grep used_memory:如果发现长期逼近上限，优先检查哪类Key占了大头：
redis-cli --bigkeys这一步能帮你快速定位是缓存Key爆炸，还是某个业务方的集合数据失控。
5.2 高可用/集群场景的推荐配置
如果是部署Redis Cluster，databases必须保持默认16（虽然实际只会用0号库）。每个节点单独设置maxmemory，建议按单节点物理内存的70%规划，并开启maxmemory-policy allkeys-lru。
redis-cli -c -h 10.0.0.2 -p 7001 CONFIG SET maxmemory 6gb redis-cli -c -h 10.0.0.2 -p 7001 CONFIG SET maxmemory-policy allkeys-lruCluster下所有Key都通过CRC16分片到不同的slot，只存在0号库。所以迁移之前，必须先把业务代码里的SELECT命令全部去掉，否则集群模式下直接报错：
ERR SELECT is not allowed in cluster mode
5.3 一个容易忽略的参数：maxmemory-samples
maxmemory-policy配合maxmemory-samples使用，默认值是5。这个参数决定了LRU/LFU近似算法采样多少个Key来淘汰。值越大，淘汰越接近真实LRU，但CPU开销越高。我的实践是：如果Redis实例的QPS很高，建议保持默认5；如果内存淘汰不够精确，导致频繁淘汰掉热点Key，可以把maxmemory-samples调到10。
这个参数三言两语讲不清楚，但它对“内存上限设计”的体验影响很大。maxmemory设得太小，淘汰频率高，LRU采样不够精准时，很容易误伤热点Key，缓存命中率下降得很厉害。设得太大，又白白牺牲了淘汰的精准度。所以它是一个需要根据实际业务观察调整的参数。
5.4 动态修改的兜底手段
不要忘了Redis几乎所有内存相关参数都支持运行时动态修改，这意味着你不需要为了一次配置失误就大动干戈重启。
# 临时调小内存上限（注意单位是字节） redis-cli CONFIG SET maxmemory 4gb # 查看当前生效配置 redis-cli CONFIG GET maxmemory redis-cli CONFIG GET maxmemory-policy生产环境建议大家把redis.conf里改好并重启，但用CONFIG SET作为一个应急兜底手段是非常实用的。比如线上内存突然涨了30%，你不可能马上重启，这时候CONFIG SET maxmemory就是最快的止血方案。
6. 常见问题与排查技巧实录
6.1 设置了maxmemory，为什么写入还在涨？
这个问题我遇到过好多次。排查下来最常见的三种原因：
- Redis 5.0以下版本的已知限制，
maxmemory不限制主从复制的backlog，如果从库同步跟不上，主库的client-output-buffer-limit会暂存大量写命令，这部分内存不计入used_memory。 - 大量
EXPIRE失效的Key尚未被真正回收，过期Key的惰性删除和定时删除都需要时间，如果流量突然冲高，有可能短暂出现内存超限。 CONFIG SET maxmemory设置了单位错误，Redis在CONFIG SET时接受字节数，不接受1gb这种写法。你一写1gb，其实设置成了1字节，等于没设。
所以调整完了记得执行CONFIG GET maxmemory，确认拿回来的是数字还是零。如果是0，说明设置没成功，重新按字节设置：
redis-cli CONFIG SET maxmemory 53687091206.2 设置了allkeys-lru，但Redis还是变慢了
这个现象通常有几个叠加原因。
淘汰本身是需要CPU的，Redis虽然是单线程，但LRU采样的复杂度不高，一般不会成为瓶颈。真正的坑在于：被淘汰的大Key在释放内存时如果太大，会阻塞主线程。比如一个100MB的List，当它被淘汰时，Redis需要遍历链表、释放每个节点，这个操作可能让主线程卡顿几十毫秒。
解决办法有两个方向。一是尽量压缩集合类Key的体积，不用大List、大Hash存海量数据，可以拆分成多个小Key。二是引入unlink命令，它实现了异步释放，当你要删大Key的时候，用UNLINK key代替DEL key，主线程不会卡住。
6.3 databases调整后，旧数据“不见了”
曾经有一个项目，运维在迁移时把databases从16改成了4，结果应用连上Redis之后发现大量Key找不到。原因就是老数据还留在5~15号库，SELECT切不过去了，而应用没有感知到切换错误，一直在0号库操作。
这类问题一旦发生，修复起来很麻烦。你只能临时把databases改回16，然后逐个把那些“被隐藏”的库里的数据迁出来。所以我强烈建议：一旦开始使用多库，就要在所有脚本和配置里明确库号，不要依赖默认值，迁移时先确认好数据分布再动手。
6.4 从monitor看：maxmemory和databases都是“预设”，真正的重点是数据形态
如果你用redis-cli --monitor观察过生产环境的命令流，你会发现在实际运行中，绝大多数命令都集中在0号库，且写入和读取分布不均。这恰恰说明，与其纠结databases设成多少，不如把精力放在Key的设计、淘汰策略的选型、以及maxmemory的合理水位上。
我见过最稳的团队是怎么做的：
databases常年保持16默认值，所有连接串里显式加/0或?database=0。- 每个Redis实例配一个单独的
maxmemory，按物理内存的70%设置，并挂上监控和告警。 - 每周跑一次
redis-cli --bigkeys和redis-cli --memkeys，把大Key消灭在萌芽状态。 - 做了缓存预热脚本并定期演练，确保大内存实例重启后能快速恢复命中率。
这些做法听起来不酷，但确实是避免线上事故最有效的组合拳。
一点个人的体会
做后台这么久，配置过从几百MB的小缓存实例到几十GB的大内存集群，踩过的坑比看过的文档多。maxmemory也好，databases也罢，本质都不是“越大越好”的选择题，而是一道“需求边界”的计算题。你得先搞清楚业务到底需要多少数据常驻、允许丢多少、淘汰策略怎么兜底、持久化要占用多少临时内存，这些算清楚了，配置自然就出来了。
面试官如果追着问这两个参数，其实是想看你在设计系统时有没有“容量规划”的意识和“留有余量”的工程直觉。用100%的硬件跑99%的负载，通常都会在某个凌晨三点爆给你看。留出20%的缓冲，给Redis一点喘息的空间，这才是和内存友好相处的方式。
