默认的持久化方式RDB
在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。 你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次 数据集。 比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 数据集： # save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可 还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件， 每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。
COW(Copy on Write)写时复制机制，在生成快照的同时依然可以处理写命令
graph TD
主线程--> bgsave子进程,共享主线程的所有数据,由它将数据写进RDB文件中--> 包括主线程新增的修改的数据 -->主线程仍然可以修改原来的阿数据
AOF(以指令追加的方式进行)
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失 最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方 式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间 fsync到磁盘)
混合持久化（基于AOF，必须先开启AOF）
Redis4.0之后开始可以使用混合持久化
aof-use-rdb-preamble yes
Redis主从架构
Redis的从节点配置成只读，从节点执行下面的命令，表示从哪个主节点复制数据。
replicaof 192.168.74.186 6379
//表示从端口号为6379这台机器上面复制数据
Redis主从流程：
- 从节点向主节点发送一个psync命令同步数据，发送命令之前会跟master建立socket长连接
- 主节点生成rdb数据，生成rdb数据的过程中间会有短暂的几秒的时间，这个时候有其他的命令过来，就会加入到一个数据缓存中（只能保存最近的几分钟的数据，如果从节点挂了）
全量复制和部分复制(断点续传备份新增的数据) 会记录数据偏移量
Redsi的主从风暴 有很多个从节点需要从主节点复制数据，导致主节点压力过大，为了缓解这个压力，可以采用让部分从节点与从节点同步数据的方式。
jedis代码连接示例
- 引入相关的依赖
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
访问redis:
public class JedisSingleTest {
public static void main(String[] args) throws IOException
{
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig(); jedisPoolConfig.setMaxTotal(20);
jedisPoolConfig.setMaxIdle(10);
jedisPoolConfig.setMinIdle(5); // timeout，这里既是连接超时又是读写超时，从Jedis 2.8开始有区分connectionTimeout和soTimeout的构造函数
JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.0.60", 6379, 3000, null);
Jedis jedis = null;
try { //从redis连接池里拿出一个连接执行命令
jedis = jedisPool.getResource();
System.out.println(jedis.set("single", "zhuge")); System.out.println(jedis.get("single")); //管道示例 //管道的命令执行方式：cat redis.txt | redis-cli -h 127.0.0.1 -a password - p 6379 --pipe /*Pipeline pl = jedis.pipelined(); for (int i = 0; i < 10; i++) { pl.incr("pipelineKey"); pl.set("zhuge" + i, "zhuge"); }
List<Object> results = pl.syncAndReturnAll();
System.out.println(results);*/ //lua脚本模拟一个商品减库存的原子操作 //lua脚本命令执行方式：redis-cli --eval /tmp/test.lua , 10 /*jedis.set("product_count_10016", "15"); //初始化商品10016的库存 String script = " local count = redis.call('get', KEYS[1]) " + " local a = tonumber(count) " + " local b = tonumber(ARGV[1]) " + " if a >= b then " + " redis.call('set', KEYS[1], a-b) " + " return 1 " + " end " + " return 0 "; Object obj = jedis.eval(script, Arrays.asList("product_count_10016"), Arrays.asList("10")); System.out.println(obj);*/ } catch (Exception e) { e.printStackTrace(); } finally { //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。 if (jedis != null) jedis.close(); } } }
jedis eval执行客户端命令，传进来script脚本，然后再传进来Arrays.asList数组。lua脚本支持事务回滚操作，具有原子性。可以通过lua脚本来实现分布式锁。
Redis哨兵高可用架构
Redis哨兵也是Redis的节点，让哨兵动态的去监听Redis节点，当住系欸但挂了之后，哨兵会重新选取新的主节点，哨兵是直到Redsi的所有的节点信息的，哨兵会把主节点的阿信息返回给客户端。客户端client是连接哨兵的，通过哨兵来获取Redis中的主从节点的信息。
主节点的重新选举：
当哨兵里面半数以上的的哨兵认为从主节点挂了才会重新选举。这样能让整个的选举更加精准点。
当然也有可能出现问题，半数以上的哨兵认为Redis集群中的主节点挂了，但是其实主节点没有挂，也就是判断失误，而发起的新的节点的选举-----脑裂问题。
