Redis学习总结（数据类型、持久化、事务、数据删除策略、主从复制、哨兵、缓存雪崩等）

1.Redis是什么

1、概念

redis是一个由C语言开发的高性能基于键值对存储的内存数据库。

2、特点

1、数据间没有必然的关联关系
2、内部采用单线程机制进行工作
3、数据存储在内存中，读写性能高
4、多数据类型支持：string、list、hash、set、sorted_set
5、持久化支持，可以进行数据灾难恢复

3、应用场景

1、为热点数据加速查询，如热点商品、热点新闻、热点资讯、推广类等
2、任务队列，如秒杀、抢购、购票排队等
3、即时信息查询，如排行耪、网站访问量统计、公交到站信息等
4、时效性信息控制，如验证码等
5、消息队列
6、分布式锁

2.Linux环境安装redis

主要记录在centos7下直接安装，不适用docker。
1、下载解压安装包

wget http://download.redis.io/releases/redis-4.0.0.tar.gz
tar -xvf redis-4.0.0.tar.gz 

2、编译并安装
直接make操作时会出现错误

致命错误：jemalloc/jemalloc.h：没有那个文件或目录

因为使用MALLOC去创建redis时，默认的分配器为jemalloc<没有jemalloc分配器需要指定libc分配器，解决方法 ：

make MALLOC=lib

3、启动redis服务器
进入redis/src目录下

./redis-server

4、启动客户端
进入redis/src目录下

./redis-cli

5、修改redis端口并启动服务器

redis-server --port 6380

6、启动修改后的端口号的redis

redis-cli  -p  6380

7、自定义配置文件启动
将配置文件复制一份，并删掉注释和空白

cat redis.conf |grep -v "#"|grep -v "^$"  >redis-6379.conf

自定义配置文件

# 设定当前服务启动端口号 
port 6379
#以守护进程方式启动，redis以服务形式存在，日志不在打印到命令窗口
daemonize yes
#设置日志文件名，便于查阅
logfile "6379.log"
#设定当前服务文件保存位置，包含日志文件、持久化文件等
dir /redis-4.0.0/data

8、启动指定配置文件的redis服务器和客户端:

redis-server conf/redis-6379.conf
redis-server conf/redis-6380.conf

9、启动修改后的端口号的redis

redis-cli  -p  6379
redis-cli  -p  6380

3.Redis的数据存储格式

redis自身是一个Map，其中所有的数据都是采用key:value的形式存储。数据类型指的是value存储的值的数据类型，key一直是字符串value常用的有String、Map、List、Set和Sort_Set。此外还有三种特殊的数据类型，分别为BitMap、GEO和HyperLogLog。

1、String类型

存储的数据为单个数据，一个存储空间保存一个数据，通常使用字符串，如果字符串以整数的形式存储，可以作为数字操作使用。数据的最大存储量为512,数值计算的最大范围跟Long相同。

1、String类型的常用操作

• 添加/修改数据

   set key value

• 添加/修改多个数据

   mset key1 value1 key2 value2 ...

• 递增数字（相当于java中的i++，操作的value必须是数字，同时也有递减decr/decrby操作）

   incr key 

• 按照value值递增数字（value值可以为负）

   incrby key value

• 按照value值递增数字，浮点型，（value值可以为负）

   incrbyfloat key value

• 获取数据

   get key

• 获取多个数据

   mget key1 key2 ...

• 获取数据字符个数（字符串长度）

   strlen key

• 追加信息到原始信息后面（原始信息存在就追加，否则新建）

   append key value

• 删除数据

   del key

演示String类型的基本操作

127.0.0.1:6379> set name tcc
OK
127.0.0.1:6379> mset name tcc age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> incrby age 5
(integer) 24
127.0.0.1:6379> get name
"tcc"
127.0.0.1:6379> mget name age
1) "tcc"
2) "24"
127.0.0.1:6379> strlen name
(integer) 3
127.0.0.1:6379> append name nice
(integer) 7
127.0.0.1:6379> get name
"tccnice"
127.0.0.1:6379> del name
(integer) 1
127.0.0.1:6379> get name
(nil)

2、String类型常用的业务场景

1、在Mysql数据库分表操作后，使用多张表存储同类型数据，对应的主键id必须保证统一性，不能重复，可以使用Redis的incr key来控制主键ID，保障数据库表的主键唯一性，因为Redis操作都是原子性的，采用单线程处理业务，无需考虑并发代来的数据影响。
2、需要设定数据的生命周期，比如某篇新闻3天内为热门新闻，这种需要保持时效性的场景，可以设置数据具有指定的生命周期。设置数据key的有效时间为value秒/毫秒

	setex key seconds value
	psetex key milliseconds value

3、可以用于经常改变的高热度数据的访问和修改，如网站访问量等。

2、Hash类型

对一系列存储数据进行编组，方便管理，比如存储对象信息。一个存储空间保存多个键值对数据，底层使用哈希表结构实现数据存储。

1、常用的Hash操作

• 添加/修改数据

   hset key field value

• 添加/修改多个数据

   hmset key field1 value1 field2 value2

• 获取数据

   hget key field  
   hgetall key

• 获取哈希表中所有的字段名或者字段值

   hkeys key   
   hvals key

• 获取多个数据

   hmget key field1 field2 ...

• 获取哈希表中字段的数量

   hlen key

• 获取哈希表中是否存在指定的字段

   hexists key field

• 设置指定字段的数值数据增加指定范围的值

   hincrby key field increment
   hincrbyfloat key filed increment

• 删除数据

   hdel key field1 field2 ...

演示Hash类型的基本操作

127.0.0.1:6379> hset user name tcc
(integer) 0
127.0.0.1:6379> hmset user age 20 sex man
OK
127.0.0.1:6379> hget user name
"tcc"
127.0.0.1:6379> hgetall user
1) "name"
2) "tcc"
3) "age"
4) "20"
5) "sex"
6) "man"
127.0.0.1:6379> hmget user name age
1) "tcc"
2) "20"
127.0.0.1:6379> hexists user sex
(integer) 1
127.0.0.1:6379> hincrby user age 5
(integer) 25
127.0.0.1:6379> hkeys user
1) "name"
2) "age"
3) "sex"
127.0.0.1:6379> hvals user
1) "tcc"
2) "25"
3) "man"
127.0.0.1:6379> hdel user name sex
(integer) 2

2、注意事项

