参考文档
Redis官网： https://redis.io/
Redis中文网： http://www.redis.cn/
Redis 命令参考： http://redisdoc.com/string/set.html

1 NoSQL入门概述

NoSQL(NoSQL = Not Only SQL)，意即“不仅仅是SQL”，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL 数据库的产生就是为了解决大规模数据集合、多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。读写速度 读：1s/8w、写：1s/11w

1.1 能干嘛？

易扩展
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展，无形之间在架构的层面上带来了可扩展的能力。

大数据量高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

多样灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。

1.2 传统RDBMS VS NOSQL

RDBMS
	高度组织化结构化数据、结构化查询语言(SQL)
	数据和关系都存储在单独的表中、数据操纵语言，数据定义语言
	严格的一致性、		基础事务
NoSQL
	代表着不仅仅是SQL、没有声明性查询语言
	没有预定义的模式、	键-值对存储，列存储，文档存储，图形数据库
	最终一致性，而非ACID属性、	非结构化和不可预知的数据:
	CAP定理、					高性能，高可用性和可伸缩性

1.3 NoSQL数据库的四大分类

KV
	新浪：			BerkeleyDB + Redis
	美团：			Redis + tair
	阿里、百度：	memcache + Redis
	文档型数据库（bson格式比较多）
	CouchDB、MongoDB
PS：MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

列存储数据库
	Cassandra、Hbase、分布式文件系统
图关系数据库
	Neo4j、InfoGrid
	它不是放图形的、放的是关系比如：朋友圈社交网络、广告推荐系统、社交网络、推荐系统。专注于构建关系图谱

1.4 分布式数据库CAP原理 + BASE原则

传统的ACID分别是什么？
	A (Atomicity) 原子性
	C (Consistency) 一致性
	I (Isolation) 独立性
	D (Durability) 持久性
CAP【CAP理论就是说在分布式存储系统中，最多只能实现两点，三选二】
	C: Consistency（强一致性）
	A: Availability（高可用性）
	P: Partition tolerance（分区容错性）
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性P是我们必须需要实现的。所以我们只能在强一致性C和高可用性A之间进行权衡，没有NoSQL系统能同时保证这三点。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：
	CA - 传统Oracle数据库，单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
	AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。大多数网站架构的选择【数据可以不一定精确，牺牲强一致性P，一定要保证网站可用，实现可用性A，电商、金融系统等】
	CP - Redis、Mongodb，满足一致性，分区容忍必的系统，通常性能不是特别高。

BASE：就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
	基本可用（Basically Available）
	软状态（Soft state）
	最终一致（Eventually consistent）

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

1.5 分布式+集群简介

分布式系统（distributed system）：由多台计算机和通信的软件组件，并通过计算机网络连接（本地网络或广域网）。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：PC、工作站、局域网和广域网上等。

简单来讲：
分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过RPC之间通信和调用，对外提供服务和组内协作。
集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。

1.6 淘宝商品信息的存储方案

商品基本信息【名称、价格，出厂日期，生产厂商等不经常信息】–> 关系型数据库MySQL
商品描述、详情、评价信息【多文字信息描述类】–> 文档数据库MongDB
商品的图片 --> 分布式的文件系统【淘宝TFS、Google的GFS、Hadoop的HDFS】
商品的关键字 --> 淘宝自家ISearch
商品的波段性的热点高频信息【如，情人节的巧克力】 --> 内存数据库Tair、Redis、Memcache

2 Redis入门概述

2.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模式的数据备份

2.2 能干嘛？

	内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务
	取最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面
	模拟类似于HttpSession这种需要设定过期时间的功能
	发布、订阅消息系统
	定时器、计数器

2.3 怎么玩？核心

	数据类型、基本操作和配置
	持久化和复制，RDB/AOF
	事务的控制
	复制（主从关系）

2.4 MAC安装redis

详见安装Redis.txt
cd /usr/local/redis-6.2.6
	./bin/redis-server etc/redis.conf 		启动服务
	./bin/redis-cli 						打开redis客户端

2.5 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.6 常用命令

Key	
set k1 v1、set k2 1、get k1
mset k7 v7 k8 v8		批量操作
mget k7 k8
del k1、strlen k1
append k1 v11		如果key已经存在,将指定的value追加到该 key 原来值的末尾.如果key不存在，与set k1 v1一致

