1. 基础
	(1) NoSql非关系型数据库, 高性能键值对数据库
	
	(2) 默认端口 6379

	(3) 存储
		1> 内存的读写数据远大于硬盘
		2> 提高了RDB, AOF两种持久化机制

	(4) 功能	
		1> 支持键的生存时间
		2> 可按照一定规则删除对应的键
		
	(5) 用途
		1> 缓存
		2> 消息队列
		3> 消息订阅/发布

2. 数据类型
	(1) 字符串类型(512M)
	(2) 散列类型(存取需用key, 加字段名称, 可单独修改实例的属性)
	(3) 列表类型 
		可以做队列(消息队列)
		也可以做栈(最近消息, 访客, 回复, 最近发的朋友圈)
	
	(4) 集合类型
		交集(共同好友)
		并集
		差集
	
	(5) 有序集合类型
		可以做排行榜, 权重
	

3. 命令
	(1) 测试客户端与服务器连接正常
		ping - pong
	
	(2) 选择相应的数据库
		select 库名

	(3) 清除
		1> flushall	清除所有数据库
		2> flushdb 清当前数据库

	(4) 查询键
		keys * 查询所有键
		支持正则表达式
	
	(5) 判断键是否存在
		exists 键名

	(6) 删除键
		del 键名 [键名 键名...]

	(7) 获取键的数据类型
		type 键名 [键名 键名...]

	(8) 赋值与取值
		1> 单个键
			get 键名
			set key value
		
		2> 批量
			mget 键名 键名...
			mset key value key value...

	(9) 递增
		incr 键名
		incrby 键名 步长

	(10) 递减
		decr 键名
		decrby 键名 步长

	(11) 追加
		append key value 
		返回值是字符串长度, key不存在则是设值

	(12) 获取字符串长度
		strlen key
	
	(13) 生存时间
		重新设值或清空生存时间

		1> 设置生存时间
			expire key 秒
			pexpire key 毫秒
		
		2> 清除生存时间
			persist key 
		
		3> 查看生存时间
			ttl key 
			-1 无生存时间
			-2 键不存在


4. 集群
	(1) 主从复制(读写分离)
		1> 优点
			避免单点故障
			架构读写分离, 满足读多写少场景

	
		
		2> 主从架构
			一个主master, 对应多个从slave

		3> 主从从...架构
			一个主master, 一个从库, 从库还有从库...
 		
		4> 查看主从信息
			info replication
			
			role: 角色
			connected_slaves: 从库数量
			slave0: 从库信息

		5> 可设置从库只读
		
		6> 主从复制的原理
			1. 当从库与主库建立MS关系后, 会向从库发送SYNC命令
			2. 主库接收到从库命令后, 开始在后台保存快照(RDB), 并将期间接收到的写命令缓存起来
			3. 当快照完成后, 主库会将快照文件和缓存命令一起发送给从库
			4. 从库接收到后, 会加载快照文件, 并执行缓存命令
			5. 同步完成之后, 主库每接收到写命令, 就会将命令发送给从库, 保持数据一致

			主库RDB会大量执行IO, 影响效率, redis 2.8.18版本开始, 实现了无磁盘复制功能(实验阶段)

			原理: 不会将快照保存在磁盘, 而是通过网络发送给从库
			
			开启无磁盘复制：repl-diskless-sync yes

		7> 宕机问题
			1. 从库宕机
				从库重启后, 会自动加入到主从架构, 自动同步数据
				2.8版本以后, 主从断线后恢复的情况下, 实现增量复制

			2. 主库宕机
				第一步, 断开主从关系, 将从库设置为主库
				第二部, 将主库重启后, 设置为从库, 数据就能同步回来
				
				手动执行此过程, 比较麻烦也易出错, redis提供了哨兵(sentinel)功能

			3. 哨兵(sentinel)
				对redis的运行情况进行监控
					监控主库和从库是否正常
					主库出现故障, 将从库转换为主库

				多个哨兵, 不仅同时监控主从库, 而且哨兵之间相互监控

	(2) Redis3.0版本起, 支持集群
		1> 特点
			1. 所有的redis节点彼此互联(ping-pong机制), 内部使用二进制协议优化传输速度和带宽
			2. 节点的fail, 是通过集群中超过半数的节点检测失效后才生效的
			3. 客户端与redis节点直连, 不需要通过proxy层, 客户端连接集群中的任一节点即可
			4. redis-cluster把所有物理节点映射到[0-16383]插槽(slot)上, cluster负责维护 node<->slot<->value
	
			cluster nodes 查看集群信息, 节点id, 插槽数, 连接数

		2> 环境
			按照ruby环境
			执行redis-trib.rb文件, 开启集群

		3> 插槽(slot)
			0-16383个节点, 平均分配给各个节点
				
			命令分析:
				set abc 1234
				
				1. 接收命令
				2. 通过key计算插槽值, 根据插槽值找到对应节点
				3. 重定向的该节点执行命令
			
			注意: 如果有部分插槽数没有指定到节点, 该部分的插槽值所对应的key将无法使用

			插槽值与key的关系:
				key的有效部分, 使用CRC16算法, 计算出哈希值对16384取余

			插槽有效部分, 如果key中存在{}包起来的串儿, {}里面的串儿就是有效部分

			新增和删除节点, 都需要重新分配插槽值

	
		4> 故障处理
			当集群中的任何一个节点下线, 就会导致插槽区有空档, 集群将不可用

			方案: 为节点设置主从, 主库宕机后, 会使用从库继续完成集群
		
		5> 注意事项:
			1. 多键命令(mget, mset), 必须每个键都位于同一节点, 否则报错
			2. 集群中的节点只能使用0号数据库, select切换数据库会报错