• hash类型下的value只能存储字符串，不郧西其他数据类型，不存在嵌套现象。
• hash类型十分贴近对象的数据存储形式，并且可以灵活的添加删除对象属性，但是hash并不是为了存储大量对象而设计的，不可滥用。
• hgetall操作可以获取全部属性，如果内部field过多，遍历数据效率很低，影响性能。

3、Hash类型常用的业务场景

1、在购物车实现中，可以使用用户id为key，商品id为field，商品数量为value，全选对应的操作为hgetall，增加商品数量对应的操作为hincr。设计时候，可以把经常变化的信息抽出来组成field：value，其余不经常改变的数据写成json存入hash。

比如此例中用户id设计为key，"商品id:商品数量"设计为第一个field，商品数量为value，“商品id:商品信息”为第二个field，商品信息的json串为value。
2、当需要频繁更改对象中一些属性的时候，建议用hash，当需要把对象当作整体传入传出时用String存储对象（Json格式）。

3、List类型

一个存储空间保存多个数据，并对数据进入存储空间的顺序进行区分，保存多个数据，底层使用双向链表存储结构实现。

1、List类型的常用操作

• 添加/修改数据

   lpush key value1 value2 ...
   rpush key value1 value 2 ...

• 获取数据(stop为-1时 为最后一位)

   lrange key start stop
   lindex key index 
   llen key

• 获取并移除数据

   lpop key
   rpop key

• 移除指定数据（count删除个数，value为值。）

   lrem key count value

• 规定时间内获取并移除最左边/最右边的数据，timeout默认单位为秒

   blpop key1 key2 ...  timeout
   brpop key1 key2 ...  timeout

演示Hash类型的基本操作

127.0.0.1:6379> lpush list a b c
(integer) 3
127.0.0.1:6379> lrange list 0 2
1) "c"
2) "b"
3) "a"
127.0.0.1:6379> lrange list 1 -1
1) "b"
2) "a"
127.0.0.1:6379> rpush list d
(integer) 4
127.0.0.1:6379> lindex list 3
"d"
127.0.0.1:6379> llen list
(integer) 4
127.0.0.1:6379> lpop list
"c"
127.0.0.1:6379> rpop list
"d"
127.0.0.1:6379> lrange list 0 -1
1) "b"
2) "a"
127.0.0.1:6379> lrem list 1 b
(integer) 1

2、注意事项

• list具有索引的概率，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式入栈出栈操作。
• 获取全部数据操作结束索引为-1，若为倒数第二个元素，索引为-2以此类推。

3、List类型常用的业务场景

1、常被用于具有操作先后顺序的数据控制，如朋友圈点赞，按照点赞顺序显示点赞好友的信息。用户的朋友圈内容为key，对应的点赞列表为value。点赞为rpush，取消点赞为lrem。

4、Set类型

能够存储大量的数据，高效的内部存储机制，便于查询。与hash存储结构完全相同，仅存储键，不存储值，无序并且值不允许重复（跟JAVA中的hashmap和hashset概念类似）

1、Set类型的常用操作

• 添加数据

   sadd key value1 value2

• 获取全部数据

   smembers key

• 获取集合的数据总量

   scard key

• 判断集合中是否包含指定数据

   sismember key value

• 随机获取集合中指定数量的数据

   srandmember key count

• 随机获取集合中某个数据并将该数据移出集合

   spop key

• 删除数据

   srem key value1 value2 ...

• 求两个集合的交、并、差集

   sinter key1 key2
   sunion key1 key2
   sdiff key1 key2

• 求两个集合的交、并、差集并存储到指定集合(key)中

   sinterstore key  key1 key2
   sunionstore key  key1 key2
   sdiffstore key  key1 key2

• 将指定数据从原始集合中移到目标集合中(将key1中的value移到key2)

   smove key1  key2 value

演示Set类型的基本操作:

127.0.0.1:6379> spop set
"b"
127.0.0.1:6379> scard set
(integer) 1
127.0.0.1:6379> smembers set
1) "a"
127.0.0.1:6379> sadd set2 a b
(integer) 2
127.0.0.1:6379> sinter set set2
1) "a"
127.0.0.1:6379> sunion set set2
1) "a"
2) "b"
127.0.0.1:6379> sdiff set set2
(empty list or set)
127.0.0.1:6379> smove set set2 a
(integer) 1

2、注意事项

• set类型不允许数据重复，如果添加的数据在set中已经存在，则只保留一份
• set虽然与hash的存储结构相同，但是无法启动hash中的存储值（value）空间。

3、Set类型常用的业务场景

1、应用于随机推荐热点数据，可以用set存放热点数据，然后随机推荐热点内容。
2、应用于同类信息的关联搜索。如显示共同好友、用户A获取到用户B的好友或者商品推荐。
3、应用于同类型不重复数据的合并操作、或者快速去重。

5、Sorted_set类型

可以保存可排序的数据，实现数据的有效展示，在set的存储结构基础上添加可排序字段。

1、Sorted_set类型的常用操作

• 添加数据

   zadd key score1 value1  [score2 value2] ...

• 获取全部数据

   zrange key start stop [withscores]
   zrevrange key start stop [withscores]

• 删除数据

   zrem key value1 [value2]

• 获取集合数据总量

   zcard key
   zcount key min max

• 集合交、并操作

   zinterstore  key  num  key1  key2 ...
   zunionstore key  num  key1  key2 ...

• 按照条件获取数据

   zrangebyscore key min max [withscores] [limit]
   zrevrangebyscore key min max [withscores] [limit]

• 按照条件删除数据(min与max作用于分数值。start与stop作用于下标)

   zrangebyrank key start  stop
   zrevrangebyscore key min max

• 获取数据对应的索引（排名）

   zrank key value
   zrevrank key value

• score值获取与修改

   zscore key value      
   zincrby key   score  value

演示Sorted_set类型的基本操作:

127.0.0.1:6379> zadd s1 50 aa 60 bb 70 cc
(integer) 3
127.0.0.1:6379> zadd s2 60 aa 40 bb 90 cc
(integer) 3
127.0.0.1:6379> zinterstore ss 2 s1 s2
(integer) 3
127.0.0.1:6379> zrange ss 0 -1 withscores
1) "bb"
2) "100"
3) "aa"
4) "110"
5) "cc"
6) "160"
127.0.0.1:6379> zunionstore ss 2 s1 s2
(integer) 3
127.0.0.1:6379> zrange ss 0 -1 withscores
1) "bb"
2) "100"
3) "aa"
4) "110"
5) "cc"
6) "160"
127.0.0.1:6379> zrevrange ss 0 -1
1) "cc"
2) "aa"
3) "bb"
127.0.0.1:6379> zrem ss cc
(integer) 1
127.0.0.1:6379> zcard ss
(integer) 2
127.0.0.1:6379> zremrangebyrank ss 0 -1
(integer) 2

