Redis介绍（持久化，事务，主从复制）

Redis的介绍

一，Redis入门介绍

一，入门概述

一，是什么：

Redis:REmote DIctionary Server(远程字典服务器)，完全开源免费，是一个高性能的（key/value）分布式内存数据库，基于内存运行，并支持持久化的NoSql数据库，被称为数据结构服务器

redis的特点：

1.redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用

2.Redis不仅仅支持简单的key-value类型的数据，同时还提供list,set,zset ,hash等数据结构的存储

3.Redis支持数据的备份，即master-slave模式的数据备份

二，能干嘛：

1.内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务

2.取最新N个数据的操作，如：可以将最新的10条评论ID放在Redis的list集合里面

3.模拟类似于HttpSession这种需要设定过期时间的功能

4.发布，订阅消息系统

5.定时器，计数器

三，怎么玩

1.数据类型，基本操作和配置

2.持久化和复制，RDB/AOF

3.事务的控制

4.复制

二，Redis数据类型

redis键key的命令：

keys *  查看所有的key
exists key的名字  判断某个key是否存在
move key db :移除当前库中的key
expire key 秒钟：为给定的key设置过期时间
ttl key:查看还有多少秒过期，-1表示永不过期  -2表示已过期
type key:查看你的key是什么类型

redis的五大数据类型：

1.String（字符串）单值单value

string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 string类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M

2.Hash KV模式不变，但V是一个键值对

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

3.List 单值多value（命令前面加l）

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

4.Set单值多value（命令前面加s）

Redis的Set是string类型的无序集合。它是通过HashTable实现实现的

5.Zset（在set基础上，加一个score值。之前set是k1 v1 v2 v3，现在zset是k1 score1 v1 score2 v2）

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

三，解析配置文件

参数说明
redis.conf 配置项说明如下：
1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
  daemonize no
2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis监听端口，默认端口为6379
  port 6379
4. 绑定的主机地址
  bind 127.0.0.1
5.当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
  timeout 300
6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
  loglevel verbose
7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
  logfile stdout
8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
  databases 16
9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
  save <seconds> <changes>
  Redis默认配置文件中提供了三个条件：
  save 900 1
  save 300 10
  save 60 10000
  分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
 
10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
  rdbcompression yes
11. 指定本地数据库文件名，默认值为dump.rdb
  dbfilename dump.rdb
12. 指定本地数据库存放目录
  dir ./
13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
  slaveof <masterip> <masterport>
14. 当master服务设置了密码保护时，slav服务连接master的密码
  masterauth <master-password>
15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
  requirepass foobared
16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
  maxclients 128
17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
  maxmemory <bytes>
18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
  appendonly no
19. 指定更新日志文件名，默认为appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日志条件，共有3个可选值： 
  no：表示等操作系统进行数据缓存同步到磁盘（快） 
  always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
  everysec：表示每秒同步一次（折衷，默认值）
  appendfsync everysec
 
21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
   vm-enabled no
22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
   vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
   vm-max-memory 0
24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
   vm-page-size 32
25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
   vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
   vm-max-threads 4
27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
  glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
  activerehashing yes
30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
  include /path/to/local.conf

四，Redis的持久化

一，RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘即Snapshop快照，它恢复时是将快照文件直接读到内存里

Redis会单独创建（fork）一个子进程来进行持久化，会将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这确保了极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效.

但是RDB的缺点是：最后一次持久化后的数据可能丢失

fork：复制一个与当前进程一样的进程，新进程的所有数据（变量，环境变量，程序计数器等）数值都是和原进程一致，但是是一个全新的进程，并作为原进程的子进程

一，如何触发RDB快照：

RDB保存的是在dump.rdb文件内，可以对自动生成的dump.rdb文件进行拷贝后使用

如：cp dump.rdb dump_new.rdb

RDB快照备份可以根据配置文件中配置的参数进行在一段时间内点击量达到多少进行自动备份，也可以使用命令进行备份

（1）save:save只管保存，其他不管，全部阻塞

（2）bgsave:redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间

（3）执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

二，如何恢复：

将备份文件（dump.rdb）移动到redis安装目录并启动服务即可；config get dir 获取目录

三，RDB的优势和劣势

优势：

适合大规模的数据恢复

对数据完整性和一致性要求不高

劣势：

在一定间隔时间做一次备份，所以如果redis意外宕机，就会丢失最后一次快照的所有修改

fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

四，停止

动态停止RDB保存规则的方法：redis-cli config set save " "

五，总结

二，AOF（Append Only File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据（redis重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作）

一，AOF的启动、修复和恢复

AOF保存的是appendonly.aof文件

正常恢复：

启动：修改配置文件，将默认的appendonly no改为yes,将有数据的aof文件复制一份保存到对应目录（config get dir）

恢复：重启redis然后重新加载

异常恢复：

启动：修改配置文件，将默认的appendonly no改为yes,备份被写坏的aof文件

