Redis_NoSQL入门学习笔记

Posted 2022-12-11 hesorchen

目录

• • NoSQL简介
  • • • NoSQL四种分类
  • 分布式基础之CAP和BASE理论
  • • • 集中式和分布式
      • 分布式系统设计理论CAP
      • BASE理论
  • Redis
  • • • 简介
      • 常见命令
      • 五大数据类型
      • 持久化之RDB
      • 持久化之AOF
      • 事务
      • 主从复制

NoSQL简介

NoSQL = Not Only SQL ，意即“不仅仅是SQL”。泛指非关系型的数据库。这些类型的数据存储不需要固定的模式，无序多余操作就可以横向扩展。

特点：

1. 易扩展：NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

2. 大数据量高性能：NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般mysql使用Query Calche，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL 的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

3. 多样灵活的数据模型：NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。

NoSQL四种分类

1. KV（键值）
2. 列存储数据库
3. 文档型数据库
4. 图形数据库

分布式基础之CAP和BASE理论

集中式和分布式

1、集中式
集中式是指有一台或者多台计算机组成的中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由集中处理。

2、分布式
分布式系统是一个硬件或者软件分布在不同的网络计算机上，彼此之间仅仅通过消费传递进行通信和协调的系统。

分布式系统设计理论CAP

ACID是数据库事务完整性的理论，CAP是分布式系统设计理论，BASE是CAP理论中AP方案的延伸。

CAP原理，即：

1. C：Consistency（强一致性）

   在分布式系统中如果能够针对一个数据项的更新操作执行成功后，所有用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性。

2. A：Avaliability（可用性）

   可用性指系统提供的服务必须一致处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内（指用户的一个操作，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间，系统就认为不可用）返回结果（返回结果是可用性的另一个重要指标，要求系统在完成对用户请求处理后，返回一个正常的响应结果，失败或者成功，而不是一个困惑的结果）。

3. P：Partition tolerance（分区容忍性）
   分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性或可用性的服务，除非整个网络环境发生了故障。

总结

在分布式环境中，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。也就是说分区容错性是分布式系统的一个最基本要求。

在CAP理论中，不能同时满足一致性、分区容忍性、可用性，而分区又是分布式系统的基本要求，因此在架构设计的时候只能在AP或者CP中选择，也就是只能在一致性或者可用性之间取舍。

另外，CAP理论关注的粒度是数据，而不是系统，也即针对同一系统的不同数据，可能会分别采用AP和CP。

参考博客：1、分布式基础之CAP和BASE理论

BASE理论

BASE理论就是对CAP理论中的一致性和可用性权衡之后的结果，让分布式系统满足三个特性，即：

1. BA：Basically Available（基本可用）
   基本可用的意思就是分布式系统如果出现不可预知的故障时，允许损失部分的可用性，但并不是整个系统都不可用，即保证系统核心服务可用即可；比如实际开发中，出现部分服务故障，我们可以让系统的响应时间适当变长，或者限流，降低消费，甚至是服务降级，让某个服务暂时无法提供服务

2. S：Soft State（软状态）
   软状态就是指系统中的数据可以存在中间状态， 并该中间状态不会影响到系统的可用性；换个说法就是允许系统中部分结点的数据同步存在时延问题，但这个时延不会影响到系统的可用性

3. E：Eventual Consistency（最终一致性）
   最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到数据一致的状态。既最终一致性的本质是需要系统保证数据的最终一致性，而不每时每刻的强一致性。但也要保证非一致窗口时期不会对系统数据造成危害

参考博客：【技术杂记】如何正确的理解CAP和BASE理论？

Redis

简介

Redis:REmote DIctionary Server(远程字典服务器)，是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的(key/value)分布式内存数据库，基于内存运行，并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一，也被人们称为数据结构服务器。

常见命令

切换数据库

select 数据库编号

查看当前数据库key的数量

DBsize

列出当前数据库所有key

keys *

查看指定key的类型

type key

删除库中所有key

FLUSHDB

删除库中指定key

DEL key名

给key设置过期时间，如果key过期，会被删除。

EXPIRE key名 时间

time to live，查看key的剩余时间，如果已经过期，返回-2，如果没设置过期时间，返回-1

TTL key名

五大数据类型

一、string（字符串）

string是redis最基本的类型。

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象。

一些常用命令：

SET name cy
GET name
SET a 1
INCR a # +1
INCRBY a step # +step
GETRANGE str L R # 取出str L-R的子串
SETEX str time value # 创建时即设置过期时间
MSET str1 v1 str2 v2 # 同时创建多个str
MGET str1 str2 # 同时获取多个str的值
SETNX a 1 # 如果不存在则创建

二、List（列表）

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

他的底层是一个链表

一些常用命令：