127.0.0.1:6379> zadd ss 100 aa 40 bb
(integer) 2
127.0.0.1:6379> zscore ss aa
"100"
127.0.0.1:6379> zincrby ss 20 aa
"120"

2、注意事项

• score保存的数据也可以是一个双精度的double值，基于双精度浮点数的特征，可能会丢失精度，使用时要慎重
• sorted_set底层存储还是基于set结构，因此数据不能重复。如果重复添加相同的数据，score值将被反复覆盖，保留最后一次修改的结果。

3、Sorted_set类型常用的业务场景

1、应用于定时任务执行顺序管理或任务过期管理。比如VIP体验功能，用户的体验时间不同，使用serted_set的score记录用户到期的提醒时间，排序后，逐个提醒下一个用户。
2、应用于即时消息/消息队列执行管理。比如采用score记录任务的权重，优先处理权重高的任务。对于任务有类别时，可以先设定角色类别。比如1级任务 101开头，2级任务102开头 再组装具体score。

几种数据类型的对比如下：

6、三种特殊的数据类型

1、Bitmaps

通过一个 bit 位来表示某个元素对应的值或者状态, 其中的 key 就是对应元素本身，实际上底层也是通过对字符串的操作来实现。可以应用于存储数据的状态统计，对应存储为0或1。比如性别。或者统计只关注他发生过没有，发生过多少次没有要求。比如电影网站统计哪些电影被看过，哪些没被看过，不关注次数。

• 获取指定key对应偏移量上的bit值

   getbit key offset

• 设置指定key对应偏移量上的bit值，value只能是1或0

   setbit key offset value

• 对指定key按位进行交、并、非、异或操作，并将结果保持到destKey中。

   bitop xx destkey key1 [key2...]
   	xx中可填写值：
     - and:交
	 - or:并
	 - not:非
 	 - xor:异或

• 统计指定key中1的数量

   bitcount key [start end]

2、HyperLogLog

应用于独立信息统计，占用存储空间小，只记录数量不保存具体数据。核心是基数估算算法，数值量较大时存在0.81%的误差。比如统计每日访问数。

• 添加数据

   pfadd key element [element ...]

• 统计数据

   pfcount key [key...]

• 合并数据

   pfmerge destkey sourcekey [sourcekey ...]

3、Geo

这个功能可以将用户给定的地理位置通过经纬信息储存起来， 并对这些信息进行操作。应用于地理位置的计算。

• 添加坐标点

   geoadd key longitude latidude member [longitude latidude member...]

• 获取坐标点

   geoadd key  member [ member...]

• 计算坐标点的距离

   geodist key member  member2  [unit]

• 根据坐标求范围内的数据

   georadius key longitude latidude radius m\km\ft\mi [withcoord] [withdist] [withhash] [count count]

• 根据点求范围内的数据

  georadiusbymember key member radius m\km\ft\mi  [withcoord] [withdist] [withhash] [count count]

• 获取指定点对应的坐标hash值

   geohash key member  [member...]

演示Geo类型的基本操作:

4.Redis中的通用操作

1、key的通用操作

• 删除指定key

   del key

• 获取key是否存在

  exists key

• 获取key的类型

   type key

• 为指定key设置有效期(后两个为时间戳格式)

   expire key seconds
   pexpire key milliseconds
   expire key timestamp
   pexpire key milliseconds-timestamp

• 获取key的有效数据（第二个为时间戳格式的操作）

   ttl key
   ppt1 key

• 切换key从时效性转化为永久性

   persist key

• 查询key

   keys pattern

pattern为查询规则，可以有如下三种格式。

• 为key改名(第一个修改，当存在newkey这条数据时，会覆盖key的key和value，第二个会判断是否存在，不存在再修改)

   rename key  newkey
   renamenx key newkey

• 对所有key排序

   sort

• 其他key通用操作

   help @generic

2、数据库的通用操作

1、key的重复问题

• key是由程序员定义的。
• 在redis的使用中伴随着操作数据量的增加，会出现大量的数据以及对应的key。
• 数据不区分种类混在一起，容易出现重复或者冲突

2、Redis解决方案

• redis为每个服务提供16个数据库，编号从0-15

• 每个数据库之间数据相互独立

• 切换数据库

   select index

• 测试数据库是否联通(联通会返回pong)

   ping

• 退出数据库

   quit

• 数据移动(将key从当前库移到db库，移动后之前库数据就没有了)

   move key db

• 数据清除(flushdb清除按当前库数据 flushall 清除所有库数据)

   dbsize
   flushdb
   flushall

5.Jedis简介

1、引入jedis依赖

<dependency> 
    <groupId>redis.clients</groupId> 
    <artifactId>jedis</artifactId> 
    <version>2.9.0</version> 
</dependency>

2、客户端连接

  @Test
    public void testJedis() {
        Jedis jedis = new Jedis("127.0.0.1", 6379);
        jedis.set("jedis","jedis测试");
        String jedis1 = jedis.get("jedis");
        System.out.println(jedis1);
        jedis.close();
    }

springboot中使用RedisTemplate整合redis的例子可以参考这里

6.Redis持久化

1、什么是持久化

利用永久性存储介质（如计算机中的磁盘）将数据进行保存，防止数据意外丢失，确保数据安全性。在特定的时间将保存的数据进行恢复的工作机制称为持久化。

2、Redis两种持久化方案

1、RDB

将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。

1、save命令
阻塞当前Redis服务器，手动执行一次数据保存操作，直到保存过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。

save指令的相关配置：

• dbfilename dump.rdb
  设置本地数据库文件名，默认值为dump.rdb。一般设置为dump-端口号.rdb
• dir
  设置存储.rdb文件的路径。通常设置成存储空间较大的目录中，名称data
• rdbcompression yes
  设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF压缩。通常默认开启状态，如果设置为no，可以节省CPU允许时间，但会使存储的文件变大
• rbdchecksum yes
  设置是否进行rdb文件格式校验，该校验过程在写文件和读文件过程均进行。通常默认为开启状态，如果设置为no，可以节约读写过程消耗时间，但是存在数据储存损坏的风险。