修复：命令：redis -check-aof --fix 要修复的aof文件

恢复：重启redis然后重新加载（如果aof文件是坏的，则启动不了redis）

二，Rewrite

aof采用文件追加方式，文件会越来越大，为避免出现此种情况，新增加了重新机制，当aof文件的大小超过所设定的阈值时，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用bgrewriteaof

重写原理：

aof文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件，最后再rename），遍历新进程的内存中的数据，每条记录一条的set语句，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，与快照类似

触发机制：

Redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64M时触发

三，优势和劣势

优势：

每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失

不同步：appendfsync no 从不同步

劣势：

相同数据集的数据而言aof文件要远大于rdb文件，恢复的速度慢于rdb

aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

四，总结

三，持久化总结

1.RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2.AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

3.只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

4.同时开启两种持久化方式：

（1）在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

（2）RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

5.性能建议

 
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
 
如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
 
如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构

五，Redis的事务

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

作用：

一个队列中，一次性，顺序性，排他性的执行一系列命令

怎么玩：

1.常用的命令：

discard:取消事务，放弃执行事务块内的所有命令

exec：执行所有事务块内的命令

multi:标记一个事务块的开始

unwatch:取消watch命令对所有key的监视

watch key[key …]:监视一个（或多个）key,如果在事务执行之前这些或这个key被其他命令所改动，那么事务将被打断

2，事务的场景：

以multi开启一个事务 ，随后执行的这些命令入队到事务中，不会立即执行，放到等待的事务队列中，由exec命令触发事务

（1）正常执行：multi 开启事务 命令入队。。。 exec提交事务

（2）放弃事务：multi 开启事务 命令入队。。。 discard放弃事务

（3）全体连坐：multi 开启事务 命令入队。。有一个命令发生了错误 ，错误抛出 exec提交事务，全都没有提交成功

（4）冤头债主：multi开启事务 命令入队。。。。exec提交事务时报错，对的执行，错的抛出

（5）watch监控：

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，
乐观锁策略:提交版本必须大于记录当前版本才能执行更新

Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，
比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行

通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，
EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

事务的特性：

1.单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

2.没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题

3.不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

六，Redis的发布订阅

进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息

先订阅后发布后才能收到消息，
1 可以一次性订阅多个，SUBSCRIBE c1 c2 c3

2 消息发布，PUBLISH c2 hello-redis

3 订阅多个，通配符*， PSUBSCRIBE new*
4 收取消息， PUBLISH new1 redis2015

七，Redis的复制（master/Slave）

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

一，作用：

读写分离；容灾恢复

二，怎么玩：

1.配从（库）不配主（主）：在从库中执行命令：slaveof 主库IP 主库端口

2.常用的三种方式：

（1）一主二仆：

1 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?
	主机操作进行一半的时候，从机连接主机进行备份，这是是从头开始复制，复制全部数据
 
2 从机是否可以写？set可否？
	从机不能进行写操作，进行set操作会报错
 
3 主机shutdown后情况如何？从机是上位还是原地待命
		从机是原地待命，等待主机的恢复
 
4 主机又回来了后，主机新增记录，从机还能否顺利复制？
	主机回来后，主机新增记录，从机可以顺利复制
 
5 其中一台从机down后情况如何？依照原有它能跟上大部队吗？
	可以跟上，因为从机的复制是从头开始

（2）薪火相传：

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力

中途变更转向：会清除之前的数据，重新建立拷贝最新的,中间的也是slave从机，从机相当于一个包工头，传达信息，不会变成老板，自己发布信息。

slaveof 新主库IP 新主库端口

（3）反客为主：

执行 slaveof no one命令，使当前数据库停止与其他数据库的同步，转为主数据库，另一个从机会原地待命，如果没有执行更换master的命令，等挂掉的主机恢复，它就会重新连接原来的主机，如果更换了master，原来的主机恢复后就会成为一个独立的master。

（4）哨兵模式：（最常用的）

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

使用步骤：

（1）在自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错

（2）配置哨兵，填写内容：在sentinel.conf这个文件中填写： sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1（1表示主机挂掉后，slave投票看让谁接替称为主机，得票数多的成为主机）

（3）启动哨兵：redis-sentinel 新建的sentinel.conf的全路径名 如（/myredis/sentinel.conf）

(4)原有的主机shutdown ,自动进行选举，选出master。此时从机会自动跟随新的主机，不会和之前反客为主的模式一样，（原地待命，需要手动执行slaveof命令）

（5）如果之前的master重启回来，不会产生双master的冲突（因为原来的主机回来，会变为这个新主机的从机进行工作）

一组sentinel能同时监控多个Master

三，复制原理

1.Slave启动成功后连接到master后会发送一个sync命令

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

3.全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中

4.增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步，但只要是重新来连接master，一次完全同步（全量复制）将被自动执行

缺点：复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。