redis大数据量高性能：读数据每秒达到11w次，写数据每秒达到8w次
一、NoSQL入门概述
1、NoSQL数据模型简介
■ NoSQL的数据模型是：聚合模型
聚合模型又包含以下几种类型：
①、KV 键值对
②、BSON：BSON（）是一种类 json 的一种二进制形式的存储格式，简称Binary JSON，它和JSON一
样，支持内嵌的文档对象和数组对象
③、列族
④、图形
■ 关系型数据库和非关系型数据库对比：
①、高并发的操作是不太建议有关联查询的，互联网公司用冗余数据来避免关联查询
②、分布式事务是支持不了太多并发的
2、NoSQL数据库的四大分类
■ 四大分类：即上述所说的具体聚合模型
□ KV 键值对：例如 redis
□ 文档型数据库（bson格式比较多）：例如 HBase，Cassandra
□ 列存储数据库：例如 MongoDB-查询性能不高
□ 图关系数据库：例如 Neo4J，InfoGrid
3、在分布式数据库中CAP原理
①、传统的 ACID 分别是什么：
A：原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务
里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户
转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起
完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。
C：一致性
一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的
一致性约束。例如A给B转账，不论转账的事务操作是否成功，其两者的存款总额不变（这是业务逻
辑的一致性，至于数据库关系约束的完整性就更好理解了）。
I：独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修
改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A
账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加
的100元的
D：持久性
持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
②、CAP 具体意义：
C：强一致性
A：高可用性
P：分区容错性
分区容错性：
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有
些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。
这就叫分区。
当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不
到这个数据了。这时分区就是无法容忍的。
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项
就可能分布到各个区里。容忍性就提高了。
然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是
不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性
的问题。
总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致
性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降
低。
③、CAP 的 3 进 2：
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟
丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没
有NoSQL系统能同时保证这三点。
CA：传统Oracle数据库
AP：大多数网站架构的选择
CP：Redis、Mongodb
注意：分布式架构的时候必须做出取舍。
一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。
因此牺牲C换取P，这是目前分布式数据库产品的方向
④、CAP 核心理论：
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
最多只能同时较好的满足两个。因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原
则和满足 AP 原则三 大类：
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
二、Redis 入门介绍
1、入门概述
①、是什么？
Redis：REmote DIctionary Server(远程字典服务器)
是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的(key/value)分布式内存数据库，基
于内存运行并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一,也被人们称为数据结构服
务器
②、Redis 与其他 key - value 缓存产品有以下三个特点
■ Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
■ Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
■ Redis支持数据的备份，即master-slave模式的数据备份
③、下载地址
http://redis.io/
http://www.redis.cn/
2、Redis的安装
● 下载获得redis-3.0.4.tar.gz后将它放入我们的Linux目录/opt
● 在/opt目录下，解压命令:tar -zxvf redis-3.0.4.tar.gz
● 解压完成后出现文件夹：redis-3.0.4
● 进入目录:cd redis-3.0.4
● 在redis-3.0.4目录下执行make命令
○ 安装时，可能会出现 gcc 命令未找到，此时需要安装 gcc 命令。gcc是linux下的一个编译程序，是C程
序的编译工具。
○ 能上网的情况下：运行 yum install gcc-c++ 即可安装
○ 安装完 gcc 后，二次make
○ 可能会提示：jemalloc/jemalloc.h：没有那个文件或目录
○ 运行make distclean之后再make
○ Redis Test(可以不用执行)，如果执行，会需要下载一些额外的软件才行
● 如果make完成后继续执行make install
● 查看默认安装目录：usr/local/bin，此目录下存放的是启动 redis 服务或客户端的一些命令
● 启动，可以使用 ps -ef | grep reids 查看服务是否启动
○ 进入目录:cd redis-3.0.4，将默认的 redis.conf 拷贝到自己定义好的一个路径下，比如/myconf，或者
拷贝到 /etc 目录下
○ 修改拷贝完后的 redis.conf 文件将里面的daemonize no 改成 yes，让服务在后台启动
○ 启动，进入 usr/local/bin 目录下，运行 redis-server 拷贝修改后的redis.conf，
例如：redis-server /myconf/redis/redis.conf
○ 进入 redis 客户端，进入 usr/local/bin 目录下，运行 redis-cli -p 6379
○ 测试连通性，运行上述步骤后，输入 ping，若打印 PONG，则连通性通过
○ 可以设置一些值，如 set k1 v1，可以查看值，如 get k1
● 关闭
○ 单实例关闭：在 redis 客户端输入 shutdown 即关闭，然后输入exit退出
○ 多实例关闭，指定端口关闭:redis-cli -p 6379 shutdown
3、Redis启动后杂项基础知识
①、单进程
单进程模型来处理客户端的请求。对读写等事件的响应是通过对epoll函数的包装来做到的。Redis的实际
处理速度完全依靠主进程的执行效率
epoll是Linux内核为处理大批量文件描述符而作了改进的epoll，是Linux下多路复用IO接口select/poll的
增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。
②、默认16个数据库，类似数组下表从零开始，初始默认使用零号库
③、select命令切换数据库，如 select 0 表示切换到 0 号库
④、dbsize查看当前数据库的key的数量
⑤、flushdb：清空当前库。Flushall；通杀全部库
⑥、统一密码管理，16个库都是同样密码，要么都OK要么一个也连接不上
⑦、Redis索引都是从零开始
⑧、为什么默认端口是6379
三、Redis数据类型
1、Redis的五大数据类型
■ String（字符串）
string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M
■ hash（哈希，类似java里的Map）
Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
类似Java里面的Map<String,Object>
■ list（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾
部（右边）。
它的底层实际是个链表
■ **set（集合）**
Redis的Set是string类型的无序集合。它是通过HashTable实现的，
■ zset（sorted set：有序集合）
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。
redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重
复。
2、哪里去获得redis常见数据类型操作命令
http://redisdoc.com/
3、Redis键（key）
■ keys *
查询所有的key
■ exists key名字，判断某个key是否存在
■ move key db，当前库就没有了，被移除了，移动到了指定的库中了
例如：move k1 2，表示当前库没有k1了，被移动了3号库里面了
■ expire key 秒钟，为给定的 key 设置过期时间
■ ttl key，表示查看还有多少秒过期，-1表示永不过期，-2表示已过期
■ type key，查看你的 key 是什么类型
4、Redis字符串（String）
■ set/get/del/append/strlen
set：设置键值对
get：获取指定key对应的值
del：删除指定的key
append：在某个key对应的值后追加其他的值
strlen：获取指定key对应值的字符串长度
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qVQ46LnT-1592367081483)(
./images/捕获178.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gpU16Iyy-1592367081488)(
./images/捕获179.png)]
■ incr/decr/incrby/decrby，一定要是数字才能进行加减
incr：对指定key对应的值加1
decr：对指定key对应的值减1
incrby：对指定key对应的值加指定的数字
decrby：对指定key对应的值减指定数字
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iAmhoWk0-1592367081492)(
./images/捕获180.png)]
■ getrange/setrange
getrange：获取指定区间范围内的值，类似between…and的关系。从零到负一表示全部
setrange：设置指定区间范围内的值，格式是：setrange key值 替换位置 具体值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ijvr7D6h-1592367081498)(
./images/捕获181.png)]
■ setex/setnx
setex：设置带过期时间的key，动态设置。setex 键 秒值 真实值
setnx：只有在 key 不存在时设置 key 的值。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qK0RdTYr-1592367081501)(
./images/捕获182.png)]
■ mset/mget/msetnx
mset：同时设置一个或多个 key-value 对。
mget：获取所有(一个或多个)给定 key 的值。
msetnx：同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qrvSUHXr-1592367081503)(
./images/捕获183.png)]
■ getset
getset：将给定 key 的值设为 value ，并返回 key 的旧值(old value)。简单一句话，先get然后立即set
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-va8BPYE9-1592367081506)(
./images/捕获184.png)]
5、Redis列表（List）
■ lpush/rpush/lrange
lpush：
rpush：
lrange：将列表取出，范围从0到-1表示取出所有元素
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2tlyaIdj-1592367081508)(
./images/捕获185.png)]
■ lpop/rpop
lpop：
rpop：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ywqIlJWE-1592367081511)(
./images/捕获186.png)]
■ lindex：按照索引下标获取元素（从上到下）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4hrEROs7-1592367081513)(
./images/捕获187.png)]
■ llen：获取列表长度
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IRYYMk5X-1592367081514)(
./images/捕获188.png)]
■ lrem
lrem：删除key中N个value，如：lrem list3 2 3，表示删除 list3 中 2 个值为3的 value
从left往right删除2个值等于v1的元素，返回的值为实际删除的数量：lrem key 2 v1
lrem key 0 值，表示删除全部给定的值。零个就是全部值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4WPLjd5d-1592367081516)(
./images/捕获189.png)]
■ ltrim：截取指定范围的值后再赋值给 key，格式：ltrim key 开始index 结束index
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FcKsB0Mh-1592367081517)(
./images/捕获190.png)]
■ rpoplpush：移除列表的最后一个元素，并将该元素添加到另一个列表并返回，
语法：rpoplpush 源列表 目标列表
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TIDxe15R-1592367081518)(
./images/捕获191.png)]
■ lset：将列表中指定索引位置的值赋值为指定的值，语法：lset key index value
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FP6ESQ0b-1592367081519)(
./images/捕获192.png)]
■ linsert：在list某个已有值的前后再添加具体值，语法：linsert key before/after 值1 值2
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TMpysfT2-1592367081520)(
./images/捕获193.png)]
■ 性能总结：
它是一个字符串链表，left、right都可以插入添加；
如果键不存在，创建新的链表；
如果键已存在，新增内容；
如果值全移除，对应的键也就消失了。
链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。
6、Redis集合（set）
■ sadd/smembers/sismember
sadd：添加元素到指定的key，如果值有重复，只添加一份，即元素不允许重复
smembers：获取出所有的值
sismember：指定的值是否存在在key中
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lv5Hcs78-1592367081521)(
./images/捕获194.png)]
■ scard：获取集合中元素的个数
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zd5AKpK5-1592367081522)(
./images/捕获195.png)]
■ srem：删除集合中元素
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JM2CSsJG-1592367081523)(./images/捕获196.png)]
■ srandmember：随机取出几个数
如果超过最大数量就全部取出
如果写的值是负数，比如-3 ，表示需要取出3个，但是可能会有重复值。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p1UsR2CK-1592367081524)(
./images/捕获197.png)]
■ spop：随机出栈
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dtYAN7SK-1592367081525)(
./images/捕获198.png)]
■ smove：将key1里面的某个值赋值给key2，key2并不一定要事先创建好
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aoSjm5t2-1592367081526)(
./images/捕获199.png)]
■ sdiff/sinter/sunion
sdiff：差集
sinter：交集
sunion：并集
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NZhBiKH8-1592367081527)(
./images/捕获200.png)]
7、Redis哈希（Hash）
KV模式不变，但V是一个键值对
■ hset/hget/hmset/hmget/hgetall/hdel
hset：设置值
hget：获取值
hmset：批量设置值
hmget：批量获取值
hgetall：获取所有的值
hdel：删除key
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4Y6EcMeu-1592367081528)(
./images/捕获201.png)]
■ hlen：获取元素个数
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fSEKQbi3-1592367081529)(
./images/捕获202.png)]
■ hexists：在key里面的某个值是否存在
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0aiFOFb4-1592367081530)(
./images/捕获203.png)]
■ hkeys/hvals
hkeys：获取hash中所有的key
hvals：获取hash中所有的value
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Zvdi7z4y-1592367081531)(
./images/捕获204.png)]
■ hincrby/hincrbyfloat
hincrby：给指定的key增加指定的整数数字
hincrbyfloat：给指定的key增加指定的浮点数字
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O2ZLUj6e-1592367081532)(
./images/捕获205.png)]
■ hsetnx：不存在赋值，存在了无效
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5sWSL7kq-1592367081533)(
./images/捕获206.png)]
8、Redis有序集合Zset（sorted set）
在set基础上，加一个score值。之前set是k1 v1 v2 v3，现在zset是k1 score1 v1 score2 v2
■ zadd/zrange
zadd：往集合中添加元素
zrange：从集合中取出元素，取出的是score对应的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TrdoF75f-1592367081534)(
./images/捕获207.png)]
■ withscores：如果zrange语法最后增加withscores，会将score和其对应的值都取出
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4NWWxd6y-1592367081536)(
./images/捕获208.png)]
■ zrangebyscore：取出范围的值
语法：zrangebyscore key 开始score 结束score
□ withscores
□ （ 不包含
□ limit：作用是返回限制，limit 开始下标步 多少步
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YjQP8CO3-1592367081537)(
./images/捕获209.png)]
■ zrem：删除元素，语法：zrem key 某score下对应的value值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EDPhNpYf-1592367081538)(
./images/捕获210.png)]
■ zcard/zcount/zrank/zscore
zcard：获得值的个数，语法：zcard key
zcount：获取值的个数，语法：zcount key score区间开始值 score区间结束值
zrank：获得下标值，语法：zrank key values值
zscore：获得分数，语法：zscore key 分数值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2wGBnghY-1592367081539)(
./images/捕获211.png)]
■ zrevrank：逆序获得下标值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hAubiCbY-1592367081540)(
./images/捕获212.png)]
■ zrevrange：逆序获得值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mLYLMaGl-1592367081541)(
./images/捕获213.png)]
■ zrevrangebyscore：逆序获得分数指定的值，语法：zrevrangebyscore key 结束score 开始score
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mjIgp02g-1592367081542)(
./images/捕获214.png)]
四、解析配置文件redis.conf
1、它在哪
出厂的 redis.conf 在 redis 的 tar 包解压目录下，在自己电脑上存放的路径是：/opt/redis-3.0.4/redis.conf
但是出厂的配置文件一般不改变，会单独复制一份出来修改，存放路径是：/myconf/redis/redis.conf
注意：/opt 目录是用来存放软件的目录，软件安装后，会存放在 /usr/local/bin 目录下，这个目录就相当于
windowns 下的 C:\Program Files
2、units单位
1k => 1000 bytes
1kb => 1024 bytes
1m => 1000000 bytes
1mb => 10241024 bytes
1g => 1000000000 bytes
1gb => 10241024*1024 bytes
①、 配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit
②、 对大小写不敏感
3、ICLUDES包含
和我们的Struts2配置文件类似，可以通过includes包含，redis.conf可以作为总闸，包含其他
4、GENERAL通用
■ daemonize
daemonize默认出厂配置为no，应改为yes，如果为no，表示 redis 不是后台启动，每次启动后，会有
一个黑色框弹出，配置为yes后，无需弹出黑色框，会变成后台的守护线程
■ pidfile
指定进程管道 ID 文件，默认出厂配置为：/var/run/redis.pid，即会在 /var/run/ 目录下生成一个
redis.pid 文件
■ port
指定端口号，默认是 6379
■ tcp-backlog
设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三
次握手队列。在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这
个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和
tcp_max_syn_backlog两个值来达到想要的效果。默认值是 511
■ timeout
当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能。默认值是 0
■ bind
绑定的主机地址。指定 redis 只接收来自于该 IP 地址的请求，如果不进行设置，那么将处理所有请求
■ tcp-keepalive
用来定时向client发送tcp_ack包来探测client是否存活的。默认不探测。单位为秒，如果设置为0，则不
会进行Keepalive检测，建议设置成60
■ loglevel
指定了服务端日志的级别。级别包括：
debug（很多信息，方便开发、测试）
verbose（许多有用的信息，但是没有debug级别信息多）
notice（适当的日志级别，适合生产环境）
warn（只有非常重要的信息）
■ logfile
指定了记录日志的文件。空字符串的话，日志会打印到标准输出设备。后台运行的redis标准输出
是 /dev/null。
■ syslog-enabled
是否把日志输出到syslog（系统日志）中
■ syslog-ident
指定syslog里的日志标志
■ syslog-facility
指定syslog设备，值可以是USER或LOCAL0-LOCAL7
■ databases
数据库的数量，默认使用的数据库是DB0。可以通过 ”SELECT “ 命令选择一个db
5、SNAPSHOTTING快照
■ save
save语法： save 秒钟 写操作次数
作用：因为 redis 是分布式内存数据库，数据保存在内存，如需写入硬盘中，可以用 save 将数据写入硬
盘内
RDB是整个内存的压缩过的Snapshot（快照），RDB的数据结构，可以配置复合的快照触发条件，默认
是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。
禁用：如果不想使用 redis 进行持久化，可以禁用RDB持久化的策略，只要不设置任何save指令，或者给
save传入一个空字符串参数也可以，如：save “”
■ stop-writes-on-bgsave-error
它的意思是后台保存如果发生错误，则停止进行写操作。它可以设置为 yes 或 no
如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
■ rdbcompression
rdbcompression：对于存储到磁盘中的快照（内存中的数据存入磁盘中），可以设置是否进行压缩存
储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为
关闭此功能。可以设置为 yes 或 no。建议此功能打开
■ rdbchecksum
rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约
10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。建议打开
■ dbfilename
指定 rdb 文件名称
■ dir
rdb 文件存放的目录
6、REPLICATION复制
7、SECURITY安全
■ requirepass
设置密码，当设置了密码后，输入任何命令redis都会提示需要先认证通过后才能响应。
输入密码的语句是：auth 密码
可以在客户端输入：config get requirepass 获取密码，也可以输入：config set requirepass 密码
来进行设置密码，可以输入：config get dir 获取启动redis的路径。
8、LIMITS限制
■ maxclients
设置能连上redis的最大客户端连接数量。默认是10000个客户端连接。由于redis不区分连接是客户端连
接还是内部打开文件或者和slave连接等，所以maxclients最小建议设置到32。如果超过了maxclients，
redis会给新的连接发送’max number of clients reached’，并关闭连接。如果设置 maxclients 0，表示
不作限制
■ maxmemory
设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过
maxmemory-policy来指定。如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移
除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有
从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设
置的是“不移除”的情况下，才不用考虑这个因素
■ maxmemory-policy
内存容量超过maxmemory后的处理策略。具体策略有如下几种：
LRU算法是最近最少使用，TTL算法是有限时间内
①、volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
②、allkeys-lru：使用LRU算法移除key
③、volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
④、allkeys-random：移除随机的key
⑤、volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
⑥、noeviction：不进行移除。针对写操作，只是返回错误信息
■ maxmemory-samples
设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大
小，redis默认会检查这么多个key并选择其中LRU的那个。
从需要淘汰的列表中随机选择sample个key，选出闲置时间最长的key移除
9、APPEND ONLY MODE追加
■ appendonly
表示是否开启 aof 功能，默认是 no，不开启，如果需要用到 aof ，则设置为 yes
■ appendfilename
表示 aof 文件名称
■ appendfsync
aof持久化策略的配置，策略有如下三种：
always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
everysec：出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
no：表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快
■ no-appendfsync-on-rewrite
重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
■ auto-aof-rewrite-min-size：设置重写的基准值，默认是 64mb，即 aof 文件达到64mb后，会重写
■ auto-aof-rewrite-percentage：设置重写的基准值，默认是 100，即 aof 文件如果达到上次文件的一倍就
会重写
10、常见配置redis.conf介绍
参数说明
redis.conf 配置项说明如下：
-
Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
daemonize no -
当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
pidfile /var/run/redis.pid -
指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
port 6379 -
绑定的主机地址
bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
timeout 300 -
指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
loglevel verbose -
日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
logfile stdout -
设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
databases 16 -
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
save
Redis默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。 -
指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes -
指定本地数据库文件名，默认值为dump.rdb
dbfilename dump.rdb -
指定本地数据库存放目录
dir ./ -
设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
slaveof -
当master服务设置了密码保护时，slav服务连接master的密码
masterauth -
设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭
requirepass foobared -
设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128 -
指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
maxmemory -
指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no -
指定更新日志文件名，默认为appendonly.aof
appendfilename appendonly.aof -
指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折衷，默认值）
appendfsync everysec -
指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
vm-enabled no -
虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
vm-swap-file /tmp/redis.swap -
将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-max-memory 0 -
Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
vm-page-size 32 -
设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
vm-pages 134217728 -
设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
vm-max-threads 4 -
设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
glueoutputbuf yes -
指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512 -
指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
activerehashing yes -
指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf
五、Redis持久化
1、RDB（Redis DataBase）
■ 是什么？
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快
照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程
都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这
就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
■ fork
fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）
数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
■ rdb 保存的是dump.rdb文件
■ 配置位置（dump.rdb 文件位置）
由第四章的SNAPSHOTTING（快照）中可知，配置的位置在 dir 指定目录下，文件名由 dbfilename 指
定。可以使用 config get dir 获取目录
■ 如何触发 RDB 快照
①、配置文件默认的快照配置（重点）
由 SNAPSHOTTING 配置中的 save 配置可知，只要 redis 内存中数据 1分钟内改了1万次，或5分钟
内改了10次，或15分钟内改了1次（这些值都可以自己修改），都会产生一个 dump.rdb 文件，只
需将产生的 dump.rdb 文件备份好，将备份好的 dump.rdb 替换原有的 dump.rdb 文件，重新开启
redis服务即可恢复原有的数据
②、命令save或者是bgsave
这两个命令都会将对redis写操作的数据进行持久化，即会产生新的 dump.rdb 文件
save：save时只管保存，其它不管，全部阻塞
bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave
命令获取最后一次成功执行快照的时间
③、执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
■ 如何恢复
一般将备份文件 (dump.rdb) 移动到 redis 安装目录（具体目录应该是配置文件 SNAPSHOTTING 配置下
dir 指定的目录）并启动服务即可，因为启动时都在这个安装目录启动的。
但是 dump.rdb 的具体目录可以在进入客户端后，使用 config get dir 命令查看
举个例子，如果启动 redis 是在 / 目录下启动的，那么 dump.rdb 可能会存放在 / 根目录下，所有要使
用 config get dir 查看目录
■ 优势
①、适合大规模的数据恢复
②、对数据完整性和一致性要求不高
■ 劣势
①、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
②、fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
■ 如何停止
动态所有停止RDB保存规则的方法：进入客户端：redis-cli -p 6379，然后运行： config set save “”
2、AOF（Append Only File）
■ 是什么？
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件
但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件
的内容将写指令从前到后执行一次以完成数据的恢复工作
■ Aof保存的是appendonly.aof文件
■ 配置位置：跟 rdb 配置位置一样
■ AOF启动/修复/恢复
①、正常恢复：恢复数据
● 启动：设置 yes
修改默认的appendonly no，改为yes
● 将有数据的aof文件复制一份保存到对应目录(config get dir)
● 恢复：重启redis然后重新加载
②、异常恢复
● 启动：设置Yes
修改默认的appendonly no，改为yes
● 备份被写坏的AOF文件
● 修复：使用命令 redis-check-aof --fix 文件名 进行修复，注意 redis-check-aof 命令跟
redis-server 在同一个目录下，同理 rdb 也可以使用这种方式恢复 dump.rdb 文件。
注意：这只是修复 aof 或者 rdb 文件。
● 恢复：重启redis然后重新加载
■ rewrite（重写）
①、是什么？
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超
过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使
用命令bgrewriteaof
②、重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再ename)，
遍历新进程的内存中数据，每条记录有一条Set语句。重写aof文件的操作，并没有读取旧的aof文
件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
③、触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件
大于64M时触发
■ 优势
①、每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但
数据完整性比较好
②、每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
③、不同步：appendfsync no 从不同步
■ 劣势
①、相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
②、aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
3、总结
①、RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
②、AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数
据,AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF
文件的体积不至于过大
③、只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
④、同时开启两种持久化方式
● 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件
保存的数据集要比RDB文件保存的数据集要完整.
● RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有
AOF可能潜在的bug，留着作为一个万一的手段。
⑤、性能建议
因为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、是什么
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执
行而不会被其它命令插入，不许加塞
2、能干嘛
一个队列中，一次性、顺序性、排他性的执行一系列命令
3、怎么玩
■ 常用命令
redis事务命令：
①、discard
取消事务，放弃执行事务块内的所有命令
②、exec
执行所有事务块内的命令
③、multi
标记一个事务块的开始
④、unwatch
取消watch命令对所有key的监视
⑤、watch key [key…]
监视一个或多个key，如果在事务执行之前这个或这些key被其他命令所改动，那么事务将被打断
■ 正常执行
● 先用multi开启事务
● 对redis进行操作
● 使用exec执行事务块内的命令
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Anvh4TMz-1592367081544)(
./images/捕获215.png)]
■ 放弃事务
● 先用multi开启事务
● 对 redis 进行操作
● 使用 discard 命令放弃之前对redis操作的事务
● redis内存中保存的值还是执行此事务之前的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DQOn0tTh-1592367081547)(
./images/捕获216.png)]
■ 全体连坐
● 先用multi开启事务
● 对redis进行操作，里面有些命令是错误的，如 getset k3，此命令写法错误，应为 getset k3 值
● 使用 exec 执行事务块内的命令
● 这种情况有命令错误，则事务内的所有命令都不能执行
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TJodarJ4-1592367081548)(
./images/捕获217.png)]
■ 冤头债主
● 先用multi开启事务
● 对redis进行操作，注意这次操作语法没错，但是数据可能有问题，则有问题的这条数据的语句不能够
得到执行，但是不影响其他语句执行，所以redis是部分支持事务，因为这种情况并没有满足事务的
一致性原则
● 使用exec执行事务块内的命令
如下图，k1 的值是 aa，在执行 incr 时并不知道 k1 是不是整数类型，这相当于java的运行时异常，类似
java 的 10/0 这种异常
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mb3r77Sv-1592367081549)(
./images/捕获218.png)]
■ watch监控
①、乐观锁/悲观锁
乐观锁： 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修
改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可
以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。乐观锁相当于
在每列后面多加了一列 version 版本号。每次写之前，会先去获取版本号，在执行写时，判
断此时数据的版本号与之前获取的版本号是不是一样，如果一样，则执行写操作，同时会将
版本号增加。如果不一样，则必须重写获取版本号
乐观锁策略：提交版本必须大于记录当前版本才能执行更新
悲观锁： 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修
改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都
是在做操作之前先上锁。
②、watch举例
● 初始化信用卡可用余额和欠额
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JsKhmyPf-1592367081550)(
./images/捕获219.png)]
● 无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JtqG06hq-1592367081552)(
./images/捕获220.png)]
● 有加塞篡改，监控了key，如果key被修改了，后面一个事务的执行失效。即：如果用户A先监控一
个key，然后开启事务，开启事务后，另外有一个用户B修改了这个key的值，那么此时A再对这
个key进行操作后，使用exec执行事务会使事务执行不成功
用户A操作如下
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EDpRUUPE-1592367081554)(
./images/捕获221.png)]
用户B操作如下
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-spIVbZeS-1592367081555)(
./images/捕获222.png)]
● unwatch
unwatch表示对放弃此次监控。如图，监控balance后，修改了balance，则此时数据可能不正
确，需放弃此次监控
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qnYHKLhl-1592367081558)(
./images/捕获223.png)]
● 一旦执行了exec之前加的监控锁都会被取消掉了
● 小结
①、Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list
已被别的客户端push/pop过了，整个事务队列都不会被执行
②、通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生
了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务
执行失败
■ 3阶段
①、开启：以MULTI开始一个事务
②、入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
③、执行：由EXEC命令触发事务
■ 3特性
①、单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他
客户端发送来的命令请求所打断。
②、没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都
不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人
万分头痛的问题
③、不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
七、Redis的发布与订阅
1、是什么
进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
2、命令
■ psubscribe
订阅一个或多个符合给定模式的频道
■ pubsub
查看订阅与发布的系统状态
■ publish
将信息发送到指定的频道
■ punsubscribe
退订所有给定模式的频道
■ subscribe
订阅给定的一个或多个频道的信息
■ unsubscribe
退订给定的频道
3、案例
①、可以一次性订阅多个
subscribe c1 c2 c3
②、消息发布
publish c2 hello-redis
③、订阅多个，通配符*
psubscribe new*
④、收取消息
publish new1 redis2019
八、Redis主从复制（Master/Slave）
初始化：配置三台 redis，配置方式为：
①、将 redis 的配置文件分别拷贝三份，分别为 redis6379.conf，redis6380.conf，redis6381.conf
②、将三份配置文件中的 pid管道文件，端口号，日志文件，dump.rdb文件名 都改为对应的值
③、分别启动这三台redis服务，redis-server 配置文件
④、启动三台服务端，redis-cli -p 6379、redis-cli -p 6380、redis-cli -p 6381
1、是什么
行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机
制，Master以写为主，Slave以读为主
2、能干嘛
■ 读写分离
■ 容灾恢复
3、怎么玩
■ 配从（库）不配主（库）
■ 从库配置
● 怎样将reids设置为从库？
命令：slaveof 主库IP 主库端口，如：slaveof 127.0.0.1 6379
● 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件，配置进redis.confi文件的方
式为：在 REPLICATION 下面修改 slaveof ，将masterip和masterport
改为对应主机的IP和端口号
● 查看机器是主机还是从机的命令：info replication
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QvROEa2E-1592367081560)(
./images/捕获225.png)]
■ 修改配置文件细节操作
● 拷贝多个 redis.conf 文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m7syu1gL-1592367081561)(
./images/捕获224.png)]
● 修改配置文件中几个配置
①、三个配置文件都开启 daemonize，即 daemonize yes。
②、修改pid 文件名字，分别为
/var/run/redis6379.pid，/var/run/redis6380.pid，/var/run/redis6381.pid
③、修改端口号，分别为 6379,6380,6381
④、修改 log 文件名，分别为 6379.log，6380.log，6381.log
⑤、修改 dump.rdb 文件名字，分别为 dump6379.rdb，dump6380.rdb，dump6381.rdb
4、常用3招
1）一仆二主
■ 初始化
由下面三图可知，在刚启动服务时，每台服务都是主机
端口号为6379的服务
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cp82b9iR-1592367081562)(
./images/捕获226.png)]
端口号为6380的服务
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CNokzKol-1592367081563)(
./images/捕获227.png)]
端口号为6381的服务
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MQYssrdn-1592367081564)(
./images/捕获228.png)]
■ 一个Master两个Slave
将端口号为6379的服务配置为主机，其他两个服务配置为从机，只需将端口号为6380和6381的两台
服务执行 slaveof 127.0.0.1（主机IP） 6379（主机端口） 命令即可将其切换为从机
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HD8CBNRa-1592367081565)(
./images/捕获229.png)]
■ 日志查看，在redis客户端通过 config get dir 获取目录，到获取的目录下查看日志
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lhMuQhGW-1592367081566)(
./images/捕获230.png)]
■ replication
查看主机从机的信息，使用命令 info replication
■ 主从问题演示
● 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123
是否也可以复制
答：之前的也可以复制。一旦切换为从机，则会将主机所有的数据从头到尾都拷贝一份到从机，
而之后如果主机再增加数据，从机只会拷贝新增的数据，已经拷贝过的数据不会再拷贝
6379服务执行如下命令
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-prXcgvjD-1592367081567)(
./images/捕获231.png)]
从下图可以看出6380即使在6379设置完k2以后切换为从机，但是依然可以获取到k2的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0HevSNes-1592367081568)(
./images/捕获232.png)]
● 从机是否可以写？set可否？
答：从机不能进行写操作
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jmzHdIGm-1592367081569)(
./images/捕获233.png)]
● 主机shutdown后情况如何？从机是上位还是原地待命
答：主机会原地待命
主机6379执行shutdown命令：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4QNCFlxH-1592367081570)(
./images/捕获234.png)]
从机6380和6381执行 info replication命令，可以看到还是从机
6380从机 6381从机
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ewAb0nFe-1592367081571)(
./images/捕获235.png)] [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-adoTe45L-1592367081572)(
./images/捕获236.png)]
● 主机又回来了后，主机新增记录，从机还能否顺利复制？
答：还能复制
主机6379回来并创建新数据：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OJiChI7r-1592367081573)(
./images/捕获237.png)]
从机 6380 获取 kk 的值，可以看到，获取到了 kk 的值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8HN3mz8n-1592367081574)(
./images/捕获238.png)]
● 其中一台从机宕机后情况如何？依照原有它能跟上大部队吗？
答：宕机后，这台从机不会再变成 6379 的从机，而是一台独立的主机，除非在配置文件中事先
配置好了为从机，即：在 REPLICATION 下面的 slaveof 配置好了。不然没配置的话，要想
成为另外一台主机的从机，必须每次连接redis 客户端后，执行 slaveof 主机IP 主机端口
的命令
2）薪火相传
■ 概念：
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么
该slave作为了链条中下一个的master,可以有效减轻master的写压力
■ 中途变更转向:会清除之前的数据，重新建立拷贝最新的
■ slaveof 新主库IP 新主库端口
■ 演示：
①、6379还是作为主机
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-X7yTR6Nz-1592367081575)(
./images/捕获239.png)]
②、6380挂载到6379上面作为从机。使用 info replication可以看到，即使6381挂载到了6380上面
，6380还是以从机的身份存在，只是它的下面挂载了一个6381
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dPvlvIrp-1592367081576)(
./images/捕获240.png)]
③、6381挂载到6380上面
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Dj5SV9am-1592367081577)(
./images/捕获241.png)]
④、这种形式挂载后，在6379服务上新增数据后，在6380和6381服务也是都能获取到新增的数据的
3）反客为主
■ 概念：在一仆二主模式下，如果主机6379挂了后，可以在6380或6381两台服务中重新选择一台服务做
为主机，使用 slaveof no one 命令在对应的希望作为主机的机器上执行，即可选择这台服务作
为主机，然后还需使用 slaveof 新主机IP 新主机端口，在从机上执行。即使之前那台主机6379
重新连接上，它也不会再作为6380或6381的主机。
■ 演示
①、6379挂掉（宕机）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ko8fELK1-1592367081577)(
./images/捕获242.png)]
②、6380执行 slaveof no one 作为主机
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i0nSQhq5-1592367081578)(
./images/捕获243.png)]
③、6381挂载到6380上面
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cm5BZl9v-1592367081579)(
./images/捕获244.png)]
5、复制原理
①、slave启动成功连接到master后会发送一个sync命令
②、Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完
毕之后，master将传送整个数据文件到slave,以完成一次完全同步
③、全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
④、增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
⑤、但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
6、哨兵模式(sentinel)
■ 是什么
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
■ 使用步骤
①、调整结构，6379带着80、81。即一仆二主
②、自定义的/myconf/redis/目录下（启动redis的配置文件目录）新建sentinel.conf文件，名字绝不能
错
③、配置哨兵，填写内容。即编辑 sentinel.conf 文件
● 增加 sentinel monitor 被监控主机名字(自己起名字) 127.0.0.1 6379 1。
例如： sentinel monitor host6379 127.0.0.1 6379 1
● 上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机。即
得票数大于等于1成为主机
④、启动哨兵
启动命令：redis-sentinel /myconf/redis/sentinel.conf 。redis-sentinel 命令是跟 redis-server 在
同一个目录下
■ 演示
①、新建 sentinel.conf 文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QYGHoY2G-1592367081580)(
./images/捕获245.png)]
②、编辑 sentinel.conf 文件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JmBdqmyv-1592367081581)(
./images/捕获246.png)]
③、启动主机从机，将6379作为主机，6380和6381作为从机
6379
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W4tWXD3P-1592367081582)(
./images/捕获247.png)]
6380
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1xstrYbm-1592367081582)(
./images/捕获248.png)]
6381
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O1LR2vFk-1592367081583)(
./images/捕获249.png)]
④、启动哨兵
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EQ5K545S-1592367081584)(
./images/捕获250.png)]
⑤、主机宕机
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pHNvpxrT-1592367081585)(
./images/捕获242.png)]
⑥、主机宕机后，可以看到启动哨兵的窗口在变化，此时正在重新选举新的主机
⑦、重新选取新主机，可以看到6380被重新选举为新的主机，6381作为6380的从机
6380
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3NUqlNRx-1592367081586)(
./images/捕获251.png)]
6381
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mewWTBpd-1592367081587)(
./images/捕获252.png)]
■ 问题：
如果之前的master重启回来，会不会双master冲突？
答：不会，之前的master重启回来后，会被挂载到由哨兵重新选举的主机下
■ 一组sentinel能同时监控多个Master
7、主从复制的缺点
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定
的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
扫一扫
3195
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
