nosql之Redis总结

关于nosql

nosql基本含义

NoSQL最常见的解释是“non-relational”， “Not Only SQL”也被很多人接受。NoSQL仅仅是一个概念，泛指非关系型的数据库，区别于关系数据库，它们不保证关系数据的ACID特性。NoSQL是一项全新的数据库革命性运动，其拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。NoSQL有如下优点：易扩展，NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。无形之间也在架构的层面上带来了可扩展的能力。大数据量，高性能，NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。
在这里推荐一个网站，没事看看：db-engines.com

键值(Key-Value)存储数据库

这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：Tokyo Cabinet/Tyrant， Redis， Voldemort， Oracle BDB。

列存储数据库

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra， HBase， Riak。

文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB， MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。

图形(Graph)数据库

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J， InfoGrid， Infinite Graph。

CAP帽子原理

在互联网系统中，由于对系统或数据进行了拆分，我们的系统不再是单机系统，而是分布式系统，针对分布式系统的CAP原理包含以下三个元素。

1、C：consistency，一致性

在分布式系统中的所有数据备份，在同一时刻具有相同的值，所有节点在同一时刻读取的数据都是最新的数据副本。

2、A：availability，可用性，好的响应性能

完全的可用性指的是在任何故障模型下，服务都会在有限时间内处理完成并进行响应。

3、P：partition tolerance，分区容忍性

尽管网络上有部分消息丢失，但系统仍可继续工作。

总结

CAP原理证明，任何分布式系统只能同时满足以上两点，而做不到三点兼得。

1. 对于关系型数据库而言，由于关系型数据库是单节点无法复制的，因此不具有分区容忍性，但具有一致性和可用性。
2. 而分布式的服务化系统都需要满足分区容忍性，那么我们必须在一致性和可用性之间进行权衡。如果在网络上有消息丢失，也就是出现了网络分区，则复制操作可能会被延后。在这种情况下，如果使用方等待数据修复之后再返回，则可能导致在一定时间内无法返回，这就失去了可用性。如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但丢失了一致性。
   redis便满足了一致性和分区容忍性，现如今项目基本上需要用分布式集群的方式开发项目确保项目的稳定使用，redis的优点就在此体现出来了。

Redis简介

一、Redis 概述

1、Redis:远程字典服务器(REmote DIctionary Server);
2、Redis 是一个高性能(key/value)分布式内存数据库，是一个非关系型数据库中的键值类型数据库，基于内存运行并支持持久化的NoSQL数据库;
3、Redis 三个特点:

• Redis 支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候,可以再次加载进行使用;
• Redis 不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储;
• Redis 支持数据的备份,即master-slave模式的数据备份。

命令

1. 检测安装：ping，若结果为pong说明安装成功；
2. 测试电脑（服务器）性能（手动滑稽）：redis-benchmark

二、 Redis 数据类型

1、 Redis 的五大数据类型

• String(字符串)
• Hash(哈希,类似java里的Map)
• List
• Set
• Zset(sorted set: 有序集合)
• 位图(Bitmap)
• Hyperloglog
• 地理空间(Geospatial)

2、 Redis 键(key)

• set 键名 键值: 向数据库中存储键值对;
• keys *: 查看当前数据库所有键;
• exits 键名: 判断某个key是否存在,存在,返回"1";不存在,返回"0";
• move 键名 数据库(例如2): 将某个键剪切至2号数据库;
• expire key 秒: 为指定的key设置过期时间;
• ttl key: 查看该key,还有多少秒过期;-1表示永不过期, -2表示已过期;
• type key: 查看key的类型;

3、Redis 字符串(String)

• set/get/del 键名: 设置/获取/删除;
• append 键名(key) 值: 向key所对应的value后面添加值;
• strlen 键名(key): 获取某个key所对应的value的字符串长度;
• incr/decr/incrby/decrby: 一定要是数字才能进行加减;
• getrange k2 0 3: 表示获取k2所对应的value的前四个字符;
• setrange: 设置指定区间范围内的值;
• setex(set with expire) 秒: 设置过期时间;
• setnx(set if not exist)
• mset/mget/msetnx: 设置(获取)多个, 例,mset k2 v2 k3 v3 k4 v4;
• getset: 先get再set;

