NoSQL 数据库 Redis

NoSQL 和 Redis 特性

NoSQL 数据库基础

数据库主要分为两大类：关系型数据库与 NoSQL 数据库

关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库

NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候可以考虑使用更加合适的数据存储。NoSQL 是对不同于传统的关系型数据库的数据库管理系统的统称

NoSQL 的 RDBMS 比较

关系型数据库管理系统（RDBMS）和NoSQL数据库各有优缺点，适用于不同的应用场景。以下是它们在几个关键方面的对比

数据模型

RDBMS

使用表格来表示数据，具有严格的模式（schema）
表与表之间通过外键建立关系
适合结构化数据，适用于事务处理和关系密集型的应用

NoSQL

使用多种数据模型，包括文档、键值对、列存储和图
没有固定的模式，数据模型更加灵活
适合半结构化和非结构化数据，适用于数据结构频繁变化的应用

查询语言

RDBMS

使用结构化查询语言（SQL）进行数据查询和管理
SQL标准化程度高，易于学习和使用，拥有丰富的查询功能

NoSQL

不使用标准的SQL，各种NoSQL数据库有自己的查询语言或API
查询功能因数据库类型不同而异，灵活性高但学习曲线较陡

可扩展性

RDBMS

通常是垂直扩展（通过增加单个服务器的资源来提升性能）
水平扩展（通过增加更多的服务器来提升性能）比较困难

NoSQL

设计为水平扩展，可以通过增加更多的服务器来处理更多的数据和请求
非常适合大规模分布式系统

一致性和事务

RDBMS

遵循ACID（原子性、一致性、隔离性、持久性）原则，确保数据的一致性和可靠性
适合需要强一致性和复杂事务的应用

NoSQL

更强调CAP定理（一致性、可用性、分区容忍性）中的可用性和分区容忍性
通常支持最终一致性，但也有一些NoSQL数据库（如MongoDB）提供事务支持

性能

RDBMS

在处理复杂查询和事务时性能较好
适合读写操作较少但查询复杂度高的应用

NoSQL

在读写操作频繁、需要高吞吐量和低延迟的场景中表现优越
适合需要快速读写、海量数据处理的应用

数据完整性

RDBMS

通过外键、唯一性约束等机制确保数据完整性
更适合需要严格数据完整性和约束的应用

NoSQL

数据完整性主要由应用程序层来管理
更灵活，但数据一致性和完整性需要更小心地处理

典型应用场景

RDBMS

金融系统、电子商务系统、企业资源计划（ERP）系统、人力资源管理（HRM）系统等需要强一致性和复杂事务的应用

NoSQL

社交网络、内容管理系统（CMS）、物联网（IoT）、实时数据处理、大数据分析等需要高扩展性和灵活数据模型的应用

总结

RDBMS

优点：数据一致性强、事务支持、标准化查询语言、数据完整性好
缺点：扩展性有限、灵活性较差、在大规模数据处理中的性能瓶颈

NoSQL

优点：高扩展性、灵活的数据模型、高性能读写、适应大规模数据处理。
缺点：一致性和事务支持相对较弱、查询语言不统一、数据完整性依赖应用程序

NoSQL数据库的发展是对现代应用需求的回应，它们在大数据、实时应用和分布式系统中的表现，使其成为传统关系型数据库的重要补充和替代方案

选择RDBMS还是NoSQL取决于具体的应用需求和场景。对于需要严格事务和数据一致性的应用， RDBMS可能更适合；而对于需要处理海量数据和高并发访问的应用，NoSQL则可能是更好的选择

CAP 定理和Base理论

CAP 定理

C：Consistency

即一致性，所有节点在同一时间具有相同的数据视图

换句话说，如果一个节点在写入操作完成后，所有其他节点都能立即读取到最新的数据

注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来

每次读取的数据都应该是最近写入的数据或者返回一个错误, 而不是过期数据，也就是说，所有节点的数据是一致的

A：Availability

即可用性，所有的节点都保持高可用性

每个非故障节点都能够在有限的时间内返回有效的响应，即系统一直可用。可用性强调系统对用户请求的及时响应

注意，这里的高可用还包括不能出现延迟，比如如果某个节点由于等待数据同步而阻塞请求，那么该节点就不满足高可用性

也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集

每次请求都应该得到一个有效的响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的，也就是说系统需要一直都是可用正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的

P：Partiton tolerance

即分区容忍性，系统能够在网络分区的情况下继续运行。分区是指系统中的节点由于网络故障无法相互通信，导致系统被分成多个孤立的子系统

由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务

在分布式系统中，机器分布在各个不同的地方，由网络进行连接。由于各地的网络情况不同，网络的延迟甚至是中断是不可避免的。分区容错性指的就是服务器之间通信异常的情况