• save second keychanges
  设置限定时间（second）范围内key的变化数量达到指定数量（keychanges）即进行数据存储。

save原理：

2、bgsave命令
Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在主线程fork创建子线程的阶段。

bgsave指令的相关配置：

• 与save相同，且公用一个存储文件
• stop-writes-on-bgsave-error yes
  后台存储过程中如果出现错误现象，是否停止保存操作。默认为开启状态。

bgsave原理：

3、使用save和bgsave进行数据存储

127.0.0.1:6379> set name tcc
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379> set sex  man
OK
127.0.0.1:6379> bgsave
Background saving started

在data文件中会生成对应的dump-6379文件：

REDIS0008ú     redis-ver^E4.0.0ú
redis-bitsÀ@ú^EctimeÂz^Tv^ú^Hused-memÂö<82>^M^@ú^Laof-preambleÀ^@ú^Grepl-id(1a67c382f0f5abb022e39976cc2f2
21431d56bdeú^Krepl-offsetÀ^@þ^@û^B^@^@^Crdb^Ddata^@^Bss^Bzfÿ^EM¾!5d!^W

测试rdb持久化是否生效：
先进行save保存后，kill掉redis服务器，重新打开redis服务器，数据还是存在。

[root@tanchun src]# ./redis-server  conf/redis-6379.conf 
[root@tanchun src]# ./redis-cli  -p 6379
127.0.0.1:6379> get name
"tcc"

4、save指令和bgsave指令的区别：

注意：

• save配置要根据实际业务情况进行设置， 频度过高或过低都会出现性能问题，结果可能是灾难性的。
• save配置中对于second于keychanges设置通常具有互补对应关系，尽量不要设置成包含关系。
• save配置启动后执行的是bgsave操作。
• 在全量复制、服务器运行过程中重启(debug reload)和关闭服务器时指定保存数据(shutdown save)时都会启动rdb。

5、rbd的优点和缺点：

优点：

• rdb是一个紧凑压缩的二进制文件，存储效率较高
• rdb内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• rdb恢复数据的速度要比AOF快很多
• 应用：服务器中每X小时执行bgsave备份，并将rdb文件拷贝到远程机器中，用于灾难恢复

缺点：

• rdb方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大可能丢失数据
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
• redis的总舵版本中未进行rdb文件格式的版本统一，有可能出现个版本之间数据格式无法兼容现象。

2、AOF

将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。

1、aof写数据的三种策略（appendfsync）

• always（每次）
  每次写入操作均同步到AOF文件中，数据零误差，性能较低，不推荐使用。
• everysec（每秒）
  每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置。在系统突然宕机的情况下丢失1秒内的数据。
• no（系统控制）
  由操作系统控制每次同步到AOF文件的周期，整体过程不可控。

aof配置：

• appendonly yes|no
  是否开启AOF持久化功能，默认为不开启状态
• appendfilename filename
  aof持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
• dir
  aof持久化文件保存路径，与rbd持久化文件保持一致即可
• appendfsync always|everysec|no
  aof的三种写数据策略

2、AOF重写：
随着命令不断写入AOF，文件会越来越大，问了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一数据的若干条命令执行结果转化成最终结果数据对应的指令进行记录。

作用：

• 降低磁盘占用率，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高IO性能
• 降低数据恢复时，提高数据恢复效率

重写规则：

• 进程内已超时的数据不再写入文件
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令，如set name、hdel key2、 srem key3等。
• 对同一数据的多条写命令合并为一条，如set name a、set name b合并为 set name b，lpush list a、lpush list b合并为lpush list a b。为防止数据量过大造成缓冲区溢出，对list、set等类型，每条指令最多写入64个数据。

重写命令：
手动重写：

bgrewriteaof

手动重写原理：

自动重写配置：

• auto-aof-rewrite-min-size
  aof重写最小的大小，当aof缓冲区大小大于最小尺寸时，就自动重写
• auto-aof-rewrite-percentage
  aof最小的百分比，当（当前大小-基础的大小）/基础的大小 大于auto-aof-rewrite-percentage时就自动重写。可以通过info指令查找aof的当前的大小和基础的大小。

3、使用AOF进行数据存储

127.0.0.1:6379> set name 234
OK
127.0.0.1:6379> set name 345
OK
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

第一次set和第二次set后，aof文件的大小都是增加的，再重写后,两个操作合并成一个，文件大小又减小了。

在data文件中会生成对应的appendonly-6379.aof文件中可以看到，最后只保存了set name 345的操作：

*2
$6
SELECT
$1
0
*3
$3
SET
$4
name
$3
345

4、AOF的工作流程
执行指令操作后，主进程会执行指令操作，然后开启一个fork子进程，然后将信息写入aof缓存区，最后根据周期将缓存区的内容写入aof文件。fork子进程还会开启一个aof重写缓存区。执行了重写后，会创建重写主进程，然后创建一个fork子进程来重写aof重写缓存区里的数据，然后将重写后的aof文件和原始的aof文件合并，返回新的aof文件。

3、RDB与AOF的区别

• 占用存储空间
  rdb存储的是压缩格式的数据，占用空间小
  aof存储的是指令，可能一万条数据又十万条指令，占用空间大
• 存储速度
  rdb在一次性改变的数据量大时存储速度慢
  aof支持一秒一存储，存储速度快
  -恢复速度
  rdb存储的是快照，恢复时直接给数据，恢复速度快
  aof存储的是指令，恢复时执行指令，恢复速度慢
• 安全性
  rdb可以设置频率，但是在频率之内的操作可能丢失。
  aof可以设置每个指令存储，每秒存储，不丢/丢失数据量低
• 启动优先策略
  启动时rdb优先级低，aof优先级高。首先恢复aof中的数据。
  

7.Redis事务

1、Redis事务的概念

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。比如不添加事务时，A客户端set name tcc，B客户端同时set name xxl。此时A客户端get name时候会获取到B客户端新设置的值，redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

2、事务的基本操作与锁操作

开启事务：设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中

multi

执行事务：设定事务的结束位置，同时执行事务。与multi配套使用

exec

取消事务：终止当前事务的定义，发生在multi之后，exec之前，之前的事务操作指令也失败。

discard

监视锁：监视一或多个key,如果在事务执行之前，被监视的key被事务之外的其他命令改动，则事务被打断 （ 类似乐观锁 ）

watch key1  [key2...]

取消监视锁：取消对所有key的监视

watch key1  [key2...]

分布式锁：利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功。操作值之前必须要先去获得到锁。

• 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
• 对于返回失败的，不具有控制权，排队或等待/
• 操作完毕后，通过del操作释放锁

setnx lock-key value

死锁问题解决：使用expire为锁添加时间限定，到时不释放，自动放弃锁。

expire lock-key second
pexpire lock-key milliseconds

监视锁操作的演示：在watch name age后，在另一台客户端上修改了name的值，执行事务时，就会返回nil，事务执行失败。

127.0.0.1:6379> set name 123 
OK
127.0.0.1:6379> set age 321
OK
127.0.0.1:6379> watch name age
OK
127.0.0.1:6379> multi 
OK
127.0.0.1:6379> set aa bb
QUEUED
127.0.0.1:6379> get aa
QUEUED

//此时客户端B对name值或者age值进行了修改

127.0.0.1:6379> exec
(nil)

分布式锁操作的演示：客户端A在setnx 操作后，客户端B再去获取锁，就会获取失败，当A的锁时间过期时或删除掉锁时，B才能成功获取到锁，执行操作。

A客户端

127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> setnx lock-num 1
(integer) 1
127.0.0.1:6379> incrby num 5
(integer) 15
//锁时间过期后，被B客户端获得到锁，此时再去获取锁，获取失败。
127.0.0.1:6379> setnx lock-num 1
(integer) 0


B客户端

127.0.0.1:6379> setnx lock-num 1
(integer) 0     //获取不到分布式锁。
127.0.0.1:6379> setnx lock-num 1
(integer) 0
//当A客户端的锁时间过期时，可以获取锁  解决了死锁问题。
127.0.0.1:6379> setnx lock-num 1
(integer) 1

Redis不保证事务的原子性，也没有事务回滚功能

当定义事务时。

• 命令格式输入错误时，后续的指令虽然会被加入到事务中，但是事务会被取消，执行exec时会出错。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name tcc
QUEUED
127.0.0.1:6379> set age 20
QUEUED
127.0.0.1:6379> lrange name 0 
(error) ERR wrong number of arguments for 'lrange' command
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> 

• 命令格式正确，但是无法正确执行时，其他正确的命令仍然会被执行，所以Redis事务没有原子性。

127.0.0.1:6379> set name tcc
QUEUED
127.0.0.1:6379> set age 20
QUEUED
127.0.0.1:6379> lindex name 0
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) WRONGTYPE Operation against a key holding the wrong kind of value
4) "tcc"
127.0.0.1:6379> 