LPUSH list名 v1 v2 v3 # 从左边依次插入，如果不存在列表，则创建
RPUSH list名 v1 v2 v3 # 从右边依次插入，如果不存在列表，则创建
LRANGE list名 L R # 查询指定范围内的值 若L=0  R=-1 则返回整个list 
LPOP list名 # 删除并返回最左边的值
RPOP list名 # 删除并返回最右边的值
LINDEX list名 id # 返回下标为id的元素
LLEN list名 # 返回list长度

如果值全移除，对应的键就消失了。各操作的时间复杂度参考链表。

三、Set（集合）

Redis的Set是string类型的无序集合。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

一些常用命令：

SADD st 1 2 3 3 # 向集合内插入值，如果集合不存在，则创建
SMEMBERS key # 查看集合内的所有值
SCARD key # 查看集合元素个数
SREM key value # 删除集合内指定的值
SDIFF key1 key2 # 差集
SINTER key1 key2 # 交集
SUNION key1 key2 # 并集

四、Hash（哈希）
Redis hash 是一个键值(key=>value)对集合。

Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

一些常用命令：

HSET hs1 k v # 向哈希内插入值，如果集合不存在，则创建
HMSET hs1 k1 v1 k2 v2 # 向哈希内插入多个值
HMGET hs1 k1 k2 k3 # 查看哈希内多个键对应的值
HGETALL hs1 # 查看哈希所有键值，返回形式为k1 v1 k2 v2 ...
HKEYS hs1 # 查看哈希内所有key
HVALS hs1 # 查看哈希内所有value
HLEN hs1 # 查看哈希内键值对的数量

五、zset（sorted set：有序集合）

zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

zset的成员是唯一的,但分数(score)却可以重复。

一些常用命令：

ZADD zst1 score1 v1 score2 v2 score3 v3 # 向zset插入值，若不存在，则创建
ZRANGE zst1 L R $ 按照从小到大返回第L到第R个值

持久化之RDB

RDB快照用官方的话来说：RDB持久化方案是按照指定时间间隔对你的数据集生成的时间点快照。它是Redis数据库中数据的内存快照，它是一个二进制文件（默认名称为：dump.rdb，可修改），存储了文件生成时Redis数据库中所有的数据内容。可用于Redis的数据备份、转移与恢复。

配置参数

RDB快照的触发方式及运行行为受配置参数的影响，打开配置文件redis.conf（windows版本在redis.windows.conf）查看“SNAPSHOTTING”章节，了解RDB快照的参数及作用。

1. save <seconds> <changes>
   save参数是Redis触发自动备份的触发策略，seconds为统计时间（单位：秒）， changes为在统计时间内发生写入的次数。save m n的意思是：m秒内有n条写入就触发一次快照，即备份一次。save参数可以配置多组，满足在不同条件的备份要求。如果需要关闭RDB的自动备份策略，可以使用save “”。以下为几种配置的说明：

   save 900 1：表示900秒（15分钟）内至少有1个key的值发生变化，则执行
   
   save 300 10：表示300秒（5分钟）内至少有1个key的值发生变化，则执行
   
   save 60 10000：表示60秒（1分钟）内至少有10000个key的值发生变化，则执行
   
   save ""： 该配置将会关闭RDB方式的持久化
   

2. dbfilename：快照文件的名称，默认为dump.rdb。

3. dir：快照文件保存目录，默认与当前配置文件在同一目录。

4. stop-writes-on-bgsave-error：默认值为yes。如果为yes，当启用了RDB且最后一次后台保存数据失败，Redis将会停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了。

5. rdbcompression：默认值yes。备份数据时是否使用LZF算法压缩字符串对象。默认是开启的，这样可以节约存储空间，但是在生成备份文件时消耗部分CPU。

6. rdbchecksum：保存和加载rdb文件时是否使用CRC64校验，默认开启。启用此参数可以使rdb文件更加安全，提高稳定性，但是会有一定的性能（大约10%）损失。如果rdb文件创建时未使用校验和，那么校验和将被设置为0，以此告知Redis跳过校验。

持久化流程

在Redis内完成RDB持久化的方法有rdbSave和rdbSaveBackground两个函数方法（源码文件rdb.c中），先简单说下两者差别：

rdbSave：是同步执行的，方法调用后就会立刻启动持久化流程。由于Redis是单线程模型，持久化过程中会阻塞，Redis无法对外提供服务；
rdbSaveBackground：是后台（异步）执行的，该方法会fork出子进程，真正的持久化过程是在子进程中执行的，主进程会继续提供服务；

参考资料：https://segmentfault.com/a/1190000039208707

持久化之AOF

redis默认未开启AOF，开启方式：打开配置文件redis.conf，修改参数：appendonly yes

