redis高级应用总结

目录

redis简介

redis选择单线程的原因?

Redis slowlog

Redis常用操作

Redis模糊查询

redis pipeline(管道机制) 

Redis数据类型

Redis HyperLogLog

什么是基数?

Redis HyperLogLog 命令

10 个提升逼格的 Redis 命令

    keys

info

scan

slowlog

rename-command

bigkeys

monitor

redis持久化

持久化有两种方式：

RDB持久化

RDB持久化的缺点

持久化参数配置

RDB持久化也分两种：SAVE和BGSAVE

Aof持久化

开启aof持久化

如何配置AOF

appendfsync有三个选项：always、everysec和no：

Redis的主从复制

Redis主从实例准备

总结

---

redis简介

Redis是用C语言开发的高性能的键值对存储的Nosql数据库，是单进程单线程模型的 KV 数据库

1. redis是一个内存nosql数据库
2. redis中也是存储key-value形式的数据
3. redis中的key-value相比hbase等数据库来说，redis的value比较强大，它的value可以不仅仅是一个byte[]
4. redis的value可以有结构：可以是一个list，也可以是一个hash，也可以是set.....
5. Redis存储的数据类型有五种：字符（string）、散列（hash）、列表（list）、集合(set)、有序集合(sorted set)

redis选择单线程的原因?

1. redis都是对内存的操作，速度极快（10W+QPS）
2. 整体的时间主要都是消耗在了网络的传输上
3. 如果使用了多线程，则需要多线程同步，这样实现起来会变的复杂
4. 线程的加锁时间甚至都超过了对内存操作的时间
5. 多线程上下文频繁的切换需要消耗更多的CPU时间
6. 还有就是单线程天然支持原子操作，而且单线程的代码写起来更简单

redis为何能支持高并发的？

几种 I/O 模型

         为什么 Redis 中要使用 I/O 多路复用这种技术呢？首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

Blocking I/O

          先来看一下传统的阻塞 I/O 模型到底是如何工作的：当使用 read 或者 write 对某一个文件描述符（File Descriptor 以下简称 FD)进行读写时，如果当前 FD 不可读或不可写，整个 Redis 服务就不会对其它的操作作出响应，导致整个服务不可用。

redis 的线程模型

          redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

来看客户端与 redis 的一次通信过程（图片若不清晰，请右击在新标签中打开图片）：

客户端 socket01 向 redis 的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

假设此时客户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。

如果此时客户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok，之后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。这样便完成了一次通信。

IO 多路复用技术

简单的理解下 IO 多路复用技术，假设每个客户端的 IO 请求是一条电路，redis 是一个开关，如下图所示：

在上图中，redis 需要处理 3 个 IO 请求，同时把 3 个请求的结果返回给客户端，所以总共需要处理 6 个 IO 事件，由于 redis 是单线程模型，同一时间只能处理一个 IO 事件，于是 redis 需要在合适的时间暂停对某个 IO 事件的处理，转而去处理另一个 IO 事件，这样 redis 就好比一个开关，当开关拨到哪个 IO 事件这个电路上，就处理哪个 IO 事件，其他 IO 事件就暂停处理了。这就是IO多路复用技术

以上是大致的理解下 IO 多路复用技术，在系统底层，IO 多路复用有 3 种实现机制：

• select
• poll
• epoll

总结一下就是：

epoll 是目前最新的也是最先进的 IO 多路复用的实现解决了select 和 poll 的很多问题。而 redis 就是使用的基于 epoll 的 IO 多路复用技术。

redis使用注意事项

如果有大量的key需要设置同一时间过期，一般需要注意什么？
如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。严重的话会出现缓存雪崩，我们一般需要在时间上加一个随机值，使得过期时间分散一些。

电商首页经常会使用定时任务刷新缓存，可能大量的数据失效时间都十分集中，如果失效时间一样，又刚好在失效的时间点大量用户涌入，就有可能造成缓存雪崩
 

Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？
第一解决方案：使用keys指令可以扫出指定模式的key列表。但是如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。不过，增量式迭代命令也不是没有缺点的： 举个例子， 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素， 但是对于 SCAN 这类增量式迭代命令来说， 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。