遵循CAP原理，一个数据分布式系统不可能同时满足C和A和P这3个条件。所以系统架构师在设计系统时，不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。由于网络的不可靠的性质，大多数开源的分布式系统都会实现P，也就是分区容忍性，之后在C和A中做抉择

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大

CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。放弃可用性，追求强一致性和分区容错性

AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些

通常实现AP都会保证最终一致性，而BASE理论就是根据AP来扩展的，一些业务场景比如：订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可

Base理论

Base理论是三要素的缩写：基本可用（Basically Available）、软状态（Soft-state）、最终一致性（Eventually Consistency）

基本可用（Basically Available）

相对于CAP理论中可用性的要求：【任何时候，读写都是成功的】，“基本可用”要求系统能够基本运行，一直提供服务，强调的是分布式系统在出现不可预知故障的时候，允许损失部分可用性。比如系统通过断路保护而引发快速失败，在快速失败模式下，支持加载默认显示的内容（静态化的或者被缓存的数据），从而保证服务依然可用

软状态（Soft state）

相对于ACID事务中原子性要求的要么全做，要么全不做，强调的是强制一致性，要求多个节点的数据副本是一致的，强调数据的一致性。这种原子性可以理解为 “硬状态“，而软状态则允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在不同节点的数据副本上存在数据延时

最终一致性（Eventuallyconsistent）

数据不可能一直处于软状态，必须在一个时间期限后达到各个节点的一致性。在期限过后，应当保证所有副本中的数据保持一致性，也就是达到了数据的最终一致性，在系统设计中，最终一致性实现的时间取决于网络延时、系统负载、不同的存储选型，不同数据复制方案设计等因素。也就是说，不保证用户什么时候能看到更新完成后的数据，但是终究会看到的

NoSQL 数据库分类

类型	部分代表	特点
列存储	Hbase	顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势
文档存储	MongoDB， CouchDB	文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有机会对某些字段建立索引，实现关系数据库的某些功能
Key-Value 存储	Memcached， Redis	可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能）
图存储	Neo4JFlockDB	图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便
对象存储	db4oVersant	通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据
XML 数据库	Berkeley DB XMLBaseX	高效的存储XML数据，并支持XML的内部查询语法，比如 XQuery，Xpath

Redis 基础

Redis（Remote Dictionary Server远程字典服务）是一个遵循 BSD MIT 开源协议的高性能的 NoSQL

Redis 基于ANSI C 语言语言编写的 key-value 数据库，是意大利的 Salvatore Sanfilippo 在 2009 年发布从 2010年3月15日起，Redis 的开发工作由VMware主持，从2013年5月开始，Redis 的开发由 Pivotal 公司赞助。目前国内外使用的公司众多，比如：阿里，腾讯,百度，京东，新浪微博，GitHub， Twitter 等

Redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，Go, C#，PHP，JavaScript，Perl，Object-C，Python， Ruby，Erlang 等客户端

Redis 特性

高性能：基于内存，读写操作快速，适用于高性能需求的场景
丰富的数据结构：支持字符串，哈希，列表，集合等多种数据结构
持久化：支持 RDB 和 AOF 两种方式对内存中的数据进行持久化操作
发布/订阅：支持实时消息发布和通知
多种语言客户端：支持 java，python，C/C++，PHP 等主流编程语言
Lua脚本：服务器端运行Lua脚本，提供原子性操作
主从复制：数据从主节点复制到从节点，实现数据冗余和负载均衡
高可用和分布式：支持哨兵和集群两种方式实现高可用和分布式
生周周期：支持数据自动过期，支持数据自动淘汰

Redis 中的单线程

Redis单线程设计在高性能、高并发场景中表现优越，同时有多种优化手段应对性能瓶颈

Redis中的单线程指的是Redis使用单线程处理所有客户端请求，即所有命令按顺序执行，不并行处理而不是说 Redis 服务中只有一个线程

单线程的优点：

简单：无需处理多线程同步和锁问题
高效：避免上下文切换和锁争用
低延迟：请求处理时间短，保持低延迟

单线程的缺点：

CPU 瓶颈：单线程在CPU密集型任务下可能成为瓶颈，无法发挥服务器多核心的作用
慢查询：长时间查询会阻塞请求

Redis 和 Memcached 比较

Redis和Memcached都是流行的内存缓存系统，但在特性和应用场景上有显著差异

特性	Redis	Memcached
数据结构	支持多种数据结构（字符串、哈希、列表、集合等）	仅支持简单的键值对
持久化	支持（RDB和AOF）	不支持
主从复制和高可用	支持主从复制、哨兵和集群模式	不支持原生复制和故障转移，依赖客户端实现
内存管理	灵活，支持多种淘汰策略（如LRU、 LFU）	简单，基于LRU策略
性能	高性能，适合复杂操作和实时处理，单线程设计	极高性能，适合简单键值对操作，多线程设计
应用场景	缓存、会话存储、实时数据处理、消息队列等复杂场景	简单、高性能的键值对缓存