xql-Redis学习笔记
Redis学习笔记
- NoSql特性
- Redis入门介绍
- 杂乱开始(鸡零狗碎的内容)
- 数据类型
-
- Redis的五大数据类型简介
- key
- String
- List
- Set
- Hash
- Zset(sorted set)
- Redis配置文件介绍
-
- GENERAL通用
- SECURITY
- Limits限制
- 常见redis.conf介绍
- Redis持久化（Redis Persistence）
-
- RDB（Redis DataBase）
-
- 概念
- 相关属性
- 如何触发RDB快照
- 如何恢复
- 优势
- 劣势
- 如何停止
- AOF（Append Only File）
-
- 概念
- 相关属性
- AOF的启动/修复/恢复
- Rewrite
- 优势
- 劣势
- RDB与AOF的选择
- 性能建议
- 事务
-
- 常用命令
-
-
- 正常执行/放弃事务
- 全体连坐
- 冤头债主
- watch监控
- 阶段
- 三个特性
-
- 消息订阅发布简介
- 主从复制
-
- 如何操作
- 常用三招
-
- 一主二仆
- 薪火相传
- 反客为主
- 复制原理
- 哨兵模式（sentinel）
-
-
-
- 概念
- 操做
- 一组sentinel能同时监控多个master
- 复制的缺点
-
-
- Jedis
-
- 联通
- 常用API
- 事务
- 主从复制
- JedisPool
NoSql特性
- C(Consistency):强一致性
- A(Availability):可用性
- P(Partition tolerance):分区容错性
CAP的核心理论:一个分布式系统不可能很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个,即CAP原则只能三选二 ;
因此根据CAP原理将NoSql数据库分成了满足CA原则\满足CP原则和满足AP原则三大类
- CA- 单点集群,满足一致性和可用性的系统,通常在扩展性上不太强大
- CP- 满足一致性和分区容错性,通常性能不是特别高
- AP- 满足可用性和分区容错性,通常可能对一致性要求低一点
CAP理论是说在分布式系统中的最多只能实现上面的两点,由于当前的网络硬件肯定会出现延迟丢包等问题,所以
分区容错性是必须要实现的,所以我们要在一致性和可用性之间进行权衡,没有NoSql系统能同时保证这三点
CA-传统Oracle数据库
AP-大多数网站架构的选择
CP-Reds Mongodb
分布式架构时必须做出取舍
Base就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案
Basically Available：基本可用
Soft state：软状态
Eventually consistent：最终一致
思想：通过让系统放松对某一时刻数据一致性上的要求来换取系统整体伸缩性和性能上改观。缘由就在于大型分布式系统往往由于地域分布和极高的性能要求，不可能采用分布式事务来解决这一问题。
Redis入门介绍
Redis：REmote DIctionary Server 远程字典服务器
开源免费、C语言编写、遵守BSD协议，高性能key-value分布式内存数据库
被人们称为数据结构服务器
Redis特点：
- 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用
- 不仅支持简单的key-value类型的数据，同时还提供list、set、zset、hash等数据结构的存储
- 支持数据的备份，即master-slave模式的数据备份
杂乱开始(鸡零狗碎的内容)
查看redis是否启动：ps -ef|grep redis
连接redis：redis-cli -p 6379
- Redis是个单进程，以单进程模型来处理客户端的请求。对读写等事件的响应是通过对epoll函数的包装来做到的。Redis的实际处理速度完全依靠主进程的执行效率
- Epoll是Linux内核为处理大量文件描述符而做了改进的epoll，是Linux下多路复用IO接口select/poll的增强版本，他能显著提高程序在大量并发连接中只有少量活跃的情况下的系统的CPU利用率
- 默认使用16个数据库，类似数组下标从0开始（0-15），使用指令”select空格数字“来切换数据库， 如：select 7 这就切换到了下表为6的数据库
- DBSIZE查看当前数据库key的数量
- 罗列所有的key：keys *
- 查找以字母开头的key：k?
- FLUSBDB 清空当前库 尽量不要用
- FLUSHALL 清空所有库 尽量不要用
- 统一密码管理，16个库都是同样密码，要么都ok要么一个也来年接不上
- Redis索引从0开始
- 默认端口是6379
数据类型
Redis的五大数据类型简介
- String（字符串）：Redis中最基本的类型，一个key对应一个value；二进制安全，意思是redis的string可以包含任何数据，比如jpg图片或者序列化的对象；一个Redis中字符串value最多可以是512M
- Hash（哈希）：类似 java 里的Map
- List 列表：简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边），底层实际上是一个链表
- Set 集合：string类型的无序无重复集合，通过Hash Table实现
- Zset ：sorted set,有序集合，string类型元素的集合，不同的是每个元素都会关联一个double类型的分数，Redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的，但分数score却可以重复
其余三种：Bitmaps-位图、HyperLogLog、GEO-地理信息定位
Redis命令参考大全 ：http://redisdoc.com/
key
keys * #查看所有key
exists key #判断某个key是否存在
move key db #例如 move k1 1 移动k1到下标为1的数据库 要想获取k1 要到下标为1的数据库 get k1
expire key 秒 #为指定的key设置过期时间
ttl key #查看还有多少秒过期 -1表示永不过期 -2表示已过期 过期后，就不存在设置的key了
type key #查看你的key是什么类型
del key #删除key
dump key #序列化key，并返回序列化的值
如果存在键值对 k1-v1，现在执行指令set k1 v2,v2会将v1覆盖
String
set、get、del方法不变
- append：
- set k1 v1
- get k1 -->v1 #获取k1的值
- append k1 12345 #执行append操作
- get k1 -->v112345 #得到数值 v112345
- strlen:
- strlen k1
- —> 7 #检测到k1的长度为7
- incr：
- set k2 1 #将数字不断进行加1操作 一定是数字才能进行加减
- incr k2 --> k2=2
- incr k2 -->k2=3
- incr k2 -->k2=4
- decr： #将数字不断进行减1操作 一定是数字才能进行加减
- decr k2 —>k2=3
- decr k2 —>k2=2
- decr k2 —>k2=1
- incrby： #将数字按照规定进行加操作 一定是数字才能进行加减
- set k3 1
- incrby k3 2 —>k3=3
- incrby k3 2 —>k3=5
- incrby k3 2 —>k3=7
- decrby：#将数字按照规定进行减操作 一定是数字才能进行加减
- decrby k3 2 —>k3=5
- decrby k3 2 —>k3=3
- decrby k3 2 —>k3=1
- getrange: #获取指定区间范围内的值，类似between…and 的关系
- set k4 ab12345
- getrange k4 0 -1 —>ab12345 #从下标0开始到-1结束，意思就是查询全部范围
- getrange k4 0 3 —>ab12 #从下标0开始，到下标为3结束
- setrange: #设置指定区间范围内的值
- set k5 ab123456
- setrange k5 0 mmm —>k5=mmm23456
- setex: set with expire ；使用格式： 键+秒+值
- setex k6 10 v6 含义：设置键k6，value=v6，10秒后过期，过期后不存在键k6
- setnx: set if not exist
- setnx k6 v66 上面我们设置k610秒后过期，现在我们用setnx语句，含义是，当k6不存在时，才赋值，也就是说，k610秒后过期了，再设置k6的value为v66
- mset/mget: 因为set关键字不能一次性设置多个键值对，get也不能一次性获取多个键值对，所以使用mset和mget进行操作
- mset kk1 vv1 kk2 vv2
- mget kk1 kk2 —>vv1 vv2
- msetnx: 现在存在kk1 和kk2两个键值对，使用msetnx给不存在的键设置值
- msetnx kk1 va kk2 vb kk3 vc —>结果 (integer) 0 没有生效，也就是说存在的已经键值对不能和不存在的一起使用msetnx
- msetnx kk4 vd kk5 ve —>成功
List
单值多value
这里我把List理解为一个栈，先进后出，后进先出
- lpush/rpush/lrange: 从左边按顺序放入/从右边按顺序放入/从左边按顺序取出 简单记忆 L-最左边的再栈底 R-最右边的再栈底
- lpush lista 1 2 3 4 5
- lrange lista —> 取出值的顺序为5 4 3 2 1
- rpush listb 1 2 3 4 5
- lrange listb —>取出值的顺序为1 2 3 4 5
- lpop/rpop: 每次只取出List中的一个值 最顶上的那个值 栈顶值
- lpop list a —>5
- rpop lista ---->1
- lrange lista ---->4 3 2
- lpop listb —>1
- rpop listb —>5
- lrange listb —>2 3 4
- lindex 按照索引下标获得元素
- lrange lista ---->4 3 2
- lrange listb —>2 3 4
- lindex lista 3 —>(nil) 含义：没有3号位 所以报空
- lindex lista 2 ---->2
- lindex lista 1 ---->3
- llen 获取集合的长度
- llen lista ---->3
- lrem key :删除n个value
- rpush lsitc 1 1 1 2 2 2 3 3 3 4 4 4 5 6 7
- llen listc ---->15
- lrem listc 3 4 #含义：在c集合中删除3哥元素值为4的元素
- lrange listc —>1 1 1 2 2 2 3 3 3 5 6 7 #可以看到，在c集合中已经将3个4删除了
- ltrim key 开始index 结束index #截取指定范围的值后再赋值给key
- del listc
- lpush listc 1 2 3 4 5 6 7 8
- ltrim listc 0 5
- lrange listc ---->8 7 6 5 4 3
- del listc
- lpush listc 1 2 3 4 5 6 7 8
- ltrim listc 3 5
- lrange listc —>5 4 3
- rpoplpush 源列表 目的列表 # 含义：第一个集合的栈底元素出栈，到第二个集合的栈顶
- del lista
- del listb
- lpush lista 1 2 3 4 5
- rpush listb 1 2 3 4 5
- lrange lista ---->5 4 3 2 1
- lrange listb ----->1 2 3 4 5
- rpoplpush lista litb
- lrange listb ---->1 2 3 4 5 1
- lset key index value
- del lista
- lpush liata 1 2 3 4 5
- lrange lista ----->5 4 3 2 1
- lset lista 2 x
- lrange lista —>5 4 x 2 1
- linsert key before/after 值1 值2
- lrange lista —>5 4 x 2 1
- linsert lista before x java
- lrange lista —>5 4 java x 2 1
- linsert lista after x c#
- lrange lista —>5 4 java x c# 2 1
list性能总结：
- 是一个字符串列表，left和right都可以插入
- 如果键不存在，创建新的列表
- 如果值全部移除，对应的键也就消失了
- 链表的操作无论是头还是尾效率都很高，但假如是对中间的元素进行操作，效率就很惨淡了
Set
单值多value
-
sadd key value1 value 2… 想集合中添加元素
- sadd set01 1 1 1 2 2 2 3 3 3
- smembers set01 ----->1 2 3 #smembers 获取set集合元素
- sismember 1 —>integer 1 表示“1”这个元素在set01这个集合中存在
- sismember x —>integer 0 表示“x”这个元素在set01这个集合中不存在
-
scard 获取集合里面的元素个数
- scard set01 ---->3
-
srem key value 删除集合中的元素
- srem set01 3
- smembers set01 —>1 2
-
srandmember key 某个整数（随机出几个数）
- del set01
- sadd set01 01 1 2 3 4 5 6 7
- standmember set01 3 #含义 在set01中随机出3个数字
-
spop key 随机出栈
- del set01
- sadd set01 1 2 3 4 5 6 7 8
- spop set01 # 出栈后元素还存在吗？？？？
-
smove key1 key2 在key1中的某个值 做用是将key1中的某个值赋值给key2 （前提是key2要存在）
- del set01
- sadd set01 1 2 3
- sadd set02 a b c
- smove set01 set02 1 #含义：将set01集合中的元素值为1的元素赋值给set02
- smembers set02 ---->a b c 1
-
set集合中的数学集合类（交叉 补 并）—差集sdiff —交集sinter —并集sunion
- del set01
- del set02
- sadd set01 1 2 3 4 5
- sadd set02 1 2 3 a b
- sdiff set01 set02 —>4 5 (以左边的为标准，即以前面的集合为全集，差集为4和5)
- sinter set01 set02 —>1 2 3
- sunion set01 set02 —>a 2 1 b 5 3 4 为什么顺序不一样呢
Hash
KV模式不变，但V是一个键值对！拿下面的user举例 ，key是user，value是（id，001）这个键值对
hset/hget/hmset/hmget/hgetall/hdel/hkeys/hvals 这几个指令重点掌握
- hset user id 001
- hget user id —>001
- hmset customer id 001 name 张三 age 20
- hmget customer id name age ----> 001 张三 20
- hgetall customer —>id 001 name 张三 age 20
- hdel cudtomer age #含义：删除了age这个属性
- hlen customer —>2 获取键的长度
- hexists key 在key里面的key
- hexists customer id —>(integer)1 #含义：表示id这个属性在customer这个key中存在
- hexists customer email —>(integer)0 #含义：表示email 这个属性在customer这个key中不存在
- hkeys customer —>id name
- hvals customer —>001 张三
- hincryby/hincryfloat key 属性 参数
- hset customer age 20
- hincryby customer age 2 —>每次执行，age属性加2
- hset customer score 99.5
- hincryfloat customer score 0.5 —>100 每次加0.5
- hsetnx key 属性 参数 如果属性不存在，就将参数放进去
- hsetnx customer age 20 —(integer 0)
- hsetnx customer email [email protected] —>(integer)1
Zset(sorted set)
在set的基础上，加了一个score值；之前set是k1,v1,v2,v3…，现在zset是k1 score1 v1 score2 v2 …
key是一个整体，score和v是一个整体
- zadd/zrange
- zadd zset01 60 v1 70 v2 80 v3 90 v4 100 v5
- zrange zset01 0 -1 #获取zset01中的全部值 ---->v1 v2 v3 v4 v5
- zrange zset01 0 -1 withscores #获取zset01的全部值 ，携带score
- zrangebyscore key 开始score 结束score 根据score后去范围
- zrangebyscore zset01 60 90 —>v1 v2 v3 v4
- zrangebyscore zset01 60 90 withscores -->v1 60 v2 70 v3 80 v4 90
- zrangebyscore zset01 60 (90 # “(” 代表不包含 找出大于等于60小于90的 —> v1 v2 v3
- zrangebyscore zset01 (60 (90 #大于60小于90 —> v2 v3
- zrangebyscore zset01 60 90 limit 2 2 —>v3 v4 #现在有v1-5 5个等级，该指令含义是从第二个后的元素开始，找两个
- zrem key 某score对应的value值，作用是删除元素
- zrem zset01 v5 —>(integer)1 删除了v5
- zcard zset01 ---->(integer)4 #前面我们已经删除了v5，所以元素还有4ge
- zcount zset01 60 80 —> 3 #统计60到80分的个数
- zrank zset01 v4 —>3 #获取v4的下标
- zscore zset01 v4 —>90 #获取v4对应的值
- zrevrank key values值，作用是逆序获得下标值
- zrange zset01 0 -1 #获取zset01中的全部值 ---->v1 v2 v3 v4
- zrevrank zset01 v4 ----> #v4的下标是3，你过来是0
- zrevrange zset01 0 -1 —>v4 v3 v2 v1 #逆序获得全部值
- zrevrangebyscore zset01 60 90 —报错
- zrevrangebyscore zset01 90 60 —> v4 v3 v2 v1
Redis配置文件介绍
GENERAL通用
- Tcp-backlog：设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手的队列+已完成三次握手的队列。在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减少到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。官方默认值511
- Tcp-keepalive：单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置为60
- Loglevel 日志等级
- **Logfile ** 日志名称
- Syslog-enabled：是否把日志输出到syslog中，默认是不输出
- Syslog-ident：指定syslog里的日志标志 默认名字redis
- Syslog-facility：指定syslog设备，值可以是USER或LOCAL0到LOCAL7
SECURITY
包含访问密码的查看、设置和取消
Limits限制
- Maxclients :最大客户端数量 默认值10000
- Maxmemory :最大内存限制
- Maxmemory-policy :最大
- Maxmemory-samples :最大样本数量。LRU算法和TTL算法都并非是精确的算法，二十估算值，所以可以设置样本的大小，redis默认会检查这么多个key丙选择其中LRU的nage 默认值5个
缓存过期策略有6种：
- volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
- allkeys-lru：使用LRU算法移除key
- volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
- allkeys-random：移除随机的key
- volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
- noeviction:永不过期策略 默认。不进行移除，只针对写操作，只是返回错误信息
常见redis.conf介绍
-
Redis默认不是以守护进程的方式进行，可以通过配置项修改，使用yes启用守护进程 daemonize no
-
当Redis以守护进程方式进行时，Redis默认把pid写如/var/run/rdis.pid文件，可以通过pidfile指定 pidfile /var/run/redis.pid
-
指定redis监听端口，默认端口6379
-
绑定的主机地址 bind 127.0.0.1
-
当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能 timeout 300
-
指定日志记录级别，Redis共支持四个级别：debug verbose notice warning 默认值verbose
-
日志记录方式，默认为标准输出，如果配置Redis为守护进程的方式运行，而这里又配置日志记录方式为标准输出，则日志将会发送给/dev/null logfile stdout
-
设置数据库的数量，默认数据库为0号数据库，可以使用select 命令连接上指定数据库id 最大支持16个
-
指定多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合 save Redis默认配置文件中提供了三个条件save 900 1 save 300 10 save 60 10000
-
指定存储本地数据库时是否被压缩，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但是会导致数据库文件变得巨大， rdbcompression yes
-
指定本地数据库文件名，默认值为dump.rdb dbfilename dump.rdb
-
指定本地数据库存放目录 dir ./
-
设置本机为slav服务时，设置master服务的IP地址及端口号，在Redis启动时，他会自动从master进行数据同步，slaveof
-
当master服务设置了密码保护时，slav服务连接master的密码 master
-
设置Redis连接密码，如果配置了连接密码，客户端在连接redis时需要通过auth命令提供密码，默认关闭 requirepass foobared
-
设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的连接数为Redis进程可以打开的最大文件描述符数量，如果设置maxclients 0,表示不做限制。当客户端连接数达到限制时，Redis会关闭新的连接，并向客户端返回mac number of clients reached 信息 maxclients 128
-
指定Redist最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会尝试已到期或即将到期的key，当此方法处理后，仍然达到最大内存设置，将无法在进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把key存放内存，value存放在swap区 maxmemory
-
指定是否每次跟新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时，导致一段时间内的数据丢失。因为Redis本身同步数据文件时按照上面的slav条件来同步的，所有的数据会在一段时间内存在与内存中。默认为no appendonly no
-
指定更新日志文件名，默认为appendonly.aof appendfilename appendonly.aof
-
指定更新日志条件，共有三个可选值
- 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持久化（Redis Persistence）
RDB（Redis DataBase）
概念
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就输行话讲的Snapshot快照，它恢复时是将快照文件直接读取到内存中。
Redis会单独创建（fork）一个进程来持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果要进行大规模的数据恢复，且对于数据恢复的完整性不是特别敏感（数据精确度不高），那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失
相关属性
fork：fork的作用是赋值一个与当前进程一样的进程。新进程的所有数据（变量，化境变量、程序计数器等）数值和原进程一致，但是是一个全新的过程，并作为原进程的子进程
RDB默认保存的是dump.rdb文件，可以进入配置文件进行修改
RDB是整个内存的压缩过的Snapshot，RDB的数据结构可以配置复合的快照出发条件，RDB的默认出发条件是：
- 1分钟内改了10000次
- 5分钟内改了10次
- 15分钟内改了1次
这些默认值都可以修改；如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以，这样redis会立即进行持久化
Stop-writes-on-bgsave-error:后台在保存数据时，如果发生了错误，前台要停写入，该值默认时开启的，也就意味着出错了就刹车，如果 配置成了no，表示你不在乎数据不一致或者你有其他的手段发现和控制
rdbcompression:对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话（默认yes），redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置关闭此功能 （妈的，就这一点内存占用率，你节约个屁啊）
rdbchecksum:在存储快照后，还可以让redis使用CRC64算法来进行数据校验但是这样做会增加大约10%的性能消耗，如果希望获取到最大性能的提升，可以关闭此功能 默认值yes
dbfilename：即RDB的默认保存文件名称
如何触发RDB快照
-
配置文件中默认的快照配置
冷拷贝后重新使用（即从主机拷贝到备机上使用），cp dump.rdb dump_new,rdb
-
命令save或者bgsave
- Save：只管保存，其他不管，全部阻塞
- BGsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
-
执行flushall命令，也会产生dump.rdb问价，但是里面是空的，无意义
如何恢复
将备份文件（dump.rdb）移动到Redis安装目录并且冲洗启动Redis服务即可，config get dir获取目录
优势
- 适合大规模的数据恢复，对数据完整性和一致性要求不高
- 是一个非常紧凑的文件
- RDB在保存RDB文件时父进程唯一要做的就是fork存储子进程，接下来要做的工作全部由紫荆城来做，父进程不需要再进行任何IO操作，所以持久化方式可以最大化Redis的性能
劣势
- 在一定时间间隔内做一次备份，所以如果Redis意外挂了，就会丢失最后一次快照后的所有修改,相对而言数据的丢失风险较大
- RDB需要经常fork子进程来保存数据到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级之间不能响应客户端请求
- fork的时候，内存中的数据被拷贝了一份，大致两倍的膨胀性需要考虑
如何停止
动态停止RDB保存规则的方法：redis-cli config set save “”
AOF（Append Only File）
AOF的出现是为了解决RDB在一定时间间隔内做一次备份，所以如果Redis意外挂了，就会丢失最后一次快照后的所有修改,相对而言数据的丢失风险较大
概念
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下拉（flushall操作会记录，读取操作不记录），只许追加问价但不允许改写文件，Redis启动之初会读取改文件重新构建数据，换言之，Redis重启的话就根据日文文件的内容将写指令从前到后执行一次来完成数据的恢复工作
相关属性
AOF默认保存的是appendonly.aof文件
appendonly no 该算法默认是关闭的
如果rdb文件和aof文件两者同时出现，默认会去找aof文件，如果aof文件错误，启动不起来Redis；但是会有一个redis-cheak-aof文件，执行指令redis-cheak-aof --fix appendonly.aof(这里是要修复的aof文件名)将文件修复
Appendfsync(同步机制)：
- always：同步持久化，每次发生数据变更会被立即记录到此磁盘，性能较差，但数据完整性比较号好
- everysec：出场默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失
- no：从不同步
no-appendfsync-on-rewrite：重写是是否可以运用appendfsync，用默认no即可，保证数据安全性
auto-aof-rewrite-min-size:设置重写的基准值，默认是64M
auto-aof-rewrite-percentage：设置重写的基准值，这里是百分比值，默认是100（100%）
AOF的启动/修复/恢复
- 正常恢复：将appedonly no 修改为yes，将有数据的aof文件赋值一份保存到对应目录（config get dir）（运维会将问价拷贝到备用机），重启redis后会重新加载该文件
- 异常恢复：如果aof文件错误，启动不起来Redis；但是会有一个redis-cheak-aof文件，执行指令redis-cheak-aof --fix appendonly.aof(这里是要修复的aof文件名)将文件修复，重启redis后会重新加载该文件（也是运维来做），同理，dump文件也有一份修复文件
Rewrite
AOF的重写概念：AOF采用文件追加的方式，文件会越来越大，为了避免这种情况，新增了重写机制，当AOF文件的大小超过了所设定的阈值的时候，Redis会启动AOF文件内容的压缩机制，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
重写原理：Aof文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
触发机制：Redis会记录上次重写时AOF的大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍（100%）且文件大于64M时触发(对应上方相关属性的两个值)
优势
- 每秒同步：appendfysnc always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差，但数据完整性比较好
- 没秒同步：appendfysnc everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失
- 不同步：appendfysnc no 从不同步
劣势
- 相同数据而言aof文件要远大于rdb文件，恢复速度相比于rdb较慢
- Aof运行效率要比rdb慢，每秒同步策略较好，不同步效率和rdb相同
RDB与AOF的选择
-
RDB持久化方式能够再指定时间间隔内对对数据惊醒快照存储
-
AOF持久化方式记录每次服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，是的AOF文件的体积不至于过大
- 只做缓存：如果你只希望数据在服务器运行的时候存在，你也可以不适用任何持久化方式
- 同时开启两种持久化方式：在这种情况下，当Redis重启的时候会优先加载AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据比RDB问价保存的数据要完整；RDB数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢，作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启不会有AOF可能潜在的bug，留着作为一个万一的手段
性能建议
因为RDB文件只用作后备用途，建议只在Salve上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1 这条规则。
如果Enable 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的事务能干什么呢？一个队列中，一次性、顺序性、排他性的执行一系列命令
常用命令
深刻理解这几个指令！！！！
- multi：标记一个事务块的开始
- exec：执行所有事务块内的命令
- discard：取消事务，放弃执行事务块内的所有命令
- unwatch：取消watch命令对所有key的监视
- watch key… :监视一个或多个key，如果在事务执行之前，这个（或这些）key被其他命令所改动，那么事务将被打断
正常执行/放弃事务
mutil
set k1 v1 --->queued
set k2 v2 --->queued
set k3 v3 --->queued
get k3 v3 --->queued
exec(在这可以使用discard取消该事务) --->结果开始
OK
OK
OK
v3
全体连坐
mutil
set k1 v1 --->queued
set k2 v2 --->queued
set k3 v3 --->queued
getset k3 v3 --->error
set k4 v4 --->queued
exec --->error
get k4 --->nil #证明事务内发生错误，导致命令全部失效
冤头债主
keys *
1)k1(实际值v1)
2)k2(实际值v2)
3)k3(实际值v3)
mutlti
incr k1
set k2 22
set k3 33
set k3 33
set k4 v4
get k4
exec
1)error
2)ok
3)ok
4)ok
5)ok
6)v4
全体连坐和冤头债主的区别在哪？
全体连坐是执行命令报错了，导致整体进行错误；冤头债主时执行的命令没有错误，但是执行格式不正确！
watch监控
unwatch
一旦执行了exec之前加密的监控锁都会被取消掉了
阶段
开启：以MUTIL开启一个事务
入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
执行：由exec命令触发事务
三个特性
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序的执行。事务在执行过程中，不会被其他客户端发送来的命令请求所打断
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交之前任何指令都不被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人头痛的问题
- 不保证原子性：redis同一个事务中，如果有一条命令执行失败，后面的命令仍然会被执行，没有回滚
小结
- 总结一下，redis对于事务的支持是部分支持
- watch指令，类似乐观锁，事务提交时，如果key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会执行；通过watch命令在事务执行之前监控了多个key，倘若在watch之后有任何key的值发生了变化，exec命令执行的事务都将被放弃，同时返回nullmutil-bulk应答以通知调用者事务执行失败
消息订阅发布简介
进程间的一种消息通信模式：发布者（pub）发送模式，订阅者（sub）接收消息 （实际上的开发并不会用redis做消息中间件）
命令：
- psubscribe pttern… 订阅一个或多个符合给定模式的频道
- pubsub subcommand 参数 … 查看订阅与发布系统状态
- publish channel message 将消息发送到指定的频道
- punsubscribe pattern… 退订所有给定模式的频道
- subscribe channel… 订阅一个或多个频道的信息
- unsubscribe channel… 指退定给定的频道
先订阅后发布才能接受到消息
订阅一个或多个频道的信息,subscribe c1 c2 c3 假设c1 c2 c3分别代表频道教育、财经、股票 ; 消息发布，publish c1 hello:
# 这是终端1
subscribe c1 c2 c3 #订阅三个频道频道
"message" #终端2向频道1发送消息，此处会接受到消息
"c1"
"hello"
# 这是终端2
publish c1 hello #向频道c1发布消息
publish c4 hello #此时，由于终端1并没有订阅终端4，所以不会接受到消息
psubscribe new1 hello #在终端3号订阅后2号终端向新闻1号频道发布消息
订阅多个，通配符 *，psubscribe new *（new和星号之间没有空格）;收取消息，publish new1 redis2015:
#终端3
含义讲解：new代表新闻，假设有新闻1-20这20个频道，通过通配符的形式可以匹配多个频道
psubscribe new* #订阅所有以"new"开头的频道
"message"
"new*"
"new1"
"redis2015"
视频中说：知道是这么回事就行了，实际工作中并不会用redis来做消息中间件
主从复制
主机数据更新后，根据配置和策略，自动的同步到备机的master/slaver机制，master以写为主，slaver以读为主
能做的功能有很多，主要有两个：读写分离、容灾恢复
如何操作
- 配从库，不配主库
- 从库配置：slaveof 主库ip 主库端口 info replication 指令用来查看当前分支信息 ;这里什么意思呢，就是说你在配置从库的时候，选择一台机器，这台机器就是从库，从库执行slaveof+主库ip+主库端口 后，就为该机器选定了主库， 但是需要注意的是，每次与slaver与master断开之后，slaver都需要重新连接主机，除非你配置进redis.conf文件
- 修改配置文件细节操作
- 拷贝多个redis.conf文件
- 开启daemonize yes
- pid文件名字
- 指定端口
- log问价名字
- dump.rdb名字
- 视频中以上操作是使用同一台电脑，使用不同端口来模拟多台机器
常用三招
一主二仆
下面情况是模拟的一主二仆，即一台主机，两台从机（主机，从机1号，从机2号）；主机上预先设定五个键，k1 k2 k3 k4 k5，分别对应五个值，v1 v2 v3 v4 v5,设定后，在指定从机
- 假设主机在存储了一定数据后，才指定从机，那么指定从机后，依然可以在从机上获取主机之前保存的数据
- 在从机和主机上分别设置值，比如主机：set k6 v6;从机：set k6 v6。那么执行结果怎样呢？ 答案是只有主机可以进行写入操作，从机是不可以进行写的操作，这样也就实现了读写分离
- 假设主机死了，从机会怎么样呢？输入info replication查看当前分支信息，发现当前分支还是slave；此时，依然可以获取已经死掉的主机的保存的值，但是连接信息是死掉的。 疑问：此时还存在读写分离吗？或者说从机能进行写入的操作吗？
- 假设主机死了，然后主机又活了，又是什么现象呢？主机活过来以后，主机：set k7 v7，从机依然能够备份到主机的数据（即主机死了，从机原地待命）
- 假设从机死了（假设从机1号死了，从机2号没死），主机：set k8 v8,然后从机又活过来，那么活过来的从机是什么身份呢？那么能不能续接上连接呢？从机1号： info replication ，查看当前身份信息，发现从机活过来以后，分支变成了主分支（master），并且没有续接上主机的操作，或者说v8的值是获取不到的，只要slaver与master断开了连接，那么slaver要进行重新连接（slaveof 主库ip 主库端口 ），除非你写进配置文件
总结一主二仆：只要有从机，从机会保存主机上的所有数据
薪火相传
即，一台主机，从机1号是主机的从机，从机2号是从机1号的从机（主–从爹–从儿子）
- 主机：set k9 v9,从爹和从儿子两台机器都能获取到k9的值
- 三台机器分别输入info replication，主机显示：master；从爹显示：slave，connected_slavers:1(然后是连接该机器的从机的信息)；从儿子显示：slave；
- 薪火相传的优点：减轻主机（master）的压力
- 如果中途变更转向，从机会清楚之前的数据，重新建立拷贝最新的
反客为主
恢复到一主二仆
-
假设主机1号挂了，现在从机1号输入指令：slaveof no one ,那么从机1号会变成主机，当真正的主机活过来以后，已经没他啥事了，原来的从机1号和从机2号变成了一套新的系统，活过来的主机自己是另一套系统
总结反客为主：slaveof no one指令—>使当前的数据库停止与其他数据库的同步，转变成主数据库
这三招都不怎么用了，真正企业中用的是哨兵模式
复制原理
slave启动成功连接到master后会发送一个sync命令，master连接到命令启动后台的存盘进程，同时收集所有接受到的用于用于修改数据集的命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步
全量复制：slave服务在接受到数据库文件数据后，将其存盘并加载到内存张中
增量复制：master继续将新的所有收集到的修改命令一次传给slave，完成同步
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行
哨兵模式（sentinel）
恢复到一主二仆
概念
自己的理解：什么叫哨兵模式呢？有一个哨兵，一直在巡逻，监控有没有主机挂了，如果主机挂了，会一句一定的规则，依据一定的规则从剩余的从机中选择选择一台主机出来
视频讲解：反客为主的自动版，能够后台监控主机是否故障，如果故障了根据票数自动将从库转换为主库
操做
配置哨兵，填写内容：
- 新建sentinel.conf文件，名字绝对不能错
- 指令：sentinel monitor 被监控数据库名字（自己起名字）ip 端口 1 ； #含义讲解：这是一条指令，用于配置哨兵，最后一个数字“1”，表示主机挂掉后slave投票看让谁接替主机，的票数多少后成为主机
- 启动哨兵：redis-sentinel /usr/common/sentinel.conf (上述目录依照各自的实际情况配置，可能木记录不同)
- 假设主机死了，哨兵模式会冲洗选一个主机，那么死掉的主机活过来了，什么结果呢？从新复活的数据库被哨兵监控到后会变成从机
- 假设主机死掉后，从剩余的两台从机的票数相同，没有选出来老大，会不会产生冲突？ 不会，重新选出新老大
一组sentinel能同时监控多个master
复制的缺点
由于所有的写操作都是先在master上操作然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重
Jedis
联通
//前提导入jedis的jar包
public class Test{
public static void main(String[] args){
Jedis jedis = new Jedis("127.0.0.1","6379");//参数指定ip和端口号
sout(jedis.ping());//jedis中封装了很多操作redis的方法
}
}
常用API
jedis.set("k1","v1");
sout(jedis.get("k1"));
Set set = jedis.keys("*");
还有很多命令，自己去学吧
事务
//事务的通用操作
public class TestTx{
public static void main(String[] args){
Jedis jedis = new Jedis("127.0.0.1","6379");//参数指定ip和端口号
Transaction transaction = jedis.mutil();//这里的Transaction是jedis包的引用
transaction.set("k1","v1");
transaction.set("k2","v2");
transaction.exec();
//transaction.discard();取消事务
}
}
//加锁
public class TestTx{
public boolean transMethod(){
Jedis jedis = new Jedis("127.0.0.1","6379");
int balance;//可用余额
int debt;//欠额
int amtToSubstract = 10;
jedis.watch("balance");
//jedis.set("balance","5");模拟其他程序已经修改了该条目
balance = Integer.parseInt(jedis.get("balance"));
if(balance<amtToSubstract){
jedis.unwatch();
sout("modify");
return false;
}else{
sout("事务开始");
Transaction tx = jedis.mutil();
tx.decrBy("balance",amtToSubstract);
tx.incryBy("debt",amtToSubstract);
tx.exec();
balance = Integer.parseInt(jedis.get("balance"));
debt = Integer.parseInt(jedis.get("debt"));
sout(balance);
sout(debt);
return true;
}
}
/*
*通俗点讲，watch命令就是标记一个键，如果标记了一个键，在提交事务前如果这个键被别人改过，那事务就会失败，这种情况通常可以在程序中重新在尝试一次。
*首先标记了键balance，然后检查余额是否足够，不足就取消标记，并且不做扣减；足够的话，就启动事务进行进行更新操作，
*如果在此期间balance被其他人修改过，那在提交事务（执行exec）的时候就会报错，程序中通常可以捕获这类错误再重新执行一次，直达成功
*/
public static void main(String[] args){
TestTX test = new TestTx();
boolean retValue = test.transMethod();
}
}
主从复制
模拟两台redis主机，各自独立，是写主写从读
public static void main(String[] args){
Jedis jedisFather = new Jedis("127.0.0.1","6379");
Jedis jedisSon = new Jedis("127.0.0.1","6380");
jedisSon.slaveof("127.0.0.1","6379");
}
JedisPool
连接池
使用单例模式双重校验锁
public class JedisPoolUtil(){
private static volatile JedisPool jedisPool = null;
private JedisPoolUtil(){
}
public static JedisPool getJedisPool(){
if(jedisPool == null){
synchronized(JedisPoolUtil.class){
if(jedisPool == null){
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxActive(1000);
poolConfig.setMaxTdle(32);
poolConfig.setMaxWait(10*1000);
poolConfig.setTestOnBorrow(true);
jedisPool = new JedisPool(poolConfig,"127.0.0.1","6379");
}
}
}
return jedisPool;
}
public static void close(JedisPool jedisPool,Jedis jedis){
if(jedis != null){
jedisPool.returnResourceObject(jedis);
}
}
}
JedisPool的配置参数大部分是由JedisPoolConfig的对应项来赋值的。
maxActive: 控制一个pool可以分配多少个jedis实例，通过pool.getResource()来获取，如果赋值未-1，则表示不限制；如果pool已经分配了maxActive个实例，则此时pool的状态为exhausted。
maxIdle: 控制一个pool最多有多少个状态为idle(空闲)的Jedi是实例。
whenExhaustedAction:表示当pool中的Jedis实例都被allocated完时，pool要采取的操作，默认有三种：
WHEN_EXHAUSTED_FAIL:表示无jeis实例时，直接抛出NoSuchElementException;
WHEN_EXHAUSTED_BLOCK:表示阻塞住，或者达到maxWait时抛出JedisConnectionException；
WHEN_EXHAUSTED_GROW：表示新建一个jedis实例，也就是说设置的maxActive无用。
maxWait: 表示当borrow一个jedis实例的时，最大的等待时间，如果超过等待时间，则直接抛出JedisConnectionException。
testOnBorrow: 获得一个jedis实例的时候，检查连接可用性(ping());如果为true，则得到的jedis实例均是可用的。
testOnReturn: return 一个jedis实例给pool时，是否检查连接可用性(ping())
自己编写测试类测试就够了