select 1		选择数据库，默认16个数据库，初始使用0号库
dbsize		查看当前数据库key的数量
flushdb		清空当前数据库
flushall		清空所有数据库
ttl key 		查看还有多少秒过期，-1表示永不过期，-2表示已过期 [ttl: time to live]
expire key 秒钟	为给定的key设置过期时间
type key 		查看你的key是什么类型
exists key		判断某个key是否存在
move key db	当前库就没有了，被移除了

String【单值单value】
incr k3、		incrby k3 2	
decr k3、		decrby k3 2	一定要是数字才能进行加减
getrange k1 0 3		如果是字符串，则进行截取、如果是数字，则输出
getrange k1 0 -1		截取全部字符串，等同于get k1
setrange k1 0 aaaa 		从下标0开始赋值，会替代字符串后面的字符，而不是后移
setnx k5 v5			setnx(set if not exist)不存在则赋值，存在不赋值
setex k6 5 v6			setex(set with expire)键秒值，k6的生命周期只有5s
getset k1 v11111		getset(先get再set)，前提是该key已经存在

List	【单值多value，value可重复】 Stack/ArrayList
lpush list01 1 2 3 4 5 		类似入栈
lpop list01				从栈上边、队列左边读 // 5
rpop list01				从栈下边、队列右边读 // 1
rpush list02 1 2 3 4 5 		类似入队列
lpop list02				从栈上边、队列左边读 // 1
rpop list02				从栈下边、队列右边读 // 5
lset list01 0 111			给指定下标赋值，也即是替换
linsert list01 before/after 1 java 	在制定元素22之前/之后插入元素java
lrange list01 0 -1 			从栈上边、队列左边开始查询集合list01 // 1 2 3 4 5
lindex list01 1 			按照索引下标获得元素（从栈上边、队列左边读）
llen list01					list01长度
lrem list01 2 3 			删除list01的2个3
ltrim list01 0 3				截取指定范围的值后再赋值给key
rpoplpush list01 list02		rpoplpush 源列表 目的列表

性能总结：

• 它是一个字符串链表，left、right都可以插入添加；
• 如果键不存在，创建新的链表；
• 如果键已存在，新增内容；
• 如果值全移除，对应的键也就消失了。
• 链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。**

Set	【List单值多value，value不可以重复】 HashSet
sadd set01 1 1 2 3 4 4 	 	添加set01= 1 2 3
smembers set01 			查看set所有元素
sismember set01 1 	     	查看1是否是set01内元素【0不是，1 是】
scard set01				获取集合里面的元素个数
srem set01 1 				删除集合中元素
srandmember set01 3 		从集合中随机显示3个整数
spop set01 				集合中元素随机出栈
smove set01 set02 3		作用是将key1里的某个值赋给key2
sdiff set01 set02			差集，属于set01，不属于set02
sinter set01 set02			交集
sunion set01 set02			并集

Hash【KV模式不变，但V是一个键值对】
hset user id 11 name zhupeng
hger user id
hgetall user
hdel user id
hexists user id			判断key里面的某个值的key
hkeys user			查询所有key值
hvals user			查询所有value值
hlen user				查询key长度
hincrby user id 2 		value值加
hincrbyfloat user score 0.5
hsetnx user age 27		字段不存在则加入

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