3、事务的工作流程

8.Redis数据删除策略

Redis作为一个缓存数据库，设置数据的过期是非常有必要的，比如项目中的token或者一些登录信息，尤其是短信验证码都是有时间限制的。在数据过期之后，Redis会去清理这些数据，释放内存。

1、设置过期时间

过期时间通常都是作用于数据的Key上的，过期时间的设定一般包括四种格式，在本文也提到过，不进行讲解。

• expire key seconds
• pexpire key milliseconds
• expire key timestamp
• pexpire key milliseconds-timestamp

字符串有单独的设定方式：

• setex key time value

获去有效时间:

• ttl key

2、过期数据删除策略

设置了过期时间后的数据格式为hash结构，hash的key存储数据的key，hash的value存储过期时间。数据删除策略的目标是为了在内存占用和CPU占用之间寻找一种平衡，使整体redis性能稳定。

1、定时删除

• 概念：在设置key的过期时间的同时，为这个key创建一个定时器，当过期时间到达时，有定时器任务立即执行对key的删除操作

• 优点：节约内存，到时就删除，快速释放掉不必要的内存占用

• 缺点：无论CPU此时负载量多高，均占用CPU来进行数据删除，影响redis服务器的响应时间和指令吞吐量

• 总结：用处理器性能换取存储空间（以时间换空间）

2、惰性删除

• 概念：数据到达过期时间后，不做处理。等下次访问该数据时如果未过期，返回数据，如果已经过期，删除，返回不存在。内部有一个expirelfNeeded()函数用于检查数据是否过期

• 优点：节约CPU性能，发现必须删除的时候才删除

• 缺点：内存压力大，出现长期占用内存的数据

• 总结：用存储空间换取处理器性能（以空间换时间）

3、定期删除

• 原理：每秒钟执行server.hz次serverCron()操作serverCron()会执行databasesCron()轮询访问16个数据库。访问一个数据库的时间为250ms/server.hz，访问时，会执行activeExpireCycle()轮循访问W个key进行检测。如果key中过期的数量大于W25%，循环该过程。如果小于W25%，则检查下一个数据库。
  W的取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值。参数current_db用于activeExpireCycle()记录当前轮循到哪一个数据库。用于下次开始时候继续轮循。hz可以通过.conf文件配置，默认为10，值越大说明刷新频率越快，对Redis性能损耗也越大。也可以在redis.conf中配置的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略。

• 概念：周期性轮循redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度。

• 优点：可以通过设定删除操作的时间，来减少删除操作对CPU时间的占用。可以定期删除过期的key。

• 缺点：内存压力不如定时删除，CPU压力不如惰性删除。

• 总结：周期性抽查存储空间（以空间换时间）

Redis中采用惰性删除+定期删除的策略模式。在进行RDB和AOF时，都会进行key过期的判断，过期则不持久化

3、逐出策略

Redis使用内存存储数据时，会先调用freeMemoryIfNeeded()检测内存是否充足。如果内存不足，redis要临时删除一些数据，就是逐出策略。逐出策略不一定一次就清理出足够的空间，可能重复尝试。

逐出策略相关配置:

最大可使用内存:占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上。

maxmemory

每次选取待删除数据的个数:选取数据时并不会全库扫描。因此采用随机获取数据的方式作为检测删除数据。

maxmemory-samples

逐出策略:达到最大内存后，对被挑选出来的数据进行删除的策略，可选的逐出策略有：
1.volatile-lru：从已设置过期时间的数据集中挑选最近时间内使用最少的数据淘汰

2.volatile-lfu：从已设置过期时间的数据集中挑选最近使用次数最少的数据淘汰

3.volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰

4.volatile-random：从已设置过期时间的数据集中任意选择数据 淘汰

5.allkeys-lru：从数据集中挑选最近时间内使用最少的数据淘汰

6.allkeys-lfu：从数据集中挑选最近使用次数最少的数据淘汰

7.allkeys-random：从数据集中任意选择数据淘汰

8.no-enviction（驱逐）：禁止驱逐数据（4.0的默认策略）

