1 NoSQL 和 Redis 特性

本节对应 PDF 中的“NoSQL 和 Redis 特性”部分， 重点介绍 NoSQL 的背景与分类、CAP 理论，以及 Redis 的基本 概念和主要特性。

---

1.1 NoSQL 概述

1.1.1 什么是 NoSQL

从数据模型上看，常见数据库大致可以分为两类：

• 关系型数据库（RDBMS）：如 MySQL、Oracle、SQL Server、DB2；
  • 以“表 / 行 / 列”为核心抽象；
  • 使用 SQL 进行查询；
  • 数据结构化程度高，约束完善，事务能力强。
• NoSQL 数据库（Not Only SQL）：
  • 并不是“不要 SQL”，而是“并不只有 SQL”；
  • 在不适合用关系型数据库的场景，引入更合适的存储模型；
  • 统称一系列“非关系型、可水平扩展”的数据库系统。

典型特点：

• 模式灵活或无模式（schema-less）；
• 易于水平扩展，适合超大规模数据；
• 通常在一定程度上弱化事务与强一致性，换取可用性与扩展性。

1.1.2 NoSQL 的起源与发展动机

根据 PDF 内容，NoSQL 概念经历了几个阶段：

• 1998 年：Carlo Strozzi 首次使用 “NoSQL” 一词，描述一个不提供 SQL 功能的轻量级关系型数据库；
• 2009 年：Last.fm 的 Johan Oskarsson 发起关于分布式开源数据库的 讨论，Rackspace 的 Eric Evans 再次提出 NoSQL 概念；
• 同年在亚特兰大举行的 “no:sql(east)” 会议，将 NoSQL 明确与 “非关系型、分布式、不完全满足 ACID 的数据库设计模式”绑定。

推动 NoSQL 出现的根本原因在于：

• 互联网应用产生了海量用户数据、日志数据、行为数据；
• 单机关系型数据库在存储容量与性能扩展上出现瓶颈；
• 大量场景并不需要传统 RDBMS 提供的全部能力（例如复杂事务）， 可以用更简单、更易扩展的系统来满足需求。

1.1.3 为什么需要 NoSQL

相比传统关系型数据库，NoSQL 在以下方面更有优势：

• 扩展性：
  • 更容易做水平扩展（增加节点即可扩容）；
  • 通常内置分片与复制机制。
• 性能：
  • 为特定访问模式做了优化，例如键值访问；
  • 多数实现以内存为主，延迟极低。
• 开发灵活度：
  • 模式更宽松，适合快速迭代的业务；
  • 适合存储半结构化或非结构化数据。

但 NoSQL 并不是用来“替代”关系型数据库，而是作为补充：

• 业务核心数据通常仍保存在 RDBMS 中；
• NoSQL 适合作为缓存层、日志/行为数据存储、会话存储等。

---

1.2 NoSQL 分类与 RDBMS 对比

1.2.1 常见 NoSQL 类型

PDF 中将 NoSQL 系统大致分为几类（这里只做归纳）：

类型	代表产品	主要特点
列存储	HBase、Cassandra、Hypertable	按列存储，适合结构化/半结构化数据
文档存储	MongoDB、CouchDB	类 JSON 文档，可按字段建索引
键值存储	Redis、Memcached、Tokyo Cabinet 等	通过 key 快速定位 value
图数据库	Neo4j、FlockDB	适合存储复杂图结构及关系
对象数据库	db4o、Versant	以对象形式存取数据
XML 数据库	Berkeley DB XML、BaseX	针对 XML 做存储与查询优化

Redis 属于“键值存储”这一大类，但相比传统 KV 系统，它的 数据结构更丰富、能力更强。

1.2.2 RDBMS 与 NoSQL 对比

可以从以下几个维度理解两者差异：

• 数据模型：
  • RDBMS：强约束的表结构，适合关系清晰、结构稳定的业务；
  • NoSQL：模型灵活，适合结构变化快、字段不固定的场景。
• 查询语言：
  • RDBMS：标准 SQL，声明式查询能力强；
  • NoSQL：通常不存在统一的“查询语言”，更多依赖 API / 命令。
• 事务与一致性：
  • RDBMS：强调 ACID 特性，单机强一致；
  • NoSQL：更多强调可用性和扩展性，常采用最终一致或弱一致。
• 扩展方式：
  • RDBMS：纵向扩展为主（Scale Up），横向分片复杂；
  • NoSQL：天然支持横向扩展（Scale Out），分布式设计更直接。

简单理解：

• 对 ACID、复杂查询和报表依赖强 → 优先 RDBMS；
• 对海量数据、高并发、灵活结构要求高 → 适当引入 NoSQL。