Redis slowlog

slowlog是什么

redis的slowlog是redis用于记录记录慢查询执行时间的日志系统(用于查询执行慢的指令信息)。由于slowlog只保存在内存中，因此slowlog的效率很高，完全不用担心会影响到redis的性能。Slowlog是Redis从2.2.12版本引入的一条命令。

redis.conf设置

在redis.conf中有关于slowlog

slowlog-log-slower-than 10000
slowlog-max-len 128

其中slowlog-log-slower-than表示slowlog的划定界限，只有query执行时间大于slowlog-log-slower-than的才会定义成慢查询，才会被slowlog进行记录。slowlog-log-slower-than设置的单位是微妙，默认是10000微妙，也就是10ms 
slowlog-max-len表示慢查询最大的条数，当slowlog超过设定的最大值后，会将最早的slowlog删除，是个FIFO队列

Redis常用操作

查看redis的连接数

127.0.0.1:6379> info clients

查看redis的集群信息

127.0.0.1:6379> info

 移除给定key的生存时间(设置这个key永不过期)

jedis.persist("key1"); 

 检查给定key是否存在

jedis.exists("key1");

将key改名为newkey,当key和newkey相同或者key不存在时,返回一个错误

jedis.rename("key1", "key2");

 返回key所储存的值的类型。 

 none(key不存在),string(字符串),list(列表),set(集合),zset(有序集),hash(哈希表)

jedis.type("key1");

 设置key生存时间，当key过期时，它会被自动删除。

jedis.expire("key1", 5); 5秒过期 

清空所有的key

jedis.flushAll();

redis的key和string类型value限制均为512MBredis的key和value的大小

redis内存缓存清除

 FLUSHALL命令的基本语法如下所示：

redis 127.0.0.1:6379> FLUSHALL  

FLUSHDB  命令的基本语法如下所示：

在某个db环境下执行删除的话，只删除当前db的数据

Redis模糊查询

在redis里,允许模糊查询key
有3个通配符 *, ? ,[] 
*: 通配任意多个字符 
?: 通配单个字符 
[]: 通配括号内的某1个字符

注意：实际开发中 禁止使用key*进行模糊查询，不然会导致redis占用cpu快速升高导致redis自锁，无法使用。

redis pipeline(管道机制) 

　　           大多数情况下，我们都会通过请求-相应机制去操作redis。只用这种模式的一般的步骤是，先获得jedis实例，然后通过jedis的get/put方法与redis交互。由于redis是单线程的，下一次请求必须等待上一次请求执行完成后才能继续执行。然而使用Pipeline模式，客户端可以一次性的发送多个命令，无需等待服务端返回。这样就大大的减少了网络往返时间，提高了系统性能。

下面用一个例子测试这两种模式在效率上的差别：　数据批量写入redis　