maxmemory-policy

9.Redis主从复制

1、概念

为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

主从复制结构：

• 提供数据方：master
  主服务器，主节点、主库
  主客户端
  执行写操作时，将出现变化的数据自动同步到slave（可以读数据）
• 接收数据方：slave
  从服务器，从节点、从库
  从客户端
  读数据（禁止写数据，因为写数据后无法同步）
• 核心工作：
  master的数据复制到slave中（主从复制）。一个master可以拥有多个slave。一个slave只能对应一个master。
  

主从复制作用：

• 读写分离
  master写、slave读，提高服务器的读写负载能力
• 负载均衡
  基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量和数据吞吐量
• 故障恢复
  当master出现问题时，由slave提供服务，实现快速的故障恢复
• 数据冗余
  实现数据热备份，是持久化之外的一种数据冗余方式
• 高可用
  基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

2、工作流程与搭建服务

主从复制的过程总体可以分为三个阶段。建立连接阶段（准备阶段）、数据同步阶段和命令传播阶段。

1、建立连接阶段

连接步骤：

1：设置master的地址和端口，保存master信息
2：建立socket连接
3：发送ping命令（定时任务）
4：身份验证
5：发送slave端口信息

步骤完成后，slave保存了master的地址和端口。master保存了slave的端口。他们之间建立了连接的socket。

主从连接操作：

• 方式一：slave客户端发送命令

slaveof  masterip  masterport

• 方式二：启动slave服务器参数设置

./redis-server  -slaveof  masterip  masterport

• 方式三：slave服务器配置（主要使用第三种方式）

slaveof  masterip  masterport

连接成功后，在master中使用info查询，可以看到slave服务器的信息

# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=788,lag=0
master_replid:1893d7157a8756a13460454f1d2eb8ae4ff73831
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:788
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:788

在slave中使用info查询，可以看到slave服务器的信息

# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:998
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:1893d7157a8756a13460454f1d2eb8ae4ff73831
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

授权访问

• master配置文件设置密码

  requirepass  password

• master客户端设置密码

  config set  requirepass  password

• master客户端启动密码验证

  ./redis-cli -a password

• slave客户端启动密码验证

  auth password

• slave配置文件密码验证

  masterauth password

2、数据同步阶段

数据同步步骤

1.请求同步数据
2.创建RDB同步数据
3.恢复RDB同步数据
4.请求部分同步数据（命令缓冲区数据）
5.恢复部分同步数据

步骤完成后，slave具有master端全部数据，包含RDB过程接收的数据。master保存slave当前数据同步的位置。他们之间完成了数据克隆。

注意事项

1. 如果master数据量大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行。

2. 复制缓冲区大小设定不合理会导致数据溢出。如果进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。可以修改复制缓冲区大小，默认为1mb。

	repl-backlog-size   1mb

3. master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区。

4. 为避免slave进行全量复制、部分复制时服务器响应阻塞或是数据不同步， 建议关闭此期间的对外服务。

	slave-serve-stale-data  no

5. 数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令。（主要是ping命令）

6. 多个salve同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果master带宽不足，因此数据同步需要根据业务需求，适量错峰。

7. slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟较大，数据一致性变差，应谨慎选择。

3、命令传播阶段

1、命令传播阶段出现了断网现象

• 网络闪断闪连---------------------------忽略
• 短时间网络中断------------------------增量复制
• 长时间网络中断------------------------全量复制

2、增量复制的三个核心要素

1. 服务器的运行id(run id)
2. 主服务器的复制积压缓冲区
3. 主从服务器的复制偏移量

服务器运行ID（runid）

• 概念：服务器运行ID是每一台服务器每次运行的身份证识别码，一台服务器多次运行可以生成多个运行id

• 组成：运行id由40位字符组成，是一个随机的十六进制字符，例如：178cb024533e2e804d69f9985388fac343880e3b

• 作用：运行id被用于在服务器间进行传输，识别身份，如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别。

• 实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发送给slave，slave保存此ID，通过info Server命令，可以查看节点的runid。

主服务器的复制积压缓冲区

• ** 概念**：复制缓冲区，又名复制积压缓冲区，是一个先进先出(FIFO)的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储再复制缓冲区。缓冲区默认数据存储空间大小是1M，当入队元素的数量大于队列长度时，最先入队的元素会被弹出。
  

• 由来：每台服务器启动时，如果开启有AOF或被连接成为master节点，即创建复制缓冲区。

• 工作原理：通过偏移量区分不同的slave当前数据传播差异。master会记录已发送的信息对应的offset，slave也会记录接收的信息对应的offset。最后比对offset的值。
  

• 作用：用于保存master收到的所有指令（仅影响数据变更的指令，例如set，select）

• 数据来源：当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区。

主从服务器的复制偏移量

• 概念：一个数字，描述复制缓冲区中的指令字节位置
• 分类：
  master复制偏移量：记录发送给所有slave的指令字节对应的位置（多个）
  slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置（一个）
• 作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用。

3、数据同步和命令传播阶段工作流程
图中，FULLRESYNC为全部的数据，CONTINUE为增量数据。

4、心跳机制

1. 进入命令传播阶段，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线。
2. master心跳：
   • 指令：PING
   • 周期：由repl-ping-slave-period决定，默认10秒
   • 作用：判断slave是否在线
   • 查询：INFO replication ,获取slave最后一次连接时间间隔，lag项维持在0或1视为正常
3. slave心跳：
   • 指令：REPLCONF ACK offset
   • 周期：1秒
   • 作用：
     • 汇报slave自己的复制偏移量，获取最新的数据变更指令
     • 判断master是否在线

注意事项

• 当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作，可以通过如下配置。

min-slaves-to-write   2
min-slaves-max-lag   10

当slave数量少于2个，或所有slave的延迟都大于等于10秒时，强制关闭master写功能，停止数据同步

• slave数量和延迟由slave发送REPLCONF ACK命令确定

在了解了心跳机制后，再来理清楚主从复制的工作流程如下：

3、主从复制常见问题

1、频繁的全量复制

1、问题现象：随着系统的运行，master的数据量会越来越大，一旦master重启，runid将发生变化，会导致全部slave的全量赋值操作

内部优化方案：

1. master内部创建master_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave
2. 在master关闭时执行命令 shutdown save，进行RDB持久化，将runid与offset保存到文件中。repl-id和repl-offset。通过redis-check-rdb查看。
3. master重启后加载RDB文件，恢复数据,重启后将EDB文件保存的rep-id与rep-offset加载到内存中。
4. 作用：本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master