4 Redis 列表(List)

LPUSH list01 1 2 3 4 5: 存储list; “LPUSH(Left push)”
LRANGE list01: 获取,“5,4,3,2,1”;
RPUSH list02 1 2 3 4 5
LRANGE list02: 获取, “1 2 3 4 5”
LPOP/RPOP：用于移除并返回列表第一个参数
LINDEX: 按照索引下标获得元素(从上到下);
LLEN: 获取list集合的长度;
RUPUSH list03 1 1 1 2 2 2 3 3 3 4 4 4 5 6 7
LREM list03 2 3: 删除list03集合中两个3(LREM, Left remove);
LTRIM list03 0 4: 截取指定范围(0~4)的值,然后赋值给list03;
RPOPLPUSH 源列表 目的列表
LSET list03 1 x: 将list03中的下标为1的键的值设置为"x";
LINSERT list03 before(after) x java: 在"x"的前面(或后面)插入"java";
注：
1、语法: LRem key count value
参数说明:
key：指定的列表名
count： 指定列表元素的下标位置
value：指定需要删除的值
1.count>0 从头往尾删除个数为count的值为value的元素
2. count<0 从尾往头删除个数为count的值为value的元素
3. count=0 删除所有值为value的元素
2、语法：LRange/RRange key count1 count2
参数说明：
key：指定的列表名
count： 指定列表元素的下标位置
1.count=0 代表下标为0的位置，即第一个元素
2.count=-1 代表列表位置为最后的一个元素

5 Redis 集合(Set)

SADD set01 1 1 2 2 3 3: 向set01中插入值,只会插入"1 2 3",即不允许重复;
SMEMBERS set01: 获取set01集合中的值
SISMEMBER set01 1: 判断"1"是否为集合set01成员; 如果是,返回1;不是,返回0;
SCARD: 获取集合里面元素个数;
SREM key member[memeber…]:移除集合key中的一个或多个memeber元素;
SRANDMEMEBER set01 3: 从set01集合中随机取三个值;
SPOP set01:从set01集合中,随机移除一个元素,并返回该元素;
SMOVE source destination memeber: 将 memeber 元素从source集合移动到destination集合;
SDIFF: 差集;
SINTER: 交集;
SUNION: 并集;

6 Redis 哈希(Hash)

类似于 Map<String,Object>;
KV模式不变,但V是一个键值对;
hset user gender male: 将 user 哈希表中的gender值设为male;
hget user gender: 获取;
hmset customer id 11 name zhangsan age 22:同时将多个field-value(域-值)对设置到哈希表customer中
hmget customer id name age: 获取多个值;
hgetall customer: 获取所有的域和值;
hdel customer id name: 删除哈希表中的id和name域;
hlen customer:获取哈希表的长度;
hexists customer id: 查看哈希表customer中是否存在id域;
hkeys customer: 获取哈希表customer中的所有域;
hvalues customer: 获取哈希表customer中的所有域的值;
hincryby key field increment: 为哈希表key中的域field的值加上增量increment;
hincrbyfloat
hsetnx key field value: 当域field不存在时,将该域field的值设置为value;

7 Redis 有序集合(Zset,sorted set)

