不少项目在引入Redis之后，开始把它当成主数据库来存放业务数据，理由是Redis也属于NoSQL，而且读写速度很快。但速度快不等于能替代所有存储职责。把订单、用户资料、权限关系全部塞进Redis，通常会遇到三个问题：复杂查询无法下推、持久化策略与数据库语义不匹配、内存成本随数据量线性上升。选型时需要把Redis放回NoSQL大家庭中，与MongoDB、Cassandra、Elasticsearch、Neo4j等系统做具体比较。
下面从数据模型、查询能力、持久化一致性、扩展成本四个维度展开，目标是给出一个可执行的选型清单，而不是简单地说哪个数据库更好。
一、数据模型差异：Redis的数据结构不等于灵活的数据关系
Redis提供String、Hash、List、Set、Sorted Set、Stream等丰富结构，这让很多人产生一种错觉，认为它也具备文档数据库或关系数据库的建模能力。实际上，Redis的结构是围绕键和值的操作原语设计的，键与键之间没有外键约束，值内部字段也不支持类似二级索引的查询。比如把用户信息存在Hash中，键是user:1001，字段是name、age、city，想查询所有age大于30且city为北京的用户，Redis并没有内置语法直接完成。
要硬做只能手工维护索引。以Sorted Set为例，把用户年龄作为score写入user:age索引，再把城市作为另一个Set，然后在应用层做交集、过滤和排序。这种方式虽然可行，但会引入索引与主数据之间的不一致风险：一旦更新用户年龄时忘记同步索引，查询结果就错了。相比之下，MongoDB文档模型可以天然嵌套数组和子文档，并在任意字段上建立索引，查询逻辑由数据库承担。
下面两段代码展示同一需求在Redis与MongoDB中的实现差异。
# Redis手工维护年龄索引的简化示例 ZADD user:age 30 user:1001 ZADD user:age 42 user:1002 SADD city:beijing user:1001 user:1003 ZRANGEBYSCORE user:age 30 100 # 应用层再与 city:beijing 求交集，非常容易出错
// MongoDB直接按字段过滤并排序
db.users.find({
"age": { "$gt": 30 },
"city": "beijing"
}).sort({ "age": -1 })
这个差异的本质是：Redis优化的是已知键的快速访问和特定数据结构操作，而MongoDB、Cassandra这类数据库优化的是按条件检索数据。选型前应先判断业务查询模式是键值查找为主，还是多维条件过滤为主。
二、查询能力与索引策略：键值直读和条件检索是两类负载
Redis的单个键读取复杂度通常为O(1)，在缓存场景中优势明显。但它的键遍历命令SCAN并不适合在线查询：SCAN基于游标分批返回键，只能做模糊键扫描，无法按照值内容过滤，也不保证返回结果的先后顺序。HSCAN和SSCAN虽然可以遍历Hash字段或Set成员，同样没有查询优化器，只适合运维排查或小规模遍历。
一旦业务里出现常见的列表页、搜索框、报表统计，Redis的短板就会暴露。MongoDB的聚合管道可以在服务端完成过滤、分组、投影、排序等一连串操作；Elasticsearch基于倒排索引，适合全文搜索和模糊匹配；Cassandra CQL可以在主键上做高效的范围扫描，但要提前设计好分区键。也就是说，需要复杂查询的主数据系统，不应该只依赖Redis，而是让它作为前置缓存。
例如一个电商订单列表接口，用户可能按状态、金额区间、创建时间筛选，并需要分页。MongoDB可以用聚合管道一次完成，而Redis如果存储订单，只能为每个筛选维度手动建立Sorted Set或Set，查询组合一多就会出现笛卡尔积式维护成本。
// MongoDB聚合：按状态和金额统计近30天订单
db.orders.aggregate([
{ "$match": {
"status": "paid",
"amount": { "$gte": 100 },
"createdAt": { "$gte": new Date(Date.now() - 30 * 24 * 60 * 60 * 1000) }
}},
{ "$group": { "_id": "$status", "total": { "$sum": "$amount" } } },
{ "$sort": { "total": -1 } }
])
结论很清楚：如果数据需要频繁参与过滤、排序、聚合、搜索，主存储应该选MongoDB、Elasticsearch或Cassandra，Redis可以把查询结果缓存几秒到几分钟，但不要充当查询引擎。
三、持久化与一致性机制：缓存属性不能忽略
Redis被归为NoSQL数据库，但它的设计重心是内存数据结构服务，持久化更多是为了重启后恢复数据，而不是提供像数据库那样的持久性保证。RDB快照会按周期生成文件，AOF日志默认的appendfsync everysec策略每秒同步一次，也就是说如果机器突然断电，最多可能丢失最近1秒的写入。即使把appendfsync改成always，每次写操作都同步到磁盘，写入吞吐通常会大幅下降，不适合高并发写场景。
此外，Redis主从复制是异步的。主节点写入后立即返回客户端，从节点可能还没有收到数据；当主节点宕机，哨兵或集群提升从节点时，已经返回成功的那部分写入可能丢失。对于缓存来说这通常可以接受，但对于订单、支付、账户余额这类核心数据，就不能只依赖Redis。MongoDB副本集可以通过写关注级别writeConcern: majority让写入在多数节点确认后才返回；Cassandra则能按操作指定一致性级别，例如QUORUM。
# redis.conf 中两种AOF同步策略 appendfsync everysec # 每秒同步，性能好，可能丢1秒数据 # appendfsync always # 每次同步，更安全但吞吐下降明显
Redis的强项在于单线程命令执行带来的原子性。单个命令如INCR、HSET不会被打断，借助Lua脚本还能把多个命令打包成原子操作，适合秒杀库存扣减、限流计数等场景。但这个原子性只覆盖单实例内的脚本执行，不涉及跨节点分布式事务。选型时如果业务需要跨多行、多集合的ACID事务，更应该考虑其他数据库，Redis只承担高风险并发操作。
四、扩展方式与成本：内存容量不是无限的
Redis的所有数据都放在内存里，这是它性能极高的根本原因，也是它不适合海量冷数据的原因。假设需要存储2TB的用户行为日志，按每GB内存成本远高于磁盘来算，Redis集群的硬件投入会非常夸张。即使使用Redis Cluster把数据分散到多个节点，每个节点仍然要承担自己那份数据的内存和备份，而且跨slot的多键操作、Lua脚本访问不同slot键都会受到限制。
相比之下，MongoDB分片将数据按片键分布到多个副本集，比较适合文档数据水平扩展；Cassandra采用无中心节点架构，写入吞吐可以随节点增加而平滑提升。Elasticsearch分片适合海量日志与搜索，但维护成本不低。表格对比了几个系统的差异。
| 系统 | 数据模型 | 优势场景 | 拓展方式 | 一致性特点 |
|---|---|---|---|---|
| Redis | 键值/数据结构 | 缓存、计数器、排行榜、会话、分布式锁 | Cluster分片，内存受限 | 异步复制，可丢少量数据 |
| MongoDB | 文档 | 通用业务数据、复杂查询、聚合 | 分片副本集 | 多数写可强一致 |
| Cassandra | 宽列/列族 | 海量写入、时序数据、跨机房 | 无中心线性扩展 | 可调一致性 |
| Elasticsearch | 倒排索引/文档 | 全文搜索、日志分析 | 分片副本 | 近实时、最终一致 |
组合方案远比二选一更贴近实际。一个典型架构是：Redis保存会话、验证码、实时排行榜和热点接口缓存；MongoDB保存用户资料、文章、订单等业务主数据；Elasticsearch负责站内搜索和日志检索；Cassandra承接海量事件写入或时序数据。这样每一层都使用最适合自己工作负载的系统，Redis也不再被强迫做它不擅长的事。
最终选型可以按三个问题做判断：数据是否需要长期保存且不允许丢失？查询模式是键值查找还是复杂条件过滤？数据量和写入吞吐是否超出单机内存和异步复制能承受的范围？把这三个问题回答清楚，Redis与NoSQL数据库的边界自然就清晰了。