2、问题现象：网络环境不佳，出现网络中断，slave不提供服务。因为缓冲区过小，断网后的offset越界，触发全量复制，使slave反复进行复制。
优化方案：
修改复制缓冲区大小 repl-backlog-size。设置为评价2重连时间master平均每秒产生数据总量

2、频繁的网络中断

1、问题现象：master的CPU占用过高或slave频繁断开连接

问题原因：slave每1秒发送REPLCONF ACK命令到master，而此时当slave接到了慢查询时（keys *,hgetall等），会大量占用CPU性能。master每1秒调用复制定时函数replicationCron()，发现slave长时间没有进行响应，master重复调用定时函数，使masterCPU占用过高。

最终结果：master各种资源（输出缓冲区、带宽、连接等）被严重占用

解决方案：通过设置合理的超时时间，确认是否释放slave。repl-timoout 该参数定义了超时时间的阈值（默认60秒），超过该值，释放slave。

2、问题现象：slave与master连接断开

问题原因：master发送ping指令频度较低，如果master设置超时时间较短，此时ping指令在网络中存在丢包，则会出现连接断开现象。

解决方案：提高ping指令发送频度。repl-ping-slave-period。超时时间repl-time的时间至少是ping指令频度的5到10倍，否则slave很容易判定超时。

3、数据不一致

1、问题现象：多个slave获取相同数据不同步

问题原因：网络信息不同步，数据发送有延迟
解决方案：

• 优化主从间的网络环境，通常放置在同一个机房部署，如果使用阿里云等云服务器时要注意此现象
• 监控主从节点延迟（通过offset判断），如果slave延迟过大，暂时屏蔽程序对slave的数据访问。slave-serve-stale-data yes|no。开启后仅响应info、slaveof等少数命令（慎用， 除非对数据一致性要求很高）

10.Redis哨兵机制

主机宕机时，会将master下线，找一个slave作为master，通知所有的slave连接新的master，启动新的master与slave。那么谁来确定master宕机了？怎么找出新的master？修改配置后，原始数master恢复了怎么办？Redis使用哨兵来处理。

1、哨兵的简介

概率：是一个分布式系统，用于对主从结构中的每台服务器进行监控，，当出现故障时通过投票机制选择新的master并将所有的slave连接到新的master。

哨兵的作用

• 监控:不断检查master和slave是否正常允许。检查master是否存活、master与slave的运行情况。
• 通知：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
• 自动故障转移：断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址。

**注意：**哨兵也是一台redis服务器，只是不提供数据服务。通常哨兵配置为单数（竞选时能不会打平）

2、哨兵的搭建

1. 配置一拖二的主从结构
2. 配置三台哨兵（配置相同，端口不同）
   使用sed命令快速复制修改配置文件：将6379的配置文件复制一份为redis-6380.conf，并且将里面的6379改变为6380。

	sed 's/6379/6380/g' redis-6379.conf   > redis-6380.conf

启动三台Redis服务器：

./redis-server conf/redis-6379.conf
./redis-server conf/redis-6380.conf
./redis-server conf/redis-6381.conf

启动三台哨兵：

./redis-sentinel  conf/sentinel-26379.conf
./redis-sentinel  conf/sentinel-26380.conf
./redis-sentinel  conf/sentinel-26381.conf

测试主从是否正常工作：

master客户端
127.0.0.1:6379> set name 100
OK

slave客户端
127.0.0.1:6380> get name
"100"

测试哨兵是否正常工作：
停掉master服务器之后，哨兵的日志信息如下：

哨兵工作完成后，新选举出来的master和slave任然能正常工作。

3、哨兵的工作原理

阶段一：监控阶段

用于同步各个节点的状态信息

• 获取各个sentinel的状态（是否在线）

• 获取master的状态

  • master属性：
    • runid
    • role:master

• 获取所有slave的状态（根据master中的slave信息）

  • slave属性
    • runid
    • role:slave
    • master_host、master_port
    • offset

阶段二：通知阶段

三个哨兵之间实现信息互通，然后某台哨兵与redis主从服务器发送hello命令测试是否正常在线。

阶段三：故障转移阶段
当某一个哨兵发送hello得不到响应后，会给该master一个flags:SRI_S_DOWN。此时一台哨兵认为他宕机了，然后哨兵会把该master的host、port、状态同步给其他哨兵，其他哨兵也去发送hello，如果不响应也标记为flags:SRI_S_DOWN，然后同步给其他哨兵。如果超过半数的哨兵都标记成flags:SRI_S_DOWN后，会将标记改为flags:SRI_O_DOWN，确定他宕机。

标记为flags:SRI_O_DOWN后接下来就是清理该标记的master。由谁来清理master呢?几个哨兵会内部进行竞选，将自己的ip、端口、runid和竞选次数发出来。每个哨兵将自己的票投给第一个接收到的哨兵的信息的哨兵。

选出了一个哨兵来清理master后，如何从服务器中挑选出新的master呢?

1. 在线的
2. 发送hello后响应快的（机器性能好）。
3. 与原master断开时间近的（与原master关系近的，数据热）
4. 优先原则
   • 优先级
   • offset（选取偏移量相差小的）
   • runid（选用runid小的）

选出新的master后，怎么构成新的主从关系呢?

1. 向新的master发送slaveof no one
2. 向其他slave发送slaveof 新masterIP端口

在哨兵执行完工作流程之后，操作是持久化的，也就是会修改主从配置文件中的slaveof masterip masterport。

10.Redis集群

概念：集群就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。

作用：

• 分散单台服务器的压力，实现负载均衡
• 分散单台服务器的存储压力，实现可扩展性
• 降低单台服务器宕机带来的业务灾难

存储设计：将集群中所有的存储空间切割成若干份，然后使用key%若干份，每个节点拥有一部分 ，然后数据分配到相应的节点的存储槽中。再新加一个节点后，其他节点会将自己的槽分配给新的节点。各个数据库节点会保存相互的存储槽编号，假如第一次未命中准确槽时，节点返还正确槽位置，以便让存储数据知道该存入哪个节点中。

集群搭建
在同一台机器上演示集群效果，再基础的配置文件里添加以下配置：

cluster-enabled yes
cluster-config-file  nodes-6379.conf
cluster-node-timeout 10000

然后复制并修改为6份同时启动。