public class PiplineTest {
    private static int count = 10000;
    public static void main(String[] args){
        useNormal();
        usePipeline();
    }
    public static void usePipeline(){
         ShardedJedis jedis = getShardedJedis();
         ShardedJedisPipeline pipeline = jedis.pipelined();
        long begin = System.currentTimeMillis();
        for(int i = 0;i

输出结果：

useNormal total time:772
usePipeline total time:112

1.pipelined.sync()表示我一次性的异步发送到redis，不关注执行结果。
2.pipelined.syncAndReturnAll()程序会阻塞，等到所有命令执行完之后返回一个List集合。
3.pipeline也不适合组装特别多的命令，因此如果是成千上万的这种命令，我们还是要进行命令的拆分。

数据批量查redis：通过user_id获取用户信息 500个请求一次redis

//获取pipline实例 
Pipeline pipeline = jedis.pipelined();
//定义一个list控制请求的数量 
 ArrayList  list = new ArrayList<>();
    list.add(user_id);
        if(list.size()==500){
            for (String u_id:list) {
                Response abtExp = pipeline.hget("mryx_abt_exp", u_id);
                String user_info= abtExp.get();
                剩下的和普通一条操作是一样的
              。。。。。。。
            }
        }
触发redis批量请求
pipeline.sync();
map.clear();

Redis数据类型

redis里存的都是二进制数据，其实就是字节数组（byte[]）

Redis中存储数据是通过key-value存储的，对于value的类型有以下几种：

• 字符串
• Hash类型
• List
• Set
• SortedSet（zset）

在redis中的命令语句中，命令是忽略大小写的，而key是不忽略大小写的。

Redis HyperLogLog

              Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数?

比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。

Redis HyperLogLog 命令

下表列出了 redis HyperLogLog 的基本命令：

1	PFADD key element [element ...]  添加指定元素到 HyperLogLog 中。
2	PFCOUNT key [key ...]  返回给定 HyperLogLog 的基数估算值。
3	PFMERGE destkey sourcekey [sourcekey ...]  将多个 HyperLogLog 合并为一个 HyperLogLog

10 个提升逼格的 Redis 命令

    keys

                   我把这个命令放在第一位，是因为笔者曾经做过的项目，以及一些朋友的项目，都因为使用keys这个命令，导致出现性能毛刺。这个命令的时间复杂度是O(N)，而且redis又是单线程执行，在执行keys时即使是时间复杂度只有O(1)例如SET或者GET这种简单命令也会堵塞，从而导致这个时间点性能抖动，甚至可能出现timeout。强烈建议生产环境屏蔽keys命令（后面会介绍如何屏蔽）。

info

        redis 提供info这个命令来查看redis运行的信息。一般比较关注的是内存信息，连接总数，可以通过info memory来查看内存使用情况

server : 一般 Redis 服务器信息，包含以下域：

redis_version : Redis 服务器版本
redis_git_sha1 : Git SHA1
redis_git_dirty : Git dirty flag
os : Redis 服务器的宿主操作系统
arch_bits : 架构（32 或 64 位）
multiplexing_api : Redis 所使用的事件处理机制
gcc_version : 编译 Redis 时所使用的 GCC 版本
process_id : 服务器进程的 PID
run_id : Redis 服务器的随机标识符（用于 Sentinel 和集群）
tcp_port : TCP/IP 监听端口
uptime_in_seconds : 自 Redis 服务器启动以来，经过的秒数
uptime_in_days : 自 Redis 服务器启动以来，经过的天数
lru_clock : 以分钟为单位进行自增的时钟，用于 LRU 管理

clients : 已连接客户端信息，包含以下域：

connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）
client_longest_output_list : 当前连接的客户端当中，最长的输出列表
client_longest_input_buf : 当前连接的客户端当中，最大输入缓存
blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量

memory : 内存信息，包含以下域：

注意：used_memory包含了redis进程内部的开销和数据占用的内存，以字节（byte）为单位

used_memory：由 Redis 分配器分配的内存总量，包含了redis进程内部的开销和数据占用的内存，以字节（byte）为单位
used_memory_human：以更直观的可读格式显示返回使用的内存量。
used_memory_rss：rss是Resident Set Size的缩写,表示该进程所占物理内存的大小,是操作系统分配给Redis实例的内存大小。
used_memory_rss_human：以更直观的可读格式显示该进程所占物理内存的大小。
used_memory_peak：redis的内存消耗峰值(以字节为单位)
used_memory_peak_human：以更直观的可读格式显示返回redis的内存消耗峰值
used_memory_peak_perc：使用内存达到峰值内存的百分比，即(used_memory/ used_memory_peak) *100%
used_memory_overhead：Redis为了维护数据集的内部机制所需的内存开销，包括所有客户端输出缓冲区、查询缓冲区、AOF重写缓冲区和主从复制的backlog。
used_memory_startup：Redis服务器启动时消耗的内存
used_memory_dataset：数据占用的内存大小，即used_memory-used_memory_overhead
used_memory_dataset_perc：数据占用的内存大小的百分比，100%*(used_memory_dataset/(used_memory-used_memory_startup))
total_system_memory：整个系统内存
total_system_memory_human：以更直观的可读格式显示整个系统内存
used_memory_lua：Lua脚本存储占用的内存
used_memory_lua_human：以更直观的可读格式显示Lua脚本存储占用的内存
maxmemory：Redis实例的最大内存配置
maxmemory_human：以更直观的可读格式显示Redis实例的最大内存配置
maxmemory_policy：当达到maxmemory时的淘汰策略
mem_fragmentation_ratio：内存的碎片率，used_memory_rss/used_memory   --4.0版本之后可以使用memory purge手动回收内存
mem_allocator：内存分配器
active_defrag_running：表示没有活动的defrag任务正在运行，1表示有活动的defrag任务正在运行（defrag:表示内存碎片整理）
lazyfree_pending_objects: 表示redis执行lazy free操作,在等待被实际回收内容的键个数

scan

                  既然keys命令不允许使用，那么有什么代替方案呢？有！那就是scan命令。如果把keys命令比作类似select * from users where username like '%afei%'这种SQL，那么scan应该是select * from users where id>? limit 10这种命令。

官方文档用法如下：

SCAN cursor [MATCH pattern] [COUNT count]

初始执行scan命令例如scan 0。SCAN命令是一个基于游标的迭代器。这意味着命令每次被调用都需要使用上一次这个调用返回的游标作为该次调用的游标参数，以此来延续之前的迭代过程。当SCAN命令的游标参数被设置为0时，服务器将开始一次新的迭代，而当redis服务器向用户返回值为0的游标时，表示迭代已结束，这是唯一迭代结束的判定方式，而不能通过返回结果集是否为空判断迭代结束。

127.0.0.1:6380> scan 0
1) "22"
2)  1) "23"
    2) "20"
    3) "14"
    4) "2"
    5) "19"

