redis分布式缓存
一、概述
为了解决单台redis服务性能不足的问题，所以让redis读写分离
二、redis性能测试
工具：
redis—benchmark
官方自带的redis性能测试工具看，可以观看redis的实际性能。服务器的硬件配置、网络状态、测试环境都会对redis性能有所影响
使用语法：redis-benchmark
三TPS、QPS、RT
在描述系统的高并发能力时，吞吐量（TPS）、QPS、响应时间（RT）经常提到。
响应时间RT
吞吐量TPS
每秒查询率QPS
响应时间（RT）
响应时间是指系统对请求作出响应的时间，在讨论系统的响应时间时，通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。
吞吐量TPS
吞吐量是指系统在单位时间内处理请求的数量
资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加
吞吐量是一个比较用用的标准，最大吞吐量基本一致，可以判断两个系统处理能力基本一致
每秒查询率（QPS）
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，也就是最大吞吐能力
可以测算Redis性能，通过benchmark来测试QPS是多少，来估算redis性能。
四、读写能力分离
如果一台服务器的QPS不能满足要求，我们还可以对读写能力扩展，解决性能瓶颈。运行新的服务器简称从服务器，让从服务器与主服务器进行连接，然后主服务器发送数据副本，从服务器通过网络根据主武器的数据副本进行准实时更新，具体的更新速度取决于网络带宽。
这样我们就有额外的从服务器处理读请求，通过将读请求分散到不同的服务器上面进行处理，用户可以从新添加的从服务器上获得额外的读查询处理能力。
redis本身是支持读写分离的。在配置文件修改
具体位修改redis.conf文件，添加添加 slaveof 192.168.200.128 6379
五、redis同步原理
redis的主从复制，就是主服务器执行写操作命令，从服务器通过主服务器的数据的变化，同步数据到从服务器。但是如果主服务器下线，从服务器无法连接到主服务器，那么数据同步该如何拿到不能连接主服务器这段时间的命令呢？
主从复制中的主从服务器双方的数据库将保存x相同的数据，概念上将这种现象乘坐数据库状态一致。
redis有两种持久化方式：RDB全量持久化和AOF增量持久化
2主要有完成重同步和部分重同步两种模式
功能主要有以下三个部分构成：
主服务的复制偏移量和从服务器的复制偏移量
主服务器的复制积压缓冲区，默认大小为1M
服务器的运行ID，用于存储服务器表示
如果从服务器断线重写连接，获取主服务器的运行ID与重接后的主服务器运行ID进行对比，判断是不是原来的主服务器，从而决定是执行部分重同步，还是执行完整重同步。
六、Sentinel实现高可用（哨兵）
Sentinel介绍
不用哨兵，主节点挂掉，将从节点晋升到主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点
这个工程费时费力，所以有了哨兵机制
Sentinel的使用
主要是先修改sentinel.conf的配置。
原理
Sentinel主要是监控服务器的状态，并决定是否进行故障转移，Sentinel判断服务是否下线，分为主观下线和客观下线
主观下线：
主观下线指的是单个Sentinel实例对服务器做出的下线判断
特点：
如果一个服务器没有在指定的时间内，对向它发送PING命令的Sentinel返回一个有效回复，那么Sentinel就会将这个服务器标记为主观下线。
客观下线：
多个Sentinel实例在对同一个服务器做出SDOWN判断，并且通过命令互相交流之后，得出服务器下线判断。（一个Sentinel和另一个Sentinel可以互相交流，询问对方是否认为给定的服务器已下线）
特点：
从主观下线状态切换到客观下线状态并没有严格规定的法定人数顺发，而是使用了流言传播：如果Sentinel在给定的时间范围内，从其他Sentinel哪里接收到了足够数量的主服务器下线报告，那么Sentinel就会将主服务器的状态从主观下线改变为客观下线。
注意点：
客观下线只适用于主服务器，对于其他类型的redis实例，Sentinel在将他们判断为下线前不需要进行协商，所以从服务器或者其他Sentinel不会达到客观下线条件。只要一个Sentinel发现某个主服务器进入客观下线状态，这个Sentinel就可能被其他Sentinel推选出，并对失效的主服务器执行自动故障迁移操作。
七、Sentinel三大工作任务
监控：Sentinel会不断地检查你的主服务器和从服务器是否运作正常。
提醒：当被监控的某个redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移：当一个主服务器不能正常工作时，Sentinel会开始一次自动故障转移操作，他会将失效主服务器的一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器。
当客户单试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，是的集群可以使用新主服务器代替失效服务器。
八、互联网冷备和热备
冷备：
概念：
冷备发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完整的数据库
优点：
非常快速的备份方法
低度维护，高度安全
缺点：
单独使用时，只能提供某一时间点上的恢复
在实施备份的全过程中，数据库必须要作备份而不能作其他工作。也就是说，在冷备份过程中，数据库必须是关闭状态。
热备：
概念：
热备份是在数据库运行的情况下，采用归档模式方式备份数据库的方法
优点：
备份的时间短
备份时数据库扔可使用
可达到秒级恢复
缺点：
若热备份不成功，所得结果不可用于时间点的恢复
对于维护，要仔细小心
九、Sentinel整合SpringBoot
设置redis密码，在所有的redis配置文件redis.conf中，添加配置
集群中主机和备机的redis.conf配置文件都需要添加
# 设置密码
requirepass 123456
# 设置访问主服务器密码
masterauth 123456
在Sentinel哨兵的配置文件sentinel01.conf中添加以下设置：
sentinel auth-pass mymaster 123456
整合SpringBoot
首先导入依赖，在yml文件中配置密码，地址。
十、Redis内置集群
为了保证可以进行投票，需要至少三个主节点
每个主节点都需要至少一个从节点，所以需要至少三个从节点。
所以需要六个redis服务器。
集群环境redis节点的配置# 不能设置密码，否则集群启动时会连接不上
第一个redis节点node1准备好之后，再复制5份，修改六个节点的端口号为7001~7006，修改redis.conf配置文件即可也就是一共六个node，每个node都有redis.conf文件，端口不同就行
redis集群的管理工具使用的是ruby脚本语言，安装集群需要ruby环境，先安装ruby环境：
# 使用集群管理脚本启动集群
./redis-trib.rb create --replicas 1 192.168.200.128:7001 192.168.200.128:7002 192.168.200.128:7003 192.168.200.128:7004 192.168.200.128:7005 192.168.200.128:7006
ip地址都一样
十一、集群原理
集群框架图
架构特点：
1、所有redis节点彼此互联
缓存雪崩：使用锁或队列、设置过期标志更新缓存、为key设置不同的缓存失效时间
缓存穿透：
最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴！
三、缓存预热
缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决思路：
1、直接写个缓存刷新页面，上线时手工操作下；
2、数据量不大，可以在项目启动的时候自动进行加载；
3、定时刷新缓存；
四、缓存更新
除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：
（1）定时去清理过期的缓存；
（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。
五、缓存降级
当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：
（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。