sed "s/6379/6380/g" cluster-6379.conf >cluster-6380.conf
...
./redis-server  conf/cluster-6379.conf
...

启动完节点后，可以使用redis自带的redis-trib.rb来搭建集群。（需要ruby环境）
使用 redis-trib.rb create 命令完成节点握手和槽分配过程:

redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384

返回信息中分配了三个主节点和三个从节点，16384个槽全部被分配给三个主节点，同时生产配置文件，集群创建成功。

Using 3 masters:
127.0.0.1:6379
127.0.0.1:6380
127.0.0.1:6381
Adding replica 127.0.0.1:6383 to 127.0.0.1:6379
Adding replica 127.0.0.1:6384 to 127.0.0.1:6380
Adding replica 127.0.0.1:6382 to 127.0.0.1:6381
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: bc775f9c4dea40820b82c9451778b1fcd42f92bc 127.0.0.1:6379
   slots:0-5460 (5461 slots) master
M: 3b27d00d13706a032a92ff6b0a914af272dcaaf2 127.0.0.1:6380
   slots:5461-10922 (5462 slots) master
M: d874f003257f1fb036bbd856ca605172a1741232 127.0.0.1:6381
   slots:10923-16383 (5461 slots) master
S: 648eb314863b82aaa676380be7db2ec307f5547d 127.0.0.1:6382
   replicates bc775f9c4dea40820b82c9451778b1fcd42f92bc
S: 65a6efb441ac44c348f7da8c62e26b888cda7c48 127.0.0.1:6383
   replicates 3b27d00d13706a032a92ff6b0a914af272dcaaf2
S: 57bda956485109552547aef6c77fba43d2124abf 127.0.0.1:6384
   replicates d874f003257f1fb036bbd856ca605172a1741232

启动时候使用redis-cli -c会以集群模式启动，当写入步数据当前节点的数据时，他会重定向到其他节点并写入成功。

11.Redis企业级解决方案

1、缓存预热

问题现象： 服务器启动后迅速宕机
问题排查：

1. 请求数量较高
2. 主从之间数据吞吐量较大，数据同步操作频度较高

解决方案：

1. 前置准备工作：
   1. 日常例行统计数据访问记录，统计访问频度较高的热点数据
   2. 利用LRU数据删除策略，构建数据留存队列
2. 准备工作：
   3. 将统计结果中的数据分类，根据级别，redis优先加载级别较高的热点数据
   4. 利用分布式多服务器同时进行数据读取，提速加载过程
3. 实施：
   5. 利用脚本程序设置定时任务触发缓存刷新，优先保证加载热点数据。

总结：
缓存预热是系统崩溃前，提前将相关的缓存数据直接加载到缓存系统，避在用户请求的时候，先查询数据库，然后再将数据缓存的问题。用户直接查询实现被预热的缓存数据。

2、缓存雪崩

**问题现象：**系统允许中，忽然数据库连接量剧增，应用服务器无法及时处理请求，大量的400页面，用户又反复刷新页面获取数据，导致数据库崩溃，数据库崩溃后导致应用程序崩溃。重启应用无效后导致redis服务器崩溃，导致Redis集群崩溃。
问题排查：

1. 在一个较短的时间内，缓存中较多的key集中过期
2. 此周期内请求访问过期数据，redis未命中，redis向数据库获取数据
3. 数据库同时接受到大量的请求无法及时处理
4. redis大量请求被挤压，开始出现超时现象
5. 数据库流量激增，数据库崩溃
6. 重启后仍然面临缓存中无数据可用
7. redis服务器资源被严重占用，redis服务器崩溃
8. redis集群呈现崩塌
9. 应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越多，应用服务器崩溃
   10.应用服务器，redis，数据库全部重启，效果不理想

解决方案：

1. LRU与LFU切换（最久没有使用和最少使用策略）
2. 数据有效期策略调整
   1. 根据业务数据有效期进行分类错峰，A类90分钟，B类80分钟。
   2. 过期时间使用固定时间+随机值的形式，稀释几种到期的key的数量
3. 超热数据使用永久key
4. 定期维护（自动+人工）（对即将过期的诗句进行访问量分析，确认是否延时）
5. 加锁

总结：
缓存雪崩就是瞬间过期数据量太大，导致对数据库服务器造成压力。如能够有效避免过期时间集中，可以有效解决雪崩现象的出现。配合其他策略一起使用，并监控服务器的运行数据，根据运行记录做延时调整。

3、缓存击穿

问题现象： 系统平稳运行过程中数据库连接量剧增，redis服务无大量key过期、内存平稳、CPU正常而数据库崩溃。

问题排查：

1. redis中某个key过期，该key访问量巨大
2. 多个数据请求从服务器直接压到redis后，均为命中
3. redis在短时间内发起了大量对数据库中同一数据的访问

解决方案：

1. 预先设定：以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物街期间加大此类信息key的过期时长
2. 现场调整：监控访问量，对自然流量剧增的数据延长过期时间或设为永久性key
3. 后台刷新数据：启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失
4. 二级缓存：设置不同的失效时间，保障不会被同时淘汰就行
5. 加锁：分布式锁，防止被击穿，但也会限制性能

总结：
缓存击穿就是单个高热数据过期的瞬间，数据访问量较大，未命中redis后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行，配合运行检测与临时调整策略，毕竟单个key的过期监控难度较高，配合雪崩处理策略即可。

4、缓存穿透

问题现象： 系统平稳运行过程中服务器流量增高，redis命中率下降，redis内存平稳，但是数据库服务器压力剧增导致数据库崩溃。

问题排查：

1. redis中大面积出现未命中
2. 出现大面积非正常URL访问
3. 数据库中没有数据，redis中也不会缓存。

解决方案：

1. 缓存null:对查询结果为null的数据进行缓存，因为缓存量太大，所以设定短时间过期，例如1分钟。
2. 白名单策略：
   1. 提前预热各种分类数据id对应的bitmaps，id作为bitmaps的offset，相当于设置了数据白名单，加载数据正常时放行，异常时候拦截（效率偏低）。
   2. 使用布隆过滤器
3. 实施监控：实时监控redis命中率（业务正常范围时，通常会有一个波动值）与null数据的占比。比如通常时间段是5倍，但是到达10倍时，可以再进行1、2步操作。

总结：
缓存穿透访问了不存在的数据，跳过了redis缓存阶段，每次都访问数据库导致服务器压力增大。通常应监控后及时处理，比如对null的结果进行缓存，或者使用bitmaps添加白名单。