返回结果分为两个部分：第一部分即1)就是下一次迭代游标，第二部分即2)就是本次迭代结果集。

slowlog

                       上面提到不能使用keys命令，如果就有开发这么做了呢，我们如何得知？与其他任意存储系统例如mysql，mongodb可以查看慢日志一样，redis也可以，即通过命令slowlog。用法如下：

SLOWLOG subcommand [argument]

subcommand主要有：

get，用法：slowlog get [argument]，获取argument参数指定数量的慢日志。
len，用法：slowlog len，总慢日志数量。
reset，用法：slowlog reset，清空慢日志。

rename-command

               为了防止把问题带到生产环境，我们可以通过配置文件重命名一些危险命令，例如keys等一些高危命令。操作非常简单，只需要在conf配置文件增加如下所示配置即可：

bigkeys

        随着项目越做越大，缓存使用越来越不规范。我们如何检查生产环境上一些有问题的数据。bigkeys就派上用场了，用法如下：

redis-cli -p 6380 --bigkeys

执行结果如下：

Sampled 526 keys in the keyspace!
Total key length in bytes is 1524 (avg len 2.90
Biggest string found 'test' has 10005 bytes
Biggest   list found 'commentlist' has 13 items
524 strings with 15181 bytes (99.62% of keys, avg size 28.97)
2 lists with 19 items (00.38% of keys, avg size 9.50)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

最后5行可知，没有set,hash,zset几种数据结构的数据。string类型有524个，list类型有两个；通过Biggest ... ...可知，最大string结构的key是test，最大list结构的key是commentlist。

需要注意的是，这个bigkeys得到的最大，不一定是最大。说明原因前，首先说明bigkeys的原理，非常简单，通过scan命令遍历，各种不同数据结构的key，分别通过不同的命令得到最大的key：

如果是string结构，通过strlen判断；
如果是list结构，通过llen判断；
如果是hash结构，通过hlen判断；
如果是set结构，通过scard判断；
如果是sorted set结构，通过zcard判断。

正因为这样的判断方式，虽然string结构肯定可以正确的筛选出最占用缓存，也可以说最大的key。但是list不一定，例如，现在有两个list类型的key，分别是：numberlist--[0,1,2]，stringlist--["123456789123456789"]，由于通过llen判断，所以numberlist要大于stringlist。而事实上stringlist更占用内存。其他三种数据结构hash，set，sorted set都会存在这个问题。使用bigkeys一定要注意这一点。

monitor

                         假设生产环境没有屏蔽keys等一些高危命令，并且slowlog中还不断有新的keys导致慢日志。那我们如何揪出这些命令是由谁执行的呢？这就是monitor的用处，用法如下：

redis-cli -p 6380 monitor

如果当前redis环境OPS比较高，那么建议结合linux管道命令优化，只输出keys命令的执行情况：

redis-cli -p 6380 monitor | grep key
1532645266.656525 [0 10.0.0.1:43544] "keyss" "*"

执行结果中很清楚的看到keys命名执行来源。通过输出的IP和端口信息，就能在目标服务器上找到执行这条命令的进程，揪出元凶，勒令整改。

如果redis的key或value是汉字的时候，进行命令行查询的时候，不是明文的。连接redis客户端的时候，需要添加  --raw

redis-cli  -h 127.0.0.1  -p 6379  -a hNzcJeGzpJBUhR --raw

redis持久化

               redis的数据是存储在内存中，如果一旦服务器挂掉，内存中的会丢失，所以需要对内存中的数据进行持久化，通俗的讲就是将内存中的数据写入硬盘中。

持久化有两种方式：

1. Rdb：快照
2. Aof：append only file(aof)里面(这称为“全持久化模式”)

Rdb是默认支持的。在实际的生产环境中，不建议使用该模式。

RDB持久化

             RDB方式的持久化是通过快照（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。RDB是Redis默认采用的持久化方式。可以在redis.conf配置文件中配置持久化的相关参数。

RDB持久化的缺点

通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。

持久化参数配置

在redis.conf配置文件中默认有此下配置：

save 开头的一行就是持久化配置，可以配置多个条件（每行配置一个条件），每个条件之间是“或”的关系。也就是只要有一条条件满足就会进行数据的持久化

“save 900 1”表示15分钟（900秒钟）内至少1个键被更改则进行快照。

“save 300 10”表示5分钟（300秒）内至少10个键被更改则进行快照。

[redis@6381]$ more /usr/local/redis/conf/redis.conf
save 900 1
save 300 10
save 60 10000
dbfilename "dump.rdb"          #持久化文件名称
dir "/data/dbs/redis/6381"    #持久化数据文件存放的路径

上面是redis配置文件里默认的RDB持久化设置，前三行都是对触发RDB的一个条件，例如第一行的意思是每900秒钟里redis数据库有一条数据被修改则触发RDB，依次类推；只要有一条满足就会调用BGSAVE进行RDB持久化。第四行dbfilename指定了把内存里的数据库写入本地文件的名称，该文件是进行压缩后的二进制文件，通过该文件可以把数据库还原到生成该文件时数据库的状态。第五行dir指定了RDB文件存放的目录。

      配置文件修改需要重启redis服务，我们还可以在命令行里进行配置，即时生效，服务器重启后需重新配置

[redis@iZ254r8s3m6Z redis]$ bin/redis-cli127.0.0.1:6379> CONFIG GET save        
 #查看redis持久化配置1) "save"2) "900 1 300 10 60 10000"
127.0.0.1:6379> CONFIG SET save "21600 1000" #修改redis持久化配置

RDB持久化也分两种：SAVE和BGSAVE

      SAVE 

是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件（即上面的dump.rdb）中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。

      BGSAVE

属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。（本人在生产中就碰到过这问题，redis本身内存使用率就60%，总的内存使用率在百分之七八十左右，持久化的时候立马飙到百分之一百三十多，告警邮件是每天几十封/(ㄒoㄒ)/~~ 最后根据需求选择了AOF持久化）

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费20～30秒钟。

如果需要对数据进行完整持久化，那么需要使用aof方式进行持久化。

Aof持久化

          通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。

开启aof持久化

默认情况下，aof持久化是不开启的。

与RDB的保存整个redis数据库状态不同，AOF是通过保存对redis服务端的写命令（如set、sadd、rpush）来记录数据库状态的，即保存你对redis数据库的写操作，以下就是AOF文件的内容

redis@iZ]$ more appendonly.aof