AOF( append only file )持久化以独立日志的方式记录每次写命令，并在 Redis 重启时在重新执行 AOF 文件中的命令以达到恢复数据的目的。AOF 的主要作用是解决数据持久化的实时性。

如上图所示，AOF 持久化功能的实现可以分为命令追加( append )、文件写入( write )、文件同步( sync )、文件重写(rewrite)和重启加载(load)。其流程如下：

• 所有的写命令会追加到 AOF 缓冲中。
• AOF 缓冲区根据对应的策略向硬盘进行同步操作。
• 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
• 当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

文件写入和同步

Redis 每次结束一个事件循环之前，它都会调用 flushAppendOnlyFile 函数，判断是否需要将 AOF 缓存区中的内容写入和同步到 AOF 文件中。

flushAppendOnlyFile 函数的行为由 redis.conf 配置中的 appendfsync 选项的值来决定。该选项有三个可选值，分别是 always、everysec 和 no：

1. always：Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 appendfsync 选项三个值当中最差的一个，但从安全性来说，也是最安全的。当发生故障停机时，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。

2. everysec：Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件中，并且每隔一秒就要在子线程中对 AOF 文件进行一次同步。从效率上看，该模式足够快。当发生故障停机时，只会丢失一秒钟的命令数据。

3. no：Redis 在每一个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件。而 AOF 文件的同步由操作系统控制。这种模式下速度最快，但是同步的时间间隔较长，出现故障时可能会丢失较多数据。

AOF文件的重写

AOF是写日志文件，因此占用空间会越来越大，可以通过等价重写实现减小空间。

在redis.conf文件中，可以找到以下内容：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

当满足文件大小大于auto-aof-rewrite-min-size，并且当前文件大小比最近一次rewrite之后的文件大百分之auto-aof-rewrite-percentage时，会自动触发rewrite。

注意：AOF实际的重写工作是针对数据库的当前值来进行的，程序既不读写、也不使用原有的 AOF 文件。

参考资料：AOF

事务

redis事务命令：

discard # 取消事务，放弃执行事务块内的所有命令。
exec # 执行所有事务块内的命令。
multi # 标记一个事务块的开始。
unwatch # 取消watch命令对所有key的监视。
watch key # 监视一个（或多个）key，如果在事务执行之前这个key被其他命令所改动，那么事务将会被打断。

五种情况：

1. 正常执行

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set a 1
   QUEUED
   127.0.0.1:6379> incrby a 3
   QUEUED
   127.0.0.1:6379> get a
   QUEUED
   127.0.0.1:6379> exec
   1) OK
   2) (integer) 4
   3) "4"
   

2. 放弃事务：discard

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set a 100
   QUEUED
   127.0.0.1:6379> discard
   OK
   

3. 全体连坐：如果有编译错误，整个事务不会执行

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set a 10
   QUEUED
   127.0.0.1:6379> ssset b 10
   (error) ERR unknown command 'ssset'
   127.0.0.1:6379> exec
   (error) EXECABORT Transaction discarded because of previous errors.
   127.0.0.1:6379>
   

4. 冤头债主：如果有运行错误，只有错误的语句不执行

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set name mike
   QUEUED
   127.0.0.1:6379> incr name
   QUEUED
   127.0.0.1:6379> set name2 john
   QUEUED
   127.0.0.1:6379> exec
   1) OK
   2) (error) ERR value is not an integer or out of range
   3) OK
   127.0.0.1:6379> get name
   "mike"
   127.0.0.1:6379> get name2
   "john"
   

5. watch监控

   127.0.0.1:6379> set balance 100
   OK
   127.0.0.1:6379> set debt 0
   OK
   127.0.0.1:6379> watch balance debt
   OK
   【127.0.0.1:6379> set balance 199999】
   【OK】
   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> decrby balance 10
   QUEUED
   127.0.0.1:6379> incrby debt 10
   QUEUED
   127.0.0.1:6379> exec
   1) (integer) 90
   2) (integer) 10
   

小结：

1. watch指令类似于乐观锁。
2. exec之后所有的监控锁都会被清除。

主从复制

建立主从关系：

slaveof 【masterip】 【masterport】

查看服务器角色：

info replication

结束与主机的连接：

slaveof no one 

slave机只能读，不能写。

复制原理

Slave启动成功连接到master后会发送一个sync命令，Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。

全量复制：在slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
首次连接到master使用全量复制，然后使用增量复制。但是只要是重新连接master，一次完全同步(全量复制)将被自动执行。

哨兵模式

哨兵顾名思义，就是来为Redis集群站哨的，一旦发现问题能做出相应的应对处理。其功能包括

1. 监控master、slave是否正常运行
2. 当master出现故障时，能自动将一个slave转换为master（大哥挂了，选一个小弟上位）

参考资料：一文掌握Redis主从复制、哨兵、Cluster三种集群模式