5. 散列类型
	(1) 结构
		存储了字段和字段值的映射, 字段值只能是字符串.最多2的32次方-1个字段

	(2) 命令加H
		1. hset 不区分插入和更新, 插入时返回1, 更新时返回0

		2. 判断字符是否存在
			hexists key 字段名

		3. hsetnx key 字段名 字段值
			字段不存在时赋值, 字段存在时不执行

		4. hdel key 字段名 [字段名 字段名...]
			返回删除的个数

		5. 只获取字段名
			hkeys key
		
		6. 只获取字段值
			hvals key

		7. 获取字段数量
			hlen key

6. redis配置文件
	(1) port: 端口
	(2) bind: 绑定ip白名单
	(3) databases: 数据库数量, 默认是16
	(4) daemonize: 设置为守护进程
	(5) maxmemory: 设置最大内存
	(6) maxmemory-policy: 达到内存限制时的处理策略
		策略可以配置, 默认是LRU算法, 最近最少使用

	修改配置文件, 需要重启redis才生效

7. 持久化
	Redis持久化, 有RDB, AOF, 可以单独使用其中一种, 也可以结合使用

	(1) RDB(默认持久化方式)
		1> 通过快照完成持久化
		2> 可在配置文件中, 配置触发条件
			指定时间内, 被更改的键的个数大于指定数值时,就会进行快照

		3> 禁用RDB持久化
			禁用RDB触发条件即可

		4> RDB快照过程
			1. Redis使用fork函数复制一份当前进程(父进程)的副本(子进程)
			2. 父进程继续接收并处理客户端的命令, 子进程将内存中的数据写入到硬盘的临时文件
			3. 当子进程写入所有数据后, 会用该临时文件替换旧的RDB文件

			RDB是压缩的, 可以通过配置禁用压缩

			Redis使用fork复制当前进行, 子进程就会占用和主进程一样的内存资源, 对内存消耗很大
			
	(2) AOF方式
		1. 将服务端的每一条命令记录下来, 保存到硬盘中的AOF文件中, AOF持久会, 默认是不开启的
		2. 查询数据不做记录
		3. AOF文件可以通过命令优化
		
	(3) 命令从缓存写入到硬盘的机制
		可配置
		1. 每次都同步
		2. 每秒同步
		3. 不主动同步, 由操作系统决定(最快但不安全)

8. redis的单线程
	(1)	redis是单进程, 单线程的, 单线程效率高, 是采用的多路IO复用
	(2) 单线程可以避免很多复杂的锁操作, 任何原子操作都可以几乎无代价的实现
	(3) 集群是如何实现单线程的???
		
9. incrby
	浏览量, 点击量, 达到一定量之后再落库