*2
 $6
 SELECT
 $1
 0
 *3
 $3
 SET

如何配置AOF

[redis@iZ]$ more ~/redis/conf/redis.conf

 dir "/data/dbs/redis/6381"           #AOF文件存放目录
 appendonly yes                       #开启AOF持久化，默认关闭
 appendfilename "appendonly.aof"      #AOF文件名称（默认）
 appendfsync no                       #AOF持久化策略
 auto-aof-rewrite-percentage 100      #触发AOF文件重写的条件（默认）
 auto-aof-rewrite-min-size 64mb       #触发AOF文件重写的条件（默认）

            要弄明白上面几个配置就得从AOF的实现去理解，AOF的持久化是通过命令追加、文件写入和文件同步三个步骤实现的。当reids开启AOF后，服务端每执行一次写操作（如set、sadd、rpush）就会把该条命令追加到一个单独的AOF缓冲区的末尾，这就是命令追加；然后把AOF缓冲区的内容写入AOF文件里。看上去第二步就已经完成AOF持久化了那第三步是干什么的呢？这就需要从系统的文件写入机制说起：一般我们现在所使用的操作系统，为了提高文件的写入效率，都会有一个写入策略，即当你往硬盘写入数据时，操作系统不是实时的将数据写入硬盘，而是先把数据暂时的保存在一个内存缓冲区里，等到这个内存缓冲区的空间被填满或者是超过了设定的时限后才会真正的把缓冲区内的数据写入硬盘中。也就是说当redis进行到第二步文件写入的时候，从用户的角度看是已经把AOF缓冲区里的数据写入到AOF文件了，但对系统而言只不过是把AOF缓冲区的内容放到了另一个内存缓冲区里而已，之后redis还需要进行文件同步把该内存缓冲区里的数据真正写入硬盘上才算是完成了一次持久化。而何时进行文件同步则是根据配置的appendfsync来进行：