Zset 在set基础上,加上一个score值;之前set集合是:k1 v1 v2 v3,现在,Zset是k1 score1 v1 score2 v2
zadd key score1 mem1 score2 mem2:将一个或多个memeber元素及其score的值加入到有序集key当中;
zrangebyscore key 开始min 结束max: 返回有序集key中,所有score介于min和max之间;
zrangebysroce zset (1 5: 返回所有符合条件 1<score<=5 的成员;
zrem key memeber: 移除有序集key中的一个或多个成员;
zcard key: 返回有序集合key的基数;
zcount key min max: 返回有序集key中,score值在min和max之间的成员数量;
zrank key member: 返回有序集key中成员memeber的下标;
zscore key member: 返回有序集key中,成员memeber对应的score值;
zrevrank key member: 逆序获得成员member下标值;
zrevrange key 0 -1: 逆序获得有序集key的所有的member成员;
zrevrangebyscore

三、 Redis 的持久化

持久化是将程序数据在持久状态和瞬间状态间转化的机制。可以理解是将数据存储在可以永久保存的磁盘等中。是为了防止服务器宕机数据丢失。
RDB(Redis DataBase)持久化方式：可以在指定的时间间隔能对数据进行快照存储；
AOF(Append Only File)持久化方式：记录每次对服务器写的操作。
如果服务器开启了AOF持久化功能，服务器会优化使用AOF文件还原数据，只有

1 RDB(Redis DataBase)

1.1 RDB 概述

RDB: 在指定的时间间隔内,将内存中的数据集快照(snapshot)写入磁盘,它恢复时,是将快照文件直接读到内存里;
Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,
在用这个临时文件替换上次持久化好的文件;
整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能;
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加高效;
RDB 的缺点: 最后一次持久化后的数据可能丢失;
RDB 保存的是 dump.rdb;
RDB 是整个内存压缩过的Snapshot, RDB持久化策略,与快照触发条件一样,默认值
1分钟内修改了1万次; save 60 10000
5分钟内修改了10次; save 300 10
15分钟内修改了1次; save 900 1

1.2 Fork

Fork的作用: 是复制一个与当前进程一样的进程;新进程的所有数据(变量,环境变量,程序计数器等)数值都和原进程
一致,但是是一个全新的进程,并作为原进程的子进程;

1.3 触发RDB快照的方式(三种)

配置文件中默认的快照配置,冷拷贝以后重新使用(即备份文件和要恢复备份的机器不是同一台);
save或bgsave命令,立刻生成dump.rbd文件;
save时,只管保存,其他不管,全部阻塞;
bgsave:Redis 会在后台异步执行快照操作,快照的同时还可以响应客户端请求;可以通过lastsave命令
获取最后一次成功执行快照的时间;
执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义;

1.4 恢复备份文件

将备份文件(dump.rdb)移动到redis安装目录并启动服务即可;

1.5 RDB优缺点

优势:

• 适合大规模的数据恢复;
• 对数据完整型和一致性要求不高;

劣势

• 在一定间隔时间做一次备份,所以如果redis意外宕机的话,就会丢失最后一次快照后的所有修改;
• Fork 的适合,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑;

2 AOF(Append Only File)

2.1 AOF 概述

以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只需追加文件但不可以改写文件, redis启动之初会读取该文件,重新构建数据,换言之,redis重启的话,就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
redis.conf中的配置appendonly no,即该种持久化方式默认为关闭;需要启动时把no改为yes。
注：windows系统为redis.windows.conf文件，修改为appendonly yes后该文件目录会出现appendonly.aof文件。启动redis服务时，启动命令为：redis-server redis.windows.conf
redis.conf中的配置appendfsync=everysec,出厂默认值,异步操作,每秒记录,若一秒内宕机,有数据丢失；appendfsync=always: 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好。appendfsync=always：将aof_buf缓冲区中的所有内容写入AOF文件，但不对其进行同步。

效率和安全性

• Always：效率最慢

2.2 重写Rewrite

AOF 采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof;
重写原理:AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据;重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似;
触发机制:Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发;

2.3 AOF 优势和劣势

优势:

• 同步持久化,appendfsync=always;
• 每修改同步,appendfsync=everysec;
• 所以一旦出现故障，最多丢失1秒的数据；

劣势:

• 相同数据集的数据而言,aof文件要远大于rdb文件,恢复速度慢于rdb;
• AOF运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同;

3 RDB 和 AOF

RDB 持久化方式能够在指定的时间间隔,对数据进行快照存储;
AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候,会重新执行这些命令来恢复原始的数据,AOF 命令
以redis协议追加保存每次写的操作到文件末尾,Redis 还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大;
同时开启两种持久化方式:
在这种情况下,当redis重启的时候,会优先加载AOF文件来恢复原始的数据,因为在通常情况下,AOF文件保存的数据集要比RDB文件保存的数据集完整;

4 Redis 的事务

4.1 事务

• 事务本质上是一组命令的集合;一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入,不许加塞;

4.2 常用命令

• MULTI: 标记一个事务块的开始;
• EXEC: 执行所有事务块内的命令;
• DISCARD: 取消事务,放弃执行事务块内的所有命令;
• WATCH: 监控一个(或多个)key,如果在事务执行之前,这个(或这些)key被其他命令所改动,那么事务将被打断;
• UNWATCH: 取消WATCH命令对所有key的监视;

4.3 事务的执行情况:

• 正常执行
• 放弃事务
• 全体连坐:不管命令正确错误,都不执行;
• 冤头债主:错误的命令不执行,正确的命令执行;
• watch监控

4.4 Redis 事务的三阶段

• 开启: 以MULTI开始一个事务;
• 入队: 将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面;
• 执行: 以EXEC命令触发事务;

4.5 Redis 事务的三个特性

• 单独的隔离操作:事务中的所有命令都会序列化,按顺序地执行;事务在执行的过程中,不会被其他客户端发送来的命令请求所打断;
• 没有隔离级别的概念:队列中的命令,在没有提交之前不会实际的被执行,因为事务提交前任何指令都不会被实际执行,
  也就不存在"事务内的查询要看到事务里的更新,在事务外查询不能看到"这个让人万分头痛的问题;
• 不保证原子性:redis同一个事务中,如果有一条命令执行失败,其他的命令仍然会被执行,没有回滚;

5 Redis 的发布/订阅

Redis 的发布/订阅:进程间的一种信息通信模式,发送者(pub)发送消息,订阅者(sub)接收消息;

6 哨兵（sentinal）和复制

6.1 概述

1、哨兵：可以管理多个redis服务器，
2、复制：

7 Redis 主从复制(Master/Slave )

7.1 概述

主从复制: 主机数据更新后,根据配置和策略,自动同步到备机的master/slave机制,Master以写为主,Slave以读为主;

7.2 应用

读写分离
容灾备份

7.3 使用方法

配从(库)不配主(库)
从库配置: slaveof 主库IP 主库端口

• 每次与master断开之后,都需要重新连接,除非配置进redis.conf文件;
• info replication: 查看当前库的状态;
  修改配置文件
• 拷贝多个 redis.conf 文件;
• 设置 daemonize yes, Pid 文件名字, 指定端口, Log文件的名字, Dump.rbd名字;
  常用3招：
• 一主二从(一个Master,两个Slave)
• 薪火相传
  1、 上一个Slave可以是下一个Slave的Master,Slave同样可以接收其他Slaves的连接和同步请求,那么,该Slave就是下一个Slave的Master,这样,可以有效减轻master的写压力;
  中途变更转向:会清除之前的数据,重新建立拷贝最新的; slaveof 新主库IP 新主库端口;
  反客为主
  slaveof no one
  使当前数据库停止与其他数据库的同步,转成主数据库;
  复制原理
  slave 成功连接到master后,会发送一个sync命令;
  Master 接到命令,启动后台的存盘进程,同时,收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,
  master 将传送整个数据文件到slave,以完成一次完全同步;
  全量复制:slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中;
  增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步;
  但是,只要是重新连接master,一次完全同步(全量复制)将被自动执行;
  复制的缺点:复制的延时;由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步
  到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重;
  哨兵模式(Sentinel)
  "反客为主"的自动版,能够后台监控主机是否故障,如果发生故障,根据投票数自动将从库转换为主库;
  使用步骤
  配置 sentinel.conf, 具体参考地址
  一个sentinel能同时监控多个Master;