zadd zset01 60 v1 70 v2 80 v3	增加
zrange zset01 0 -1		查询，不包括分数score
zrange zset01 0 -1 withscores 	查询，包括分数score
zrangebyscore zset01 60 90 	查询[60, 90]的value
zrangebyscore zset01 60 (90 	查询[60, 90)的value
zrangebyscore zset01 (60 (90 	查询(60, 90)的value
zrangebyscore zset01 60 90 	limit 2 2	limit 开始下标步 多少步[Limit 作用是返回限制]
zrem zset01 v3 		删除某score下对应的value值
zcard zset01  	 	查询个数
zrank zset01 v1 	查询下标
zrevrank key values值，作用是逆序获得下标值
zrevrange
zrevrangebyscore key 结束score 开始score

3 Redis配置文件

Redis 的配置文件位于 Redis 安装目录下，文件名为 redis.conf，说明如下：

1、Redis 默认不是以守护进程的方式运行，可以通过该配置项修改，使用 yes 启用守护进程 
daemonize no
2、当 Redis 以守护进程方式运行时，Redis 默认会把 pid 写入 /var/run/redis.pid 文件，可以通过 pidfile 指定
	pidfile /var/run/redis.pid	
3、指定 Redis 监听端口，默认端口为 6379，【6379 在手机按键上 MERZ 对应的号码，而 MERZ 取自意大利歌女 Alessia Merz 的名字】
port 6379
4、绑定的主机地址
	bind 127.0.0.1	
5、当客户端闲置多长秒后关闭连接，如果指定为 0 ，表示关闭该功能
	timeout 300
6、指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice	
	loglevel notice	
7、日志记录方式，默认为标准输出，如果配置 Redis 为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给 /dev/null
	logfile stdout	
8、设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
	databases 16
9、Redis 默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
分别表示 900 秒（15 分钟）内有 1 个更改，300 秒（5 分钟）内有 10 个更改以及 60 秒内有 10000 个更改。
save <seconds> <changes>	
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
10、指定存储至本地数据库时是否压缩数据，默认为 yes，Redis 采用 LZF 压缩，如果为了节省 CPU 时间，可以关闭该选项，但会导致数据库文件变的巨大
	rdbcompression yes	
11、指定本地数据库文件名，默认值为 dump.rdb
	dbfilename dump.rdb	
12、指定本地数据库存放目录
	dir ./	
13、设置当本机为 slave 服务时，设置 master 服务的 IP 地址及端口，在 Redis 启动时，它会自动从 master 进行数据同步
	slaveof <masterip> <masterport>	
14、当 master 服务设置了密码保护时，slav 服务连接 master 的密码
	masterauth <master-password>
15、设置 Redis 连接密码，如果配置了连接密码，客户端在连接 Redis 时需要通过 AUTH 命令提供密码，默认关闭
	requirepass foobared
	redis修改登陆密码
	config get requirepass 			# redis默认登陆密码为空”“
	config set requirepass “123456” 	# 设置redis登陆密码
	auth 123456 				# 登陆
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

4 Redis持久化【RDB、AOF】

持久化之RDB

RDB是什么？
RDB（Redis DataBase）在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
过程：
（1）Redis会单独创建（fork）一个子进程来进行持久化
（2）先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

RDB配置？【SNAPSHOPPONG】
	#save 3600 1		# 15分钟变动1次
	#save 300 100	# 5分钟变动100次
	#save 60 10000	# 1分钟变动1w次
	save				save时只管保存，其它不管，全部阻塞。
	bgsave			Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
	dbfilename dump.rdb 			启用rdb持久化存储
	stop-writes-on-bgsave-error yes 	如果配置成no，不在乎数据不一致或者有其他方法控制
	rdbcompression yes 			是否启动rdb文件压缩算法
	rdbchecksum yes 				存储快照后，还可以让redis使用CRC64算法进行数据校验，大约会增加10%的性能小号，如果希望得到最优的性能提升，可以关闭该功能

如何恢复？
	将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

RDB优点：
	适合大规模的数据恢复
	对数据完整性和一致性要求不高
RDB缺点：
	Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，大致2倍的膨胀性需要考虑。
	在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

总结
	RDB是一个非常紧凑的文件。
	RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的性能。
	与AOF相比，在恢复大的数据集的时候，RDB方式会更快一一些。
	数据丢失风险大。
	RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候fork的过程是非常耗时的吗，可能会导致Redis在一些毫秒级不能回应客户端请求。

持久化之AOF

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

AOF配置【APPEND ONLY MODE】
	appendonly no  					# 默认no
	appendfilename "appendonly.aof" 	# 文件名
	appendfsync [always/everysec/no]
	always		同步持久化，redis每次发生数据改变都会被立即记录到磁盘，性能较差但数据完整性最好
	everysec		默认推荐，异步操作，每秒记录一次，最多损失1s的数据
	no			不进行持久化
	no-appendfsync-on-rewrite no 重写时是否运用appendfsync，默认no即可，保证数据安全性
	auto-aof-rewrite-percentage 100
	auto-aof-rewrite-min-size 64mb

rewrite
是什么：
	AOF采用文件追加方式，文件会越来越大。为避免出现此种情况，新增了重写机制， 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof
重写原理
	AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)， 遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似.
触发机制
	Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
		auto-aof-rewrite-percentage 100
	auto-aof-rewrite-min-size 64mb 【一般3GB起步】

AOF优点：
	每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
	每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
	不同步：appendfsync no 从不同步
AOF缺点：
	相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
	Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同


总结
	AOF文件时一个只进行追加的日志文件
	Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
	AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松
	对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
	根据所使用的fsync 策略，AOF的速度可能会慢于RDB

如何选择？

1、RDB持久化方式能够在指定的时间间隔内对数据进行快照存储，AOF持久化方式记录每次对服务器的写操作，当服务器重启时会重新执行这些命令来恢复原始数据，Redis还会对AOF文件进行重写，避免文件体积过大。
2、建议同时开启RDB、AOF持久化方式：redis会优先载入aof文件来恢复原始数据，因为通常情况下aof文件保存的数据集比rdb文件保存的数据集要完整。但是也不建议只用AOF，因为RDB更适合备份数据库了，而AOF数据不断变化，不好备份。
3、只做缓存：可以都不使用RDB、AOF

性能建议
	因为RDB文件只做后备用途，建议只在slave上持久化RDB，而且重要15分钟备份一次就够了【只保留 save 900  1】
	如果启用AOF，好处是在最坏情况下也只会丢失1s数据，启动脚本简单加载自己的aof文件就可以恢复，代价一是带来了持续的IO，二是rewrite的最后将rewrite过程中产生的新数据写到新文件会造成不可避免的阻塞，应当尽量减少rewrite的频率，建议auto-aof-rewrite-min-size 设置为5G，默认超过原来的100%进行重写。
	如果不启用AOF，仅靠master-slave Replication实现高可用也可以，能节省一大笔IO、以及重写rewrite带来的系统波动，代价是如果master/slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个master/slave的RDB文件。

5 Redis事务（Transacttion）

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

能干嘛？
	一个队列中，一次性、顺序性、排他性的执行一系列命令。

常用命令
命令				描述
MULTI				标记一个事务块的开始。
WATCH key [key …]	监视一个(或多个) key，如果在事务执行之前这个key 被其他命令所改动，那么事务将被打断。
UNWATCH			取消 WATCH 命令对所有 key 的监视。
EXEC				执行所有事务块内的命令。
DISCARD			取消事务，放弃执行事务块内的所有命令。

常见CASE

case5：watch监控
WATCH 使得 EXEC 命令需要有条件地执行： 事务只能在所有被监视键都没有被修改的前提下执行， 如果这个前提不能满足的话，事务就不会被执行。
Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变， 比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化， EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

PS：悲观锁/乐观锁/CAS(Check And Set)
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。【高一致性，低并发】
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。乐观锁策略:提交版本必须大于记录当前版本才能执行更新。【高并发，低一致性】

CAS：信用卡可用余额和欠额案例

事务特性
	单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
	没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行， 也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
	不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
	不遵循传统的ACID中的AI

6 Redis主从复制、读写分离

是什么？
	也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主，主要负责读写分离、容灾恢复。

怎么玩？
	slaveof 主库IP 主库端口	【配从(库)不配主(库)】

准备工作：启动多个Redis服务器，部分配置文件参数修改如下：
daemonize yes、pid文件名字、port指定端口、logfile日志名称、dump.rdb配置文件名字

case1：一主二仆【中心化架构】

常见问题
1、slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制？
答：从头开始复制；123也可以复制
2、从机是否可以写？set可否？
答：从机不可写，不可set，主机可写
3、主机shutdown后情况如何？从机是上位还是原地待命
答：从机还是原地待命（咸鱼翻身，还是咸鱼）
4、主机又回来了后，主机新增记录，从机还能否顺利复制？
答：能
5、其中一台从机down后情况如何？依照原有它能跟上大部队吗？
答：不能跟上，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件（具体位置：redis.conf搜寻#### REPLICATION ####）```

case2：薪火相传【去中心化架构】

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力（奴隶的奴隶还是奴隶），中途变更转向会清除之前的数据，重新建立拷贝最新的
slaveof 新主库IP 新主库端口

case3：反客为主

使当前数据库停止与其他数据库的同步，转成主数据库，形成一个中心点
SLAVEOF no one

case4：哨兵模式(sentinel)

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

怎么玩(使用步骤)
1、调整结构，6379带着6380、6381
2、新建sentinel.conf文件，名字绝不能错
3、配置哨兵,s填写内容
sentinel monitor host 127.0.0.1 6379 1
数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
4、启动哨兵
redis-sentinel /sentinel.conf（上述目录依照各自的实际情况配置，可能目录不同）
5、正常主从演示
6、原有的master挂了
7、投票新选，重新主从继续开工，info replication查查看

问题：如果之前挂了的master重启回来，会不会双master冲突？
答： 不会，原master，变成slave