---

1.3 CAP 定理与 NoSQL

PDF 对 CAP 定理进行了详细说明，这里做简要总结：

在分布式系统中，无法同时完全满足以下三个属性：

• C（Consistency，一致性）：所有节点在同一时间看到的数据一致；
• A（Availability，可用性）：每个请求都能在有限时间内获得响应；
• P（Partition tolerance，分区容忍性）：系统在出现网络分区时仍能继续提供服务。

由于现实中网络分区不可避免，实际系统都必须在 C 与 A 之间进行取舍：

• CP 系统：
  • 强调一致性和分区容错；
  • 在网络异常时宁可拒绝部分请求（降低可用性），也要保证数据一致；
  • 例如：ZooKeeper、Etcd 等。
• AP 系统：
  • 强调可用性和分区容错；
  • 允许短时间数据不一致，通常保证“最终一致性”；
  • 例如：许多采用异步复制机制的键值存储、主从复制架构等。

NoSQL 产品通常是围绕 CAP 的取舍做出的不同实现，Redis 本身也 需要通过部署架构（主从、哨兵、集群等）来体现具体的 CAP 选择。

---

1.4 Redis 简介

1.4.1 Redis 是什么

根据 PDF 中的描述，Redis 具有以下特征：

• 名称：Redis = Remote Dictionary Server（远程字典服务）；
• 类型：高性能 NoSQL 键值数据库；
• 语言：使用 ANSI C 编写；
• 协议：遵循 BSD / MIT 等开源协议；
• 作者：Salvatore Sanfilippo（常被称为 antirez），约在 2009 年发布；
• 赞助：先后由 VMware、Pivotal 等公司支持开发；
• 用户：国内外大量互联网公司广泛使用（阿里、腾讯、百度、京东、微博、 GitHub、Twitter 等）。

Redis 在很大程度上弥补了传统 key/value 存储（例如 Memcached）在 数据结构、持久化、高可用方面的不足，常作为关系数据库的有力补充。

1.4.2 Redis 特性概览

综合 PDF 的内容，可以概括 Redis 的主要特点：

• 速度快：
  • 以内存为主，单机可轻松达到每秒数万到十万级别的 QPS；
  • 使用高效的事件驱动模型和 I/O 多路复用（如 epoll）。
• 实现简单：
  • 单机核心代码量相对较小，结构清晰；
  • 单线程模型降低并发编程复杂度（6.0 之前，核心请求处理逻辑为单线程）。
• 数据结构丰富：
  • 字符串、列表、集合、有序集合、哈希、位图、HyperLogLog、Streams 等；
  • 可以直接用高层结构解决业务问题，而不必自行编码组合结构。
• 功能完善：
  • 支持发布/订阅、Lua 脚本、事务（MULTI/EXEC）、pipeline 等；
  • 支持键过期、键空间通知等高级功能。
• 多语言客户端：
  • 几乎所有主流语言都有完善的 Redis 客户端库；
• 高可用与分布式能力：
  • 内置主从复制（Replication）；
  • 提供哨兵（Sentinel）实现高可用；
  • 提供 Redis Cluster，实现分布式分片与故障转移。

---

1.5 Redis 与 Memcached 对比

PDF 中还对 Redis 与 Memcached 做了详细对比，可总结为：

• 数据结构支持：

  • Memcached：几乎只支持简单字符串键值；
  • Redis：支持多种数据结构，更适合复杂业务场景。

• 持久化能力：

  • Memcached：纯内存，无持久化；
  • Redis：支持 RDB 快照、AOF 追加日志等多种持久化方案。

• 高可用与集群：

  • Memcached：主要依赖客户端分片，缺乏官方高可用方案；
  • Redis：提供主从、哨兵、集群等官方方案。

• 内存管理与功能：

  • Memcached：预分配内存池，适合大量简单 KV；
  • Redis：支持更复杂的数据结构和脚本、事务等功能，对内存碎片管理 也有自己的策略。

• 适用场景：

  • Redis：
    • 复杂数据结构缓存；
    • 需要持久化和高可用的缓存/状态服务；
    • 排行榜、计数器、分布式锁、会话等。
  • Memcached：
    • 简单 KV 缓存；
    • 单值较小、访问频繁且不需要持久化的场景。

总体来说，在新项目中，Redis 通常是更通用、更灵活的选择，而 Memcached 仍可在极简 KV、高并发纯缓存场景中发挥作用。

---

本节对 PDF 中“NoSQL 和 Redis 特性”部分做了结构化整理，后续 文档将分别围绕“Redis 部署”“Redis 使用”“Redis 数据类型”等内容 展开更细致的说明。