JAVA提高（三）--- Redis部分

1、Redis简介

注：熔断是指，存储层挂掉的时候，用户访问时缓存层不管有没有数据直接返回结果给客户端，能够止损。
Memcache：代码层次类似Hash
1、支持简单数据类型
2、不支持数据的持久化存储，一旦服务器宕机了，数据是不能保存的
3、不支持主从同步和分片。
Redis:
1、支持数据类型丰富
2、支持数数据磁盘持久化存储
3、支持主从同步
4、3.0后支持分片。
Redis为什么查询那么快：
1、完全基于内存，绝大部分请求是纯粹的内存操作。
2、数据结构简单，对数据操作简单。不使用表，不用关联。
3、主线程是单线程的，主线程串行处理IO事件，避免了频繁的上下文切换和锁竞争。想多核也可以启动。
4、使用多了I/O复用模型，非阻塞IO
（注：使用多了I/O复用模型——[epoll、kqueue、evport、select]，根据不同系统选择不同的模型。他们是对文件进行监控，让线程可以去做其他事情）

2、Redis常用数据类型

（1）String：最基本的数据类型，二进制安全的（可以包含jpg图片等文件）——插入：set 属性名 值；获取：get 属性名
（2）Hash：String元素组成，适合存储对象。——插入：hmset 表名 属性名 值；获取：hget 表名 属性名
（3）List：列表，按照String元素插入排序，后进先出。——插入：lpush 表名 值；获取：lrange 表名 开始位置 长度
（4）Set：String元素无需集合，通过哈希表实现的，不允许重复。——插入：sadd 表名 值；获取：smembers 表名
（5）Sorted Set：每个元素都有个double分数，通过分数从小到大排序。——插入：zadd 表名 分数 值；获取：zrangebyscore 表名 开始位置 长度
用于技术的HyperLogLog，用于支持存储地理位置信息的Geo

3、从海量KEY中查询固定前缀的key

（1）KEYS pattern：查询所有符合给定模式pattern的key（缺点：一次性返回所有匹配的key，键数量过大就会卡顿）
（2）SCAN 游标 [MATCH pattern]：基于游标的迭代器，游标为0时服务器开始新的迭代。返回给用户0时表示迭代结束。
Java需要安装Jedis客户端，引入jar包，最后才能调用指令。

4、分布式锁

分布式锁解决的问题：
互斥性：任意时刻只能有一个客户端获取锁；
安全性：锁只能由持有该锁的客户端删除；
死锁：获取锁的客户端宕机未释放锁，其他客户端获取不到锁，就会死锁；
容错：部分节点宕机时，保证客户端任然能够获利到锁

实现分布式锁一：（缺点：原子性不够，可能设置完key之后就宕机了，没有设置生存时间，就会死锁）
SETNX key value：如果key不存在就创建赋值。时间复杂度O（1）。成功返回1，失败返回0。创建后key会被一直占用，不能改变。
EXPIRE key seconds：设置key的生存时间，当key过期就会被删除。
实现分布式锁二：

大量的key同时过期删除很耗时。需要在设置过期时间的时候给每个key加上随机值。

5、异步队列

方式一：（缺点：LPOP不会等待队列里面的值，直接去消费。解决：可以在应用层引入Sleep去调用LPOP）
使用List作为队列，rpush 表名 值——来生产信息，lpop 表名——消费信息（一次一条，先进先出）
方式二：（缺点：只能供一个消费者消费）
BLPOP key timeout：阻塞直到队列有消息或者超时。
方式三：（缺点：消息的发布是无状态的，无法保证可达。要用专业的消息队列来解决）
pub/sub：主题订阅者模式。发送者（pub）发送消息，订阅者（sub）接收消息。订阅者可以订阅任意数量的频道。
订阅：subscribe 频道名。发送：publish 频道名 消息。

6、持久化方式之RDB（快照方式持久化）

RDB：保存某个时间点的全量数据快照。
配置：sava 秒数 number——在秒数内有number个数据数量写入则备份一次（sava “”，这个操作能禁用rdb配置）
stop-writes-on-bgsave-error——当为yes时，备份时出错了，主进程就停止操作。保护数据持久化。
rdbcompression——当为yes时，表示在备份时将rdb文件压缩后在进行保存。（一般设置为NO，减少CPU消耗）

RDB的生成：
SAVA：会阻塞Redis的服务器进程，知道RDB文件创建完成。
BGSAVA：派生（Fork）出一个子线程来创建RDB文件，不阻塞服务器线程。
实现原理：在Fork时创建子进程，将内存内容写入到临时文件中，由于OS的Copy-on-Write，父子进程会共享相同的物理页面，父进程处理写请求是，OS会为父进程要修改的页面创建一个副本。所以子进程地址空间内的数据是Fork时候的整个数据库的快照，当写入操作进行完之后，在替换掉快照，从而完成了一次备份。（缺点：每次都是完整写入，而不是增量写入）
lastsava：查看上次sava的时间

7、持久化方式之AOF（保存写状态）

RDB持久化相当于备份数据库状态。AOF持久化备份数据库接收到的所有变更数据库的指令，命令会以append的形式追加保存到AOF中（增量），将appendonly值设为yes开启。
redis只支持不中断服务的情况下，后台重建aof文件：
1、调用fork，创建子进程
2、子进程将新的aof文件写到一个临时文件里面，不依赖原来的aof
3、主进程持续将新的变动同时写到内存和原来的aof
4、子进程重新完成时，主进程获取到完成信号，把内存里的buffer新增到新的aof
5、用新的aof替换掉原来的aof

RDB和AOF的优缺点。
RDB
优点：全量数据快照，文件小，速度快
缺点：无法保存最近一次快照之后的数据
AOF
优点：可读性高，适合增量数据，不易丢失
缺点：文件体积大，恢复时间长
Redis4.0之后默认使用RDB-AOF混合持久化方式。用RDB获取全量持久化，AOF增量持久化。

8、Pipeline及主从关系

使用Pipeline批量执行指令，节省多次IO往返的时间。如指令有顺序依赖建议分批发送。
主从同步原理：（缺点：Master宕机的话，Redis就不能提供写入操作）
全量同步：
Slave发送sync命令给Master
Master启动一个后台进程，将Redis的数据快照保存到文件中（BGSava）
Master会将保存数据快照期间接受到的写命令缓存起来
Master完成写文件操作后，将该文件发给Slave
Slave将新的替换旧的RDB
当Slave完成数据快照的恢复后，Master将收集到的增量写命令送给Slave
增量同步：
Master接收到用户的操作指令，判断是否需要扩散到Slave
将操作记录存储到AOF文件中
将操作传播到其他Slave：1、对齐主从库；2、将命令和参数按照Redis的协议格式写入到响应的Slave中
将缓存中的数据发送给Slave
Redis Sentinel（Redis哨兵）：
解决主从同步Master宕机后的主从切换问题：
监控：检查主从服务器是否运行正常
提醒：通过API向管理员或者其他应用程序发送故障通知
自动故障迁移：主从切换

9、Redis集群

分片：按照某种规则去划分数据，分散存储在多个节点上。
Redis集群原理：

将服务器使用哈希进行哈希变换（可以选择服务器的ip或者主机名作为关键字进行哈希），找到在哈希环上的位置。然后将数据的key进行相同的哈希算法算出哈希值，并确定数据在环上的位置并顺时针行走，遇到的第一个服务器就是存储的目标服务器了。
可能会出现数据倾斜问题：

解决办法：一致性哈希算法引入了虚拟节点的机制，可以在服务器的ip或者主机名后面增加编号，对每一个服务器节点计算多个哈希。