分布式 第二章 Redis

---

1 NoSql 简介

数据库应用的发展历程：

• 单机数据库时代
• 缓存、水平切分时代（Memcached）
• 读写分离时代
• 分表分库时代(集群)
• nosql时代

关系型数据库：oracle、mysql、DB2、sqlserver…

非关系型数据库(NoSql)： 彻底改变底层存储机制。不再采用关系数据模型，而是采用聚合数据结构存储数据。例如： redis、mongoDB、HBase、…

2 Redis简介

Redis【Remote Dictionary Server】(远程字典服务器)是一个用C语言编写的、开源的、基于内存运行并支持持久化的、高性能的NoSQL数据库。

Redis中的数据大部分时间都是存储内存中的，适合存储频繁访问、数据量比较小的数据。

Redis的特点：

• 支持数据持久化 将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
• 支持多种数据结构 key-value，list，set，zset，hash等数据结构
• 支持数据备份 master-slave模式

Redis客户端
Redis客户端通过网络连接到Redis服务器，从而实现跟 Redis服务器的交互

1.启动Redis客户端：

1)直接连接redis (默认ip127.0.0.1，端口6379)：redis-cli
2)指定IP和端口连接redis：redis-cli –h 127.0.0.1 -p 6379
-h redis主机IP（可以指定任意的redis服务器）
-p端口号（不同的端口表示不同的redis应用）

2.退出Redis客户端：exit或者quit指令

Redis基本知识

1）测试Redis性能
Redis-benchmark
2）Redis沟通命令，查看状态
ping 返回PONG表示redis服务运行正常
3）查看redis服务器的统计信息：info
4）redis默认使用16个库
5）切换库命令：select db
默认使用第0个，如果要使用其他数据库，命令是 select index
6）查看当前数据库中key的数目：dbsize
7）查看当前数据库中有哪些key：keys *
8）清空当前库：flushdb
9）清空所有数据库：flushall
10）config get * 获得redis的所有配置值

Redis的5种数据结构

• 字符串类型 string 能存储任何类型的数据 最大512M
• 列表类型 list 按照插入顺序排序，元素可以重复 底层是链表
• 集合类型 set string类型的无序无重复集合
• 哈希类型 hash 一个string类型的field和value的映射表，hash特别适合用于存储对象
• 有序集合类型 zset zset的每个元素都会关联一个分数（分数可以重复），redis通过分数来为集合中的成员进行从小到大的排序

3 Redis的常用操作命令

key

keys、exists、move、ttl、expire、type、rename、del

string

set、get、append、strlen、incr、decr、incrby、decrby、getrange、setrange、setex、setnx、mget、mset、msetnx

list

lpush、rpush、lrange、lpop、rpop、lindex、llen、lrem、ltrim、lset、linsert

set

sadd、smembers、sismember、scard、srem、srandmember、spop、smove、sdiff、sinter、sunion

hash

hset、hget、hmset、hmget、hgetall、hdel、hlen、hexists、hkeys、hvals、hincrby、hincrbyfloat、hsetnx

Zset

zadd、zrange、zrangebyscore、zrem、zcard、zcount、zrank、zscore、zrevrank、zrevrange、zrevrangebyscore

4 Redis的配置文件

redis.conf存放位置：
Redis的安装根目录下(/opt/redis-5.0.2)，Redis在启动时会加载这个配置文件，在运行时按照配置进行工作。 这个文件有时候我们会拿出来，单独存放在某一个位置，启动的时候必须明确指定使用哪个配置文件，此文件才会生效。

网络相关配置
常规配置
安全配置
RDB配置
AOF配置

5 Redis的持久化

redis是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当redis所在服务器发生宕机后，redis数据库里的所有数据将会全部丢失。
为了解决这个问题，redis提供了持久化功能——RDB和AOF。

RDB

RDB（Redis DataBase）是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis重启会通过加载dump.rdb文件来恢复数据。

RDB原理：Redis会复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，来进行持久化。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