appendfsync有三个选项：always、everysec和no：

1、选择always的时候服务器会在每执行一个事件就把AOF缓冲区的内容强制性的写入硬盘上的AOF文件里，可以看成你每执行一个redis写入命令就往AOF文件里记录这条命令，这保证了数据持久化的完整性，但效率是最慢的，却也是最安全的；

2、配置成everysec的话服务端每执行一次写操作（如set、sadd、rpush）也会把该条命令追加到一个单独的AOF缓冲区的末尾，并将AOF缓冲区写入AOF文件，然后每隔一秒才会进行一次文件同步把内存缓冲区里的AOF缓存数据真正写入AOF文件里，这个模式兼顾了效率的同时也保证了数据的完整性，即使在服务器宕机也只会丢失一秒内对redis数据库做的修改；

3、配置成no则意味redis数据库里的数据就算丢失你也可以接受，它也会把每条写命令追加到AOF缓冲区的末尾，然后写入文件，但什么时候进行文件同步真正把数据写入AOF文件里则由系统自身决定，即当内存缓冲区的空间被填满或者是超过了设定的时限后系统自动同步。这种模式下效率是最快的，但对数据来说也是最不安全的，如果redis里的数据都是从后台数据库如mysql中取出来的，属于随时可以找回或者不重要的数据，那么可以考虑设置成这种模式。

Redis的主从复制

          Redis的主从复制是解决单点故障问题，可以通过redis的高可用（HA）。主从复制，则需要两个redis实例。把两个redis实例放到两个服务器中。模拟实现，可以在一台服务中启动两个实例。

 Redis主从拓扑

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响 

 

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

 

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

 

3. 主从复制原理

 

4. 数据同步

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制
全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）
部分复制：网络出现问题，从节点再次连接主节点时，主节点补发缺少的数据，每次数据增量同步
心跳：主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

5. 主从的缺点

a)主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
b)主从复制主节点的写能力单机，能力有限
c)单机节点的存储能力也有限

6.主从故障如何故障转移

a)主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
b)其它的节点成为新主节点的从节点，并从新节点复制数据；
c)需要人工干预，无法实现高可用。

Redis主从实例准备

第一步：复制一个redis实例

