微服务架构中各层的高可用设计

典型的微服务架构

接入层&反向代理层

网关层

负责流控和熔断降级

https://blog.csdn.net/qq798280904/article/details/130026867

RPC

Zookeeper

Leader:
主要承担了以下的功能

事务请求的唯一调度和处理者，保证集群事务处理的顺序性，所有 Follower 的写请求都会转给 Leader 执行，用来保证事务的一致性

集群内部各服务器的调度者：处理好事务请求后，会将数据广播同步到各个 Follower，统计 Follower 写入成功的数量，超过半数 Follower 写入成功，Leader 就会认为写请求提交成功，通知所有的 Follower commit 这个写操作，保证事后哪怕是集群崩溃恢复或者重启，这个写操作也不会丢失。

Follower:
处理客户端非事务请求、转发事务请求给 leader 服务器

参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）

参与 Leader 选举的投票

可以看到由于只有一个 Leader，很显然，此 Leader 存在单点隐患，那么 ZK 是怎么解决此问题的呢，首先 Follower 与 Leader 会用心跳机制保持连接，如果 Leader 出现问题了（宕机或者因为 FullGC 等原因无法响应），Follower 就无法感知到 Leader 的心跳，就会认为 Leader 出问题了，于是它们就会发起投票选举，最终在多个 Follower 中选出一个 Leader 来（这里主要用到了 Zookeeper Atomic Broadcast，即 ZAB 协议，它是为 ZK 专门设计的一种支持崩溃恢复的一致性协议）
详见
https://blog.csdn.net/qq798280904/article/details/129965877

Redis

分片集群，所谓分片集群即将数据分片，每一个分片数据由相应的主节点负责读写，这样的话就有多个主节点来分担写的压力，并且每个节点只存储部分数据，也就解决了单机存储瓶颈的问题，但需要注意的是每个主节点都存在单点问题，所以需要针对每个主节点做高可用，整体架构如下

原理也很简单，在 Proxy 收到 client 执行的 redis 的读写命令后，首先会对 key 进行计算得出一个值，如果这个值落在相应 master 负责的数值范围（一般将每个数字称为槽，Redis 一共有 16384 个槽）之内，那就把这条 redis 命令发给对应的 master 去执行，可以看到每个 master 节点只负责处理一部分的 redis 数据，同时为了避免每个 master 的单点问题，也为其配备了多个从节点以组成集群，当主节点宕机时，集群会通过 Raft 算法来从从节点中选举出一个主节点。

ES

创建了多个节点，分片（图中 P 为主分片，R 为副本分片）的优势就体现出来了，可以将分片数据分布式存储到其它节点上，极大提升了数据的水平扩展能力，同时每个节点都能承担读写请求，采用负载均衡的形式避免了单点的读写压力

ES 的写机制与 Redis 和 MySQL 的主从架构有些差别（后两者的写都是直接向 master 节点发起写请求，而 ES 则不是），所以这里稍微解释一下 ES 的工作原理

首先说下节点的工作机制，节点（Node）分为主节点（Master Node）和从结点（Slave Node），主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是集群的一部分，并决定哪些分片分配给相关的节点，主节点也只有一个，一般通过类 Bully 算法来选举出来，如果主节点不可用了，则其他从节点也可以通过此算法来选举以实现集群的高可用，任何节点都可以接收读写请求以达到负载均衡的目的

再说一下分片的工作原理，分片分为主分片（Primary Shard，即图中 P0，P1，P2）和副本分片（Replica Shard，即图中 R0，R1，R2），主分片负责数据的写操作，所以虽然任何节点可以接收读写请求，但如果此节点接收的是写请求并且没有写数据所在的主分片话，此节点会将写请求调度到主分片所在的节点上，写入主分片后，主分片再把数据复制到其他节点的副本分片上，以有两个副本的集群为例，写操作如下

kafka

mysql

数据量大了之后就要分库分表了，于是就有了多主，就像 Redis 的分片集群一样，需要针对每个主配备多个从