Redis_NoSQL入门学习笔记

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 选项的值来决定。该选项有三个可选值,分别是 alwayseverysecno

  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三种集群模式

猜你喜欢

转载自blog.csdn.net/hesorchen/article/details/122805518