1.1、什么是数据库？
提起数据库的概念之前，因该先要去明白什么是数据？
简单来说，数据就是记录客观事物属性、状态或关系的符号化、数字化或者结构化的表示。例如：远古时期的壁画记载、近现代的文字、图像、视频、声音等。而这些数据都具备一些特定的结构或者表现形式：
• 结构化数据：Excel表格中的信息或者二维表格中存储的数据
• 半结构化数据：JSON格式的日志文件
• 非结构化数据：图片等无结构数据
• 实时流数据：智能设备采集的实时数据，例如智能手环采集的心率变化曲线
数据就是未经加工的原材料。例如：温度传感器显示25℃，如果不经过上下文交互处理成信息，并不具备直接传递意义的功能，只有经过解释加工之后，才具备传递作用。所以说：数据是信息的载体，而信息是数据的语义化解释。
明白了什么是数据之后，再回过头来想一个问题？数据是怎么样被管理的呢？这个时候就需要回顾一下数据库技术演进的几个主要阶段了：
人工管理层次数据库系统网状数据库系统关系型数据库系统NoSQLNewSQL
• 人工管理阶段：信息被人工通过记录在信息载体（早期的书籍、壁画等）上的方式进行存储，此时并没有计算机系统的诞生
• 层次数据库系统：采用树状结构组织数据，除根节点外，每个记录有且只有一个父节点，形成严格的双亲子女关系。比如：家族族谱就是典型的层次结构。典型实现就是IBM的IMS（Information Management System），是最早大型数据库系统之一。很明显这种结构并不能满足处理多对多的关系，并不适用于复杂的交互场景。
• 网状数据库系统：以有向图为基础，允许结点存在多个上级或下级结点，可定义复合链表达多对多联系。例如，一个员工可能同时属于不同部门，这种交叉关联无法用层次模型表示。而网状结构却能更直接的描述现实世界的多对多关系，但是由于其结构复杂导致查询和维护难度很高（设想一下，通过网状结构去维护学生与课程的关系，如果修改了某个节点的值的时候，必须同步更新所有的相关链路，这只是两张表的关系，更多表的关联呢？），逐渐被淘汰。
• 关系型数据库系统：用二维表结构存储数据，通过主键与外键实现表间关联。例如，用户订单表中的用户ID作为外键关联到用户表的主键。支持SQL语言进行标准化操作；强制ACID事务特性保证数据一致性；提供索引优化、视图管理和存储过程等功能。代表产品就是MySQL、Oracle等。关系型数据库的出现，解决了早期数据库的局限性，基本满足了企业应用的使用。
• NoSQL：随着信息大爆炸时代的到来，关系型数据库逐渐不能满足数据类型的多样化要求，NoSQL的出现就是为了应对传统关系型数据库在特定场景下的局限性。NoSQL（Not Only SQL的缩写）是非关系型数据库的统称，打破固定表结构限制，适应海量非结构化数据处理需求。其典型实现就是Redis、MongoDB。
• NewSQL：结合了关系型数据库的ACID特性与NoSQL的水平扩展能力，来平衡传统事务支持和大数据性能需求。适应目前Ai时代和云原生时代的技术融合趋势。
了解了数据库技术的演进过程，回过头来再看问题：什么是数据库？
目前比较通俗的定义是：数据库是一个长期存储在计算内的、有组织、可共享的、能够统一管理的数据集合。通俗的说，数据库就是数据的集合体，是由这些数据集合体构成有序的集合后，存放在结构化的数据表中。而这些数据表就是数据的载体，通过这些载体之间的关联来反映描述事物之间的本质联系。
总结：一个新技术的诞生往往是旧技术的突破，从数据库技术的演变历史就可以看出来。技术在不停的更新迭代，为了满足不断出现的新的业务需求，就需要不断的去突破目前的技术壁垒，来应对日益增长的复杂需求。
1.2、为什么需要Redis?
回答这个问题之前，我们应该先要弄明白这几个问题：
• 什么是Redis?
• Redis有哪些优点？
• Redis的出现帮助我们解决了什么问题？
1.2.1、什么是Redis?
从上文中的介绍我们可以知道，Redis隶属于非关系型数据库系统，所以说它并不是存储标准的关系型数据表的，而是根据其支持的数据结构类型来进行存储特定结构的数据。对于Redis的概念描述如下：
Redis（全称 Remote Dictionary Server）是一个开源的、基于内存的高性能键值对（Key-Value）存储系统，通常被用作数据库、缓存或消息中间件。它支持丰富的数据结构（如字符串、哈希表、列表、集合、有序集合、位图、超文本等），并内置持久化机制和高可用性功能。由于数据主要存放在内存中，Redis具有极高的读写速度，适用于需要快速响应的场景。
1.2.2、Redis有哪些优点？
接下来让我们了解一下Redis有哪些优点呢？
• 极高性能：上面的概念中提到这句话：基于内存的高性能键值对（Key-Value）存储系统，由于其所有操作都在内存中完成，延迟低且单线程架构避免了上下文切换开销，最新版8.2单个实例的处理能力甚至突破了 每秒 100 万次操作。
• 灵活的数据结构支持：提供多种基础类型：字符串（String）、哈希（Hash）、列表（List）、集合（Set）、有序集合（ZSet/Sorted Set）。开发者可以根据业务需求选择合适的结构，简化复杂逻辑实现。例如，用有序集合实现排行榜功能。
• 简单易用的API：通过命令行或客户端库调用直观的命令即可完成操作，学习成本低且开发效率高。
• 持久化机制保障安全性：支持两种持久化方式：RDB（快照）和AOF（日志追加），可在重启时恢复数据，避免因断电导致丢失重要信息。
• 原子性操作与事务支持：单个命令是原子性的，保证执行过程中不被中断；还支持Multi/Exec实现事务功能，确保多个操作要么全部成功，要么全部回滚。
• 发布订阅模式（Pub/Sub）：允许客户端订阅特定频道的消息推送，常用于实时通知系统（如聊天室、事件广播）。
• 分布式特性扩展能力强：原生支持主从复制、哨兵模式实现故障自动转移，结合分片技术可横向扩展以应对大规模数据场景。同时支持集群部署，实现业务连续性保障。
• 跨语言兼容性好：几乎所有主流编程语言都有对应的客户端驱动，方便集成到现有项目中。
总结：Redis从高可用、故障自愈、数据安全性（持久化）、事务、兼容性等多角度凭借其高速、灵活、易扩展的特性，完美解决了单机时代的容量瓶颈和单点故障问题，同时保持了Redis原有的高性能特性。
1.2.3、Redis的出现帮助我们解决了什么问题？
根据以上的描述回过头想一下，Redis可以帮助我们解决什么问题呢？为什么必须用Redis而不是传统的关系型数据库来实现呢？
这里我们通过生活中很常见的几个场景去理解：
场景一：双11京东秒杀活动时，单个商品页面可能在瞬间涌入大量的请求，如果这个商品信息没有在Redis中进行缓存，而是通过直接访问数据库的形式进行获取，因为关系型数据库依赖于磁盘的I/O，很可能无法承受如此高的并发写入负载，那么这个时候数据库服务器就会因为过载而导致宕机，进而导致服务的奔溃。而Redis作为内存数据库，读写速度极快，能快速响应高并发请求，减轻后端压力，就能很大程度的避免这种情况的出现。
场景二：多个服务端实例同时处理同一订单可能造成数据冲突（如重复扣款），基于数据库的悲观锁或乐观锁会因网络延迟导致性能瓶颈，利用Redis的SETNX命令实现分布式锁，确保同一时间只有一个服务能操作共享资源。例如，支付系统通过锁机制保证订单状态的唯一性。
场景三：针对直播打赏榜单上面的TOP10粉丝实时排行，传统关系型数据库SQL聚合查询和排序在大数据量的情况下性能差，难以满足秒级刷新需求。利用Redis的Sorted Set结构，以用户ID为成员、打赏金额为分数，实时维护排名。每次新打赏时更新分数即可快速获取TOP10列表。
场景四：历史发布的秒杀商品信息，一般是通过url/{id}(商品ID)的形式进行访问的，如果这个商品因为错误上架后下架了，但是原来的链接信息已经被公开并记录，此时再次有大量请求去访问这个商品信息时，如果后端业务中没有做针对性的处理，就会有大量的无效请求直接打到数据库导致数据库服务器因压力过载而宕机。Redis通过布隆过滤器拦截不存在的Key，或设置空对象缓存避免重复查询数据库；同时采用随机过期策略防止集中失效引发雪崩。
通过这几个场景，我们可以看到Redis的强悍之处：
• 高性能读写需求
• 分布式锁与资源竞争控制
• 实时排行榜统计
• 缓存穿透与雪崩防护
• …
同类型的问题还有很多种，不同的应用场景有不同的解决方案，这里从不同维度对比一下关系型数据库的局限性和Redis的优势，同时也回答为什么必须用Redis而不是用关系型数据库去实现？
维度关系型数据库局限性Redis优势
性能瓶颈
磁盘I/O限制导致读写延迟高；复杂事务占用大量锁资源
纯内存操作，单线程架构避免上下文切换开销；原子性命令保证高效并发控制
扩展性差
垂直扩展依赖高端硬件，成本高昂；横向分库分表引入跨节点JOIN复杂度
水平扩展简单，通过分片机制轻松应对PB级数据；无Schema约束支持灵活数据结构
事务一致性过强
强制ACID特性增加冗余开销，弱一致性场景下成为负担
弱化事务模型，支持最终一致性，适合互联网场景下的可用性优先原则
非结构化数据处理弱
固定表结构难以适应动态业务需求；JSON/BSON等半结构化数据存储效率低
原生支持多种数据类型（String/Hash/List等），天然适配NoSQL场景
运维复杂度高
备份恢复慢；DDL变更需停机维护
持久化机制（RDB/AOF）保障数据安全；在线扩容无需停服
特定功能缺失
缺乏原生分布式锁、位图统计、地理空间索引等功能
内置丰富特性满足缓存、队列、计数器等多种场景需求
总结：Redis通过其高性能、灵活性和丰富的原生功能，解决了传统关系型数据库在互联网场景下的诸多痛点。它并非替代关系型数据库，而是针对特定场景（如缓存、队列、计数器等）提供更优解决方案。选择Redis的核心考量在于：是否需要低延迟、高并发的支持？是否能接受弱化的事务一致性？以及是否需要利用其独特的数据结构和算法优化能力？
上一条：Windows系统Redis安装教程
下一条：Redis是什么
沪公网安备31011302006932号