Redis学习一：NoSQL学习
本文最后更新于：2024年5月10日 下午
作为目前最知名也是最流行的开源NoSQL数据库，Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库。因此Redis的学习很有必要。主要通过B站尚硅谷网课和配套资料免费学习。
NoSQL入门概述-上
1 为什么用NoSQL
在介绍NoSQL之前，先介绍一下应用中的SQL发展，从单机的MySQL到分库分表+缓存到集群等等，随着移动应用发展，网站程序访问量不断激增，所以对应用的数据库要求也在不断增加。
1.单机MySQL的美好年代
在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。（我们在学校做的应用基本上都是采用简单的单机MySQL）
DAL dal是数据访问层的英文缩写，即为数据访问层（Data Access Layer）
上述架构下，我们来看看数据存储的瓶颈是什么?
- 数据量的总大小一个机器放不下时
- 数据的索引(B+ Tree)一个机器的内存放不下时
- 访问量(读写混合)一个实例不能承受
如果满足了上述1or3个，进化…
2.Memcached(缓存)+MySQL+垂直拆分
后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。
程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
3.Mysql主从读写分离
由于数据库的写入压力增加，Memcached 只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
4.分表分库+水平拆分+mysql集群
在Memcached的高速缓存，MySQL的主从复制， 读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库[2]成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。
5.MySQL的扩展性瓶颈
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小， 如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差(需要复杂的技术来实现)，大数据下IO压力大，表结构更改困难，正是当前使用MySOL的开发人员面临的问题。
6.今天是什么样子? ?
7.为什么用NoSQL
传统的RDBMS使用SQL语法来存储和查询数据。相反，NoSQL数据库系统包含可存储结构化，半结构化，非结构化和多态数据的多种数据库技术。
NoSQL数据库的概念在处理大量数据的互联网巨头（例如Google，Facebook，Amazon等）中变得很流行。使用RDBMS处理海量数据时，系统响应时间变慢。
为了解决此问题，当然可以通过升级现有硬件来“横向扩展”我们的系统。但这个成本很高。这个问题的替代方案是在负载增加时将数据库负载分配到多个主机上。这种方法称为“横向扩展”。传统的SQL数据库已经不适合这些应用了，NoSQL数据库的发展也却能很好的处理这些大的数据。
2 NoSQL是什么
NoSQL，最初被称作Non-SQL[1]；后来也称作Not Only SQL，意即“不仅仅是SQL”，泛指非关系型的数据库。是一种非关系型DMS，不需要固定的架构，可以避免joins链接，并且易于扩展。
NoSQL数据库可以用于具有庞大数据存储需求的分布式数据存储、大数据和实时SNS类型的Web应用程序。例如，像Twitter，Facebook，Google这样的大型公司，每天可能产生TB级的用户数据，这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
3 NoSQL特点
易扩展
例如MySQL，出于业务需求需要拓展对象的属性时，是通过alter table添加字段，但是这是有限的，且数据库的字段类型也是有限的。并且对于社会关系等比较复杂的关系，可能需要用图、树等结构来描述，采用SQL难于拓展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。（以常见的k-v键值对为例，key可以是数字、字符等等，value可以是字符串、对象、对象数组等等）
大数据量高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
多样灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的Web 2.0时代尤其明显。
高可用
NoSQL在不太影响性能的情况，就可以方便地实现高可用的架构。比如Cassandra、HBase模型，通过复制模型也能实现高可用
传统RDBMS VS NOSQL
RDBMS
- 高度组织化结构化数据
- 结构化查询语言(SQL)
- 数据和关系都存储在单独的表中
- 数据操纵语言，数据定义语言
- 严格的一致性
- 基础事务
NoSQL
- 代表着不仅仅是SQL
- 没有声明性查询语言
- 没有预定义的模式
- 键-值对存储，列存储，文档存储，图形数据库
- 最终一致性，而非ACID属性
- 非结构化和不可预知的数据
- CAP定理
- 高性能，高可用性和可伸缩性
4.NoSQL的应用
- K-V：键值对存储
- Cache：缓存
- Persistence：数据持久化
NoSQL入门概述-下
以腾讯微信、阿里淘宝为例：在节假日活动时会产生海量的用户数据；数据的种类肯定也是多样的，不是仅仅在数据库中表现的varchar、int等简单类型；双十一、春节车票抢购都是对数据的实时性有非常高的要求。对应于应用发展带来的数据3v，需求架构上也产生了三高。
| 大数据时代的3V | 互联网需求的3高 |
|---|---|
| 海量Volume | 高并发 |
| 多样Variety | 高可扩 |
| 实时Velocity | 高性能 |
当下NoSQL应用场景简介
SQL和NoSQL双剑合璧：以阿里巴巴为例，通过分析Alibaba中文站商品信息如何存放，看看阿里巴巴中文网站首页以女装/女包包为例
架构发展历程
演变过程
第5代
第5代架构使命
和我们相关的，多数据源类型的存储问题
例如一个购物网站的商品页面，会包含商品的基本信息、详情、销量、用户的评价（文字图片视频）、点赞点踩等等不同类型的信息，且信息的存放往往会采用不同的数据源。
阿里商品描述
什么是IOE，为什么去IOE化
I：IBM的小型机、O：Oracle的数据库、E：EMC的高端存储。这三者在金融证券电信保险等企业有着巨大的份额，许多传统企业都是采用它们的产品，导致技术上有着严重依赖，对于公司的发展提升有着很大的弊病。
去IOE化，其本意是，在阿里巴巴的IT架构中，去掉IBM的小型机、Oracle数据库、EMC存储设备，代之以自己在开源软件基础上开发的系统。借此保证企业良好的技术提升
| 类型 | 内容及存储方式 |
|---|---|
| 商品基本信息 | 名称、价格，出厂日期，生产厂商等趋于不变的数据 关系型数据库。如MySQL |
| 商品描述、详情、评价信息(多文字类) | 多文字信息描述类，IO读写性能变差 文档数据库MongDB |
| 商品的图片 | 商品图片展现类。 分布式的文件系统，如TFS、GTF、HDFS |
| 商品的关键字 | 淘宝自研的ISearch |
| 商品的波段性的热点高频信息 | 内存数据库；Tair、Redis、Memcache |
| 商品的交易、价格计算、积分累计 | 外部系统，外部第3方支付接口 支付宝 |
NoSQL数据模型简介
以一个电商客户、订单、订购、地址模型来对比关系型数据库和非关系型数据库
传统关系型数据库如何设计：先画E-R图，描述模型关联，再根据E-R设计表结构。常见的关联有1:1、1:n、n:n等。
NOSQL如何设计：以BSON为例，采用Json结构来表述数据的存储方式，k-v形式可以实现对象的存储。
为什么用聚合模型来处理
高并发的操作是不太建议用关联查询的，互联网公司用冗余数据来避免关联查询；分布式事务是支持不了太多的并发的
NoSQL数据库四大分类
常见的K-V键值对：【新浪：BerkeleyDB+redis】、【美团：redis+tair】、【阿里、百度：memcache+redis】
文档型数据库：Bson格式为主，【CouchDB】、【MongoDB(一个基于分布式文件存储的数据库)】
列族：顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，
对针对某一列或者某几列的查询有非常大的IO优势。【Cassandra】、【HBase】、【分布式文件系统】
图形：图关联结构，存放的不是图片数据，而是用来表示存在复杂关系的数据，社交网络、推荐系统等应用较多。【Neo4J】、【InfoGrid】
四者对比
分布式数据库CAP原理
CAP原理简介
介绍分布式数据库的CAP原理之前，可以先回顾一下SQL数据库的ACID特性
- A (Atomicity) 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成。
- C (Consistency) 一致性：执行事务前后，数据库的完整性没有被破坏，数据能保持一致。
- I (Isolation) 独立性：数据库允许多个事务进行数据操作，通过隔离性防止多个事务并发执行出现的数据不一致
- D (Durability) 持久性：事务对数据的修改是永久的。
分布式数据库的CAP原理：对于分布式计算系统来说，不可能同时满足以下三点
- C:Consistency（强一致性）：分布式系统中的所有数据备份，在同一时刻保持同样的值。（等同于所有节点访问同一份最新的数据副本）
- A:Availability（可用性）：保证每个请求都能获得非错的响应，但不保证响应的是最新的数据。
- P:Partition tolerance（分区容忍性）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。
CAP的三进二
CA（一致性+可用性）
即放弃系统的拓展性，传统的单点关系型数据库或类似架构的非分布式数据库，不存在网络分区问题。
比如MySQL、Oracle等传统数据库
CP（一致性+容错性）
相当于每个请求都需要在服务器之间保持强一致性。当分区间的数据出现不一致（出现网络故障等情况），必须停止旧数据的服务，直到数据同步完成，这势必会牺牲用户的体验。
典型的比如Redis、HBase，数据的一致性是基本要求，发生特殊情况优先保证数据的强一致性
AP（可用性+容错性）
仍然允许所有客户端读写，但是两个数据中心之间不再同步，它们的数据就会逐渐地变得不同，即牺牲一致性，保证可用性。
AP的应用场景也很多，比如12306抢票，浏览时看到还有票（可能已经没票了），点进去下单提示没票了，购买失败。这就是在数据一致性上做出牺牲，会影响一些用户体验，但是也不至于造成用户流程的严重阻塞。
但是，我们说很多网站牺牲了一致性，选择了可用性，这其实也不准确的。就比如上面的买票的例子，其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过了一段时间，还是要保证最终一致性的。
BASE定理
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
BASE是对CAP中一致性C和可用性A权衡的结果，来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是：让系统放松对某一时刻数据的强一致性要求（Strong Consistency），来换取西戎整体的伸缩性和性能上的改观，结合自身业务特点，通过适当设计保证系统达到最终一致性（Eventual Consistency）。
基本可用
什么是基本可用？它是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，参考例子：
- 响应时间上的损失：正常情况下一个搜索引擎0.5秒即返回给用户结果，现在出现了异常，查询的相应时间可能变成1-2秒。
- 功能上的损失：日常购物时用户在网上买东西可以按流程顺利完成订单，但是在像双十一这种高峰期，用户访问量剧增，为了保证稳定，部分用户可能会被引导到降级页面。
软状态
相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
最终一致性
软状态不能一直存在，必须有一个期限，在这段时间内可以允许数据延时，但是期限过后所有数据要达到一致状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
亚马逊首席技术官Werner Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍，他认为最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。
- 因果一致性（Causal consistency）
- 读己之所写（Read your writes）
- 会话一致性（Session consistency）
- 单调读一致性（Monotonic read consistency）
- 单调写一致性（Monotonic write consistency）
实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。
总体来说BASE理论面向的是大型高可用、可扩展的分布式系统。与传统ACID特性相反，不同于ACID的强一致性模型，BASE提出通过牺牲强一致性来获得可用性，并允许数据段时间内的不一致，但是最终达到一致状态。同时，在实际分布式场景中，不同业务对数据的一致性要求不一样。因此在设计中，ACID和BASE理论往往又会结合使用。