Redis 的故事：从一次“日志卡顿”，到实时数据结构服务器
2009 年，意大利工程师 Salvatore Sanfilippo（网名 antirez）在给自家创业项目做实时 Web 日志分析（LLOOGG）时，发现传统数据库在这一类高频、低延迟的写读模式下很难“跑顺”。他用 Tcl 写了个原型，随后改写成 C，把“键值 + 数据结构”的思路做成了一个小服务，并把它开源，命名为 REmote DIctionary Server——Redis。很快，GitHub、Instagram 等早期团队开始使用它，社区热度一路上升。
它是怎么长大的？
Redis 不是“把数据放内存里”的简单 KV，而是数据结构服务器：字符串、列表、集合、有序集合、哈希、位图、HyperLogLog、地理空间索引、以及后来的 Streams 等，每一种都对应一套原子命令与操作语义。2018 年，Redis 5.0 正式引入 Streams，为事件日志/消费分组提供了一等数据类型。
为了在生产环境可靠运行，Redis 又补上了三块“地基”：
-
持久化：RDB 快照与 AOF 追加日志两种模式（可按需取舍）。
-
高可用：Sentinel 监控/选主与故障转移。
-
可水平扩展：Cluster 基于 16384 个哈希槽的分片机制。
近年生态也在演化：2024 年 Redis 更改为 RSAL/SSPL 双许可，引发社区在 Linux 基金会下创建 Valkey 分叉；2025 年 Redis 8 增加 AGPLv3 选项并继续演进。无论选择哪条发行线，核心理念仍是“以数据结构为中心的实时系统”。(Redis)
人们为什么爱用 Redis？
1）快：内存读写 + 简洁事件循环模型，做对了“少而精”的事；
2) 好用：高层次的数据结构就是业务原语（排行榜=有序集合、计数=原子自增…）；
3) 简单可靠：内置过期/TTL、事务（MULTI/EXEC）、Lua 原子脚本、复制/哨兵/集群这些“刚需”能力开箱即用；
4) 生态广：几乎所有语言/云厂商都有成熟客户端与托管服务。
除了“做缓存”，还能干什么？
以下都是把数据结构当“工具箱”的典型场景：
-
会话与登录状态：
HASH/STRING+EXPIRE管理用户 Session，轻松做滑动过期。 -
限流/防刷：
INCR+EXPIRE做固定窗口；需要更强一致性可用 Lua 脚本或滑动窗口；还可用 Streams 构建令牌流。 -
消息队列与事件流：轻量队列可用
LIST/BRPOP；需要消费组、重试与确认就上 Streams + XGROUP/XREADGROUP。 -
发布/订阅：实时推送、房间广播；语义为 at-most-once（最多一次），需要更强投递保证时用 Streams。
-
排行榜 / 计分板 / Feed 排序：
ZSET（有序集合）天然支持按分数区间/名次查询。 -
地理位置服务：
GEOADD/GEOSEARCH做附近检索、半径查询、距离计算。 -
去重与 UV 估计：
HyperLogLog几 KB 内存估算独立访客数等。 -
海量布尔状态：位图跟踪活跃用户、签到、特征位。
-
分布式锁/协调：单实例
SET NX PX或多副本 Redlock（请结合场景权衡一致性与可用性）。
想把 Redis 用成“多模型实时数据库”？有 Redis Stack/模块：
RedisJSON 做文档存储；RediSearch 做全文/向量检索；RedisTimeSeries 做时序；RedisBloom 提供 Bloom/Cuckoo/Top-K/Count-Min 等概率结构。(Redis)
Redis 的“工程学取舍”
-
内存优先 + 可选持久化：RDB 快照适合快速恢复，AOF 注重更高耐久；业务要点是先确定可接受的数据丢失窗口，再选策略与 fsync 频率。
-
高可用路线：单机 + Sentinel（自动故障转移）→ Cluster 分片（16384 槽，客户端感知路由）。
-
一致性与幂等：Pub/Sub 是 at-most-once；要“至少一次/可重放”，请选 Streams + 消费组并配合业务幂等。