手动保存RDB快照：save命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。由于save指令会阻塞所有客户端，所以保存数据库的任务通常由 BGSAVE 命令异步地执行，而save作为保存数据的最后手段来使用，当负责保存数据的后台子进程不幸出现问题时使用。

RDB数据恢复：通过脚本将Redis产生的dump.rdb文件备份(cp dump.rdb dump_bak.rdb)，每次启动Redis前，把备份的dump.rdb文件替换到Redis相应的目录(在redis.conf中配的的dir目录)下，Redis启动时会加载dump.rdb文件，并且把数据读到内存中。

AOF

AOF(Append Only File)，Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF保存的文件：AOF保存的文件是appendonly.aof文件 ,位置保存在Redis的启动目录。如果开启了AOF，Redis每次记录写操作都会往appendonly.aof文件追加新的日志内容。

AOF数据恢复：通过脚本将Redis产生的appendonly.aof文件备份(cp appendonly.aof appendonly_bak.aof)，每次启动Redis前，把备份的appendonly.aof文件替换到Redis相应的目录(在redis.conf中配的的dir目录)下，只要开启AOF的功能，Redis每次启动，会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。会把出现异常的部分往后所有写操作日志去掉。

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

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

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。当然，也可以在配置文件中进行配置。

小结

Redis 需要手动开启AOF持久化方式，AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

关于Redis持久化的使用：若只打算用Redis 做缓存，可以关闭持久化。若打算使用Redis 的持久化，建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

AOF与RDB模式可以同时启用，这并不冲突。如果AOF是可用的，那Redis启动时将自动加载AOF，这个文件能够提供更好的持久性保障。

6 Redis的事务

Redis的事务允许在一次单独的步骤中执行一组命令，并且能够保证将一个事务中的所有命令序列化，然后按顺序执行；
在一个Redis事务中，Redis要么执行其中的所有命令，要么什么都不执行。即Redis的事务要能够保证序列化和原子性。

Redis事务的常用命令：
multi、exec、discard、watch、unwatch

事务小结：

1. 单独的隔离操作：事务中的所有命令都会序列化、顺序地执行。事务在执行过程中，不会被其它客户端发来的命令请求所打断，除非使用watch命令监控某些键。
2. 不保证事务的原子性：redis同一个事务中如果一条命令执行失败，其后的命令仍然可能会被执行，redis的事务没有回滚。Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。

7 消息的发布与订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道。

Redis发布订阅的常用命令：
subscribe、publish、psubscribe

8 Redis的主从复制

主从复制

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

一主二从

原理：
1、配从(库)不配主(库)
2、配从(库): slaveof 主库IP 主库端口
3、主写从读、读写分离
4、从连前后同
5、主断从待命、从断重新连

复制原理

全量复制：
slave启动成功连接到master后会发送一个sync命令；Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步；slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
只要是重新连接master,一次完全同步（全量复制)将被自动执行。

增量复制：
Master将新的所有收集到的修改命令依次传给slave,完成同步。

哨兵模式

原理：从机上位的自动版。Redis提供了哨兵的命令，哨兵命令是一个独立的进程，哨兵通过发送命令，来监控主从服务器的运行状态，如果检测到master故障了根据投票数自动将某一个slave转换master，然后通过消息订阅模式通知其它slave，让它们切换主机。然而，一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多哨兵进行监控。

小结

操作：
1 查看主从复制关系命令：info replication
2 设置主从关系命令：slaveof 主机ip 主机port
3 开启哨兵模式命令：./redis-sentinel sentinel.conf
4 主从复制原则：开始是全量复制，之后是增量复制
5 哨兵模式三大任务：监控，提醒，自动故障迁移

缺点：
Redis的主从复制最大的缺点就是延迟，主机负责写，从机负责备份，这个过程有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，从机器数量的增加也会使这个问题更加严重。

9 Jedis操作Redis

使用Redis官方推荐的Jedis，在java应用中操作Redis。
Jedis几乎涵盖了Redis的所有命令。
操作Redis的命令在Jedis中以方法的形式出现。

---

传送门

上一章：分布式 第一章 Dubbo
下一章：分布式 第三章 Maven多模块管理