Redis主从复制
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower);数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave 以读为主。
默认情况下，每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点主从复制的作用主要包括:
1、数据冗余:主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复:当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复;实际上是一种服务的冗余,
3、负载均衡:在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务(即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点)，分担服务器负载;尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4、高可用基石:除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大;
2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G,也不能将所有内存用作Redis存储内存一般来说，单台Redis最大使用内存不应该超过20G。
电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是”多读少写”。
主从复制，读写分离! 80%的情况下都是在进行读操作!减缓服务器的压力!架构中经常使用!一主二从!只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis!
将配置文件复制三份，模拟三机，79端口主机，80端口和81端口是两个从机
复制3个配置文件，然后修改对应的信息
1、端口
2、pid 名字
3、log文件名字
4、dump.rdb 名字
修改完毕之后，启动我们的3个redis服务器，可以通过进程信息查看!
先打开79配置文件
生成的日志文件改名为6379.log
生成的rdb文件改名为dump6379.rdb，然后：wq保存退出
进入80端口的配置文件
首先端口修改为6380
pidfile的pid文件修改成自己的名字
logfile的名字也改成6380.log
rdb文件也改名为dump6380.rdb，然后：wq保存退出
紧接着编辑81端口的配置文件
端口改为6381
更改pid文件名
更改日志文件名
更改rdb文件名，然后：wq保存退出
启动79端口
启动80端口
启动81端口
查看进程
打开6379端口的客户端
查看当前库信息，为主机，从机有0个
打开6380端口的客户端
查看当前库信息，为主机，从机有0个
打开6381端口的客户端
查看当前库信息，为主机，从机有0个
一主二从
默认情况下，每台Redis服务器都是主节点;我们一般情况下只用配置从机就好了!认老大!一主(79)二从(80，81) SLAVEOF host 6379 找谁当自己的老大!
在6380客户端通过命令slaveof ip地址 端口号 来使得该redis服务器跟随6379的主机，查询库信息，发现本机变为slave从机，并且显示主机的ip地址和相应端口
在6379主机客户端查看库信息，发现此时有一个从机，并且显示从机的ip和端口
将6381端口的服务器也跟随6379的主机，并查看库信息，也一样变为从机
此时在6379主机的客户端查看库信息，发现其下有两个从机，分别为80和81端口
真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的!
conf文件中有相应的主从配置
REPLICATION 复制
配置文件中可通过下面两个东西，配置从机的主机ip与端口，如果主机有密码的话，需要配置主机密码
主机可以写，从机不能写只能读!主机中的所有信息和数据，都会自动被从机保存!
主机中新增一个数据
在两个从机中都可以查看到这个在主机中新增的数据，不过，在从机中新增数据的话会直接报如下错误，从机只能读不能写
如果主机此时掉线了，再连接上，再次新增数据，两个从节点依然可以更新出新增的数据，主从关系依然存在，但是如果其中一个从节点掉线了，掉线期间新增的数据，包括连接回来后，又新增的数据，这个从节点都不会更新了，之间的主从关系断了，新连上的这个从节点又默认变回了自己的主节点
如果是使用命令行，来配置的主从，这个时候如果重启了，就会变回主机!只要再次敲命令变为从机，立马就会从主机中获取值!
复制原理
Slave 启动成功连接到 master 后会发送一个sync命令
Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制:而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
增量复制:Master 继续将新的所有收集到的修改命令依次传给slave，完成同步
但是只要是重新连接master，一次完全同步(全量复制)将被自动执行
除了上述的一主二从模式，还有下述的另一种主从模式，80端口既是79的从机，又是81的主机，这时候也可以完成我们的主从复制!
如果没有老大了，这个时候能不能选择一个老大出来呢?手动!
谋朝篡位
如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机!其他的节点就可以手动连接到最新的这个主节点(手动)
哨兵模式
(自动选举老大的模式)
主从切换技术的方法是:当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel(哨兵 )架构来解决这个问题。
谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里的哨兵有两个作用
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。。当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行--次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
我们目前的状态是 一主二从!
1、配置哨兵配置文件 sentinel.conf
在redis目录的sentinel.conf配置文件中配置哨兵相关配置
监控主节点，配置主节点的ip以及端口
后面的这个数字1，代表主机挂了，slave投票看让谁接替成为主机，票数最多的，就会成为主机!
2、启动哨兵!
敲入如下命令启动哨兵
可以在下方日志中看到监控的主机信息以及两个从机信息
此时模拟主机故障，让主机下线
可以看到哨兵的日志中有一些新的日志产生，包括主节点下线之类的
过一会，可以看到从机81端口，变为了主机，并且，80端口从机跟随了它
如果Master 节点断开了，这个时候就会从从机中随机选择一个服务器!(这里面有一个投票算法!)
此时，我们再将刚才的主机6379端口再次打开
稍微过一会就可以看到，该6379的服务器自动变为了81端口的从机，恢复后不再是主机。
如果主机此时回来了，只能归并到新的主机下，当做从机，这就是哨兵模式的规则!
优点:
1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有
2、主从可以切换，故障可以转移，系统的可用性就会更好
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮!
缺点:
1、Redis 不好啊在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦!
2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择!
Redis缓存穿透和雪崩
在这里我们不会详细的区分析解决方案的底层!
Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。
缓存穿透（查不到）
缓存穿透的概念很简单，用户想要査询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。
解决方案
布隆过滤器
布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力;
缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源;
但是这种方法会存在两个问题
1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键;2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。
缓存击穿（量太大，缓存过期!）
这里需要注意和缓存穿透的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。
解决方案
设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点 key过期后产生的问题。
加互斥锁
使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。
缓存雪崩
缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis宕机!
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点,很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
解决方案
redis高可用
这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。
限流降级
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