# cd /usr/local/redis
# cp -r bin/ ./bin2

第二步：修改端口

其中：6379服务器会是主redis，而6380会是从redis

主redis:无需配置

从redis:将slaveof 指定主redis的ip和端口

启动主redis和从redis

# bin/redis-server bin/redis.conf
# bin2/redis-server bin2/redis.conf

总结

主redis中存储的数据，在从redis中会进行同步。

主redis可以进行写操作，而从redis只是只读的。

reds集群模式

1. 主从复制
2. 哨兵模式
3. Redis官方提供的Cluster集群模式(服务端)
4. Jedis sharding集群(客户端sharding)
5. 利用中间件代理，比如豌豆荚的codis等

哨兵模式

          该模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来，无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。

Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。

Redis哨兵机制（Sentinel）

1. 为什么要有哨兵机制？

       哨兵机制的出现是为了解决主从复制的缺点的

2. 哨兵机制(sentinel)的高可用

　　原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

3. 哨兵的定时监控任务

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到

任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的

 任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据

客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线

 

4. 领导者哨兵选举流程

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

 

5. 故障转移机制

a)由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

 

 

 b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

 

 c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

 

 流程：

　　  1. 将slave-1脱离原从节点，升级主节点，

         2. 将从节点slave-2指向新的主节点

         3. 通知客户端主节点已更换

         4. 将原主节点（oldMaster）变成从节点，指向新的主节点

 d) 故障转移后的redis sentinel的拓扑结构图

6. 哨兵机制－故障转移详细流程-确认主节点

a) 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点

b) 选择salve-priority从节点优先级最高（redis.conf）的

c) 选择复制偏移量最大，指复制最完整的从节点

Redis官方 Cluster集群模式

      Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。采用虚拟槽分区实现数据的均分布到各个节点，而且可以动态的添加节点和删除节点。

虚拟槽分区原理

      虚拟槽分区利用了哈希空间，使用分散良好的哈希函数把所有的数据映射到一个固定范围的整数集合中，这个整数集合定义为槽（slot），这个整数范围远远大于redis集群节点的个数，这样的目的是方便数据的拆分和集群的扩展，每个节点都会负责一定数量的槽

在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。

Redis集群数据分片

                在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

还有就是因为如果集群的话，是有好多个redis一起工作的，那么，就需要这个集群不是那么容易挂掉，所以呢，理论上就应该给集群中的每个节点至少一个备用的redis服务。这个备用的redis称为从节点（slave）。那么这个集群是如何判断是否有某个节点挂掉了呢？

首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。

它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入发力了状态。这就是我们的redis的投票机制投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉.

什么时候整个集群不可用(cluster_state:fail)?

           如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
Redis 3.0的集群方案有以下两个问题。

一个Redis实例具备了“数据存储”和“路由重定向”，完全去中心化的设计。这带来的好处是部署非常简单，直接部署Redis就行，不像Codis有那么多的组件和依赖。但带来的问题是很难对业务进行无痛的升级，如果哪天Redis集群出了什么严重的Bug，就只能回滚整个Redis集群。
对协议进行了较大的修改，对应的Redis客户端也需要升级。升级Redis客户端后谁能确保没有Bug？而且对于线上已经大规模运行的业务，升级代码中的Redis客户端也是一个很麻烦的事情。
Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

Jedis sharding集群
Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式，其主要思想是采用hash算法将存储数据的key进行hash散列，这样特定的key会被定为到特定的节点上。

庆幸的是，Java Redis客户端驱动Jedis已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool

Jedis的Redis Sharding实现具有如下特点：

                采用一致性哈希算法，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。
为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。

利用中间件代理

           中间件的作用是将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点，将这些数据存在这个redis的节点中。

常用的中间件有这几种

Twemproxy
Codis
nginx
具体用法就不赘述了，可以自行百度。

扫一扫加入大数据公众号，了解更多大数据技术，还有免费资料等你哦

扫一扫加入大数据公众号，了解更多大数据技术，还有免费资料等你哦

扫一扫加入大数据公众号，了解更多大数据技术，还有免费资料等你哦