Por que o Redis deve estar altamente disponível?
Pontos de dor:
- Se houver apenas um nó mestre para redis de um serviço, um dia a máquina de interface não se comunicará com a máquina redis ou, se a máquina redis falhar, você não poderá acessar o Redis. Se o serviço depende muito de redis , ele entrará em colapso.
- Alta disponibilidade no nível de vários nós principais: se o redis tiver um nó mestre e um nó escravo, se a rede falhar ou a máquina redis falhar, mesmo que a falha dure 1 hora, todo o serviço redis será afetado. Se redis tem vários nós mestres (4), os dados são fragmentados nesses mestres e, se a máquina redis estiver conectada apenas a uma máquina, 1/4 dos dados serão afetados. Perda reduzida em 3/4
- Alta disponibilidade de redis no nível regional: se o serviço for implantado no norte e no sul, Guangzhou acessará redis em Guangzhou e Pequim acessará redis em Pequim. Se o redis na área de Pequim estiver inativo, você pode se conectar ao redis de Guangzhou na área de Pequim ou encaminhar diretamente a solicitação de Pequim para Guangzhou; ou depois que o cliente receber uma solicitação com falha de Pequim, tente novamente em Guangzhou
meios altamente disponíveis
A essência da alta disponibilidade é ter um backup.Quando ocorre uma falha, um backup pode fornecer serviços. Portanto, o núcleo do problema é o backup, então como fazer backup?
Vamos dividi-lo em alguns níveis:
Persistência:
Ponto problemático a ser resolvido : os dados são descartados no disco e os dados da memória não serão perdidos devido à interrupção do redis
Os dados do redis existem na memória. Se o redis travar, os dados da memória serão perdidos após a reinicialização e não haverá backup. Neste ponto, a persistência é necessária, ou seja, os dados armazenados no redis também são gravados no disco.Quando o redis trava e reinicia, os dados do disco podem ser reimportados para atingir o objetivo da recuperação.
beneficiar:
- Com o backup em disco, quando ocorre uma falha, os dados do disco podem ser restaurados
ferir:
- Ainda é um serviço de ponto único. Leva tempo para restaurar os dados. A duração desse tempo depende do tamanho dos dados. Durante o processo de restauração, o serviço ainda está indisponível
- Não automatizado, a ser restaurado manualmente
sincronização mestre-escravo
Ponto problemático resolvido : dados de backup de vários nós
上面说的持久化，痛点是在故障的时候，还得手动通过磁盘文件恢复。 那么主从同步可以解决这个痛点 具体是这么做的：redis主节点，挂N个从节点，slave节点实时同步master节点的数据，在master挂了的时候，可以立刻把slave提升成为master节点。 因为slave有了master的所有数据，因此可以直接切换，不用从磁盘恢复数据，大大缩短这个恢复时间。
好处：
- 故障时候，不用从磁盘恢复数据，减短故障时间
- slave节点一直保持同步，所以数据是最新的，可以直接提升为master
- 读写分离，master接收写请求，slave接收读请求。
坏处：
- 如果代码写死了链接master节点，此时切换了slave节点，代码就要更改redis连接配置。解决方案：因此需要设置一个VIP，中间件IP，客户端连接这个VIP即可，VIP后面怎么转发，对代码透明。
- 非自动切换，需要手动切换，深夜时间无人值班，没发现即时会让故障时间延长。
哨兵模式（Sentinel）
解决的痛点：自动故障转移
出故障的时候可能夜晚，又必须要精通的运维才能快速搞定，否则一定崩了，影响服务和用户。 有了主从同步，数据得以备份，以备故障的时候可以容器。但是这个故障切换要手动操作，哨兵模式就是解决这个痛点：自动转移故障
工作原理： sentinel哨兵也是一个集群，而且是独立于redis集群的一个服务。 因此哨兵是多个节点的，他的本质原理就是，每个哨兵每秒定时发送ping给master，等master回应 如果回应正常，那没问题 如果回应超时，那就需要关注。但是超时也有可能很多原因，比如网络不通畅、偶发的丢包等等。 假设有3个哨兵： 如果只有一个哨兵得不到回应，他会标识master 主观下线，即只是他自己认为master下线了 但另外两个哨兵是正常的，那就说明master没有真的下线，可能只是哨兵1网络问题
这样就有个好处，必须要多数哨兵认为master下线了，才会切换主从。 哨兵自己认为master挂了，这种叫主观下线 半数以上哨兵认为master挂了，他们通过互相信息同步，就认为master是客观下线 这个时候，就需要走主从切换流程了
主从切换原理： 正常情况下，多个slave配置，都配置了slaveof master 如果master被哨兵认为客观下线了，此时就要进行一次“投票”，从slave里面选出新的master。 具体就是修改配置文件、重启服务，这几个操作的自动化
简化理解 其实就好比平常工作中，写了个脚本，定时扫描漏单之类的，这个定时脚本也要高可用，所以就部署在多个接口机上。 然后脚本定时探测一下master是否正常，多数发现不正常了，就触发自动更换配置文件，reload服务。 就是这么个道理
标识下线机制，这个类似rpc重试机制，一个机器返回5xx，得重试到另外一个机器，都失败了，才返回5xx给客户端。
问题： 问题1. 如果代码写死链接的masterip， 这样切换了，代码还得发版上线才能生效，所以代码不能这么说傻叉写死一个IP。
解决方案：需要有一个类似中间件的组件，来做这个事。比如mysql就有个中间件，端口就是127.0.0.1:9981服务，后面转发到redis真实IP 。当然故障切换后，这个中间件得知道master是谁了。这个也是可以通过下发配置通知的？
问题：还是客户端直接访问的sentinel ? sentinel担任起中间件的角色？因为它知道master和slave具体信息
实际解决方案：就是客户端连接3个哨兵的ip:端口，让哨兵来返回redis的主从节点，他也帮你连接好了，返回一个redis实例给你，所以相当于是哨兵是中间件，客户端（代码）先连接到哨兵，哨兵返回master，再帮你哦链接后redis，返回给你。 这样就不用怕主从切换后的IP变更了
结构图：
Redis Cluster 集群方案
哨兵机制解决的是主从自动切换的痛点。 另外一个痛点是：redis单机存储有限；数据单点 场景，比如专辑业务的痛点：
- redis数据都是几十G的，如果只有一个master节点，那么这个redis机器要很大内存，这样的配置很贵
- 同时，如果真有这么大内存的redis机器，那么全部数据都单点存储，一旦这个机器挂了，就影响全部用户
Redis Cluster就是解决以上两个痛点的解决方案：
- 数据分片，key按规则hash到不同的节点，就算某些节点挂了，之影响那个节点的数据，提高高可用性
- 每个机器的内存都不用太大，甚至集齐N个4G内存的机器，都能组成一个大容量集群
问题： Redis Cluster如何解决故障自动转移？ 如何分片，分片规则是怎样的？ 用了Redis Cluster集群，还需要哨兵做主从切换吗？ 你的业务redis集群的架构是怎样的？（字节面试题）