高并发高可用知识点汇总

高并发读的解决方案：
1、并发读（异步RPC，google冗余请求）
2、缓存（本地缓存、redis、memcache，mysql的master/slave，CDN（Content Delivery Network）静态文件（如html、js等）加速）
3、重写轻读（微博的feeds流，宽表、搜索引擎）

高并发写的解决方案：
异步
批量
数据分区（数据分为多块，如MySQL分库分表（可以使用MyCAT）、kafka的partition）
任务分区（任务分发到多台机器执行）

高可用的解决方案：
本地/异地多副本：MySQL半异步复制+异步复制
隔离（业务上、机器隔离、线程隔离）、限流（一般指并发数，有时候还有速率、业务上，漏桶算法、令牌桶算法）、
、熔断（失败请求率、响应时长）、降级（从业务上来说）
监控

限流算法
不同的算法，主要从不同的粗细时间粒度上考虑，所带来的效果。
1、计数：请求进来+1，请求结束-1，超过阈值不放进来。时间粒度太粗，如果1秒钟的请求都集中在某一个毫秒内，仍然可能会导致服务崩溃。
2、滑窗：虽然实现不同，但是仍然有突发超高流量的问题。
3、漏桶：一般使用消息队列实现，定时消费，保证流出速率固定，平滑输出。会引入阻塞问题，响应不及时，适合任务类的限流，比如线程池。
4、令牌桶：定时放令牌进入令牌桶，有令牌就处理，无令牌不处理。在平滑输出的同时，允许一定的突发流量，但是又不像计数和滑窗那样剧烈。另外，令牌桶需要预热。第一个10ms来了2个请求，第二个10ms没有请求，如果是每10ms放入1个令牌的情况下，会导致过于保守。
参考：https://www.jianshu.com/p/40d3f44122b2
超详细的Guava RateLimiter限流原理解析 - 知乎

高可用开源软件
keepalived：基于VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）做的，热备、负载均衡。虚拟IP方案只能在同网段或者说同个二层交换机下进行，无法做到跨网段或者跨机房的高可用。
HAProxy：负载均衡
Heartbeat：集群基于UDP协议，提供服务的启停功能。
DNS：
doozerd：
Consul：
gossip：每个节点往M个节点同时同步数据，传播较慢，并且会有很多冗余的数据传输。
zookeeper：
etcd：

	zookeeper	etcd
语言	java	go
存储格式	树形结构存储在内存中，最大1M	key-value存储在内存中，无限制
一致性算法	zab（ZooKeeper Atomic Broadcast，原子广播）	raft
节点要求	选举要求半数以上，至少3个节点。n/2+1过半写入一致性。
快照	全局快照	支持增量快照
应用	hadoop、hbase、Dubbo注册中心、kafka	k8s
应用场景	服务发现、负载均衡、发布/订阅、分布式队列、分布式锁、分布式通知与协调、统一命名服务（dubbo）、分布式配置管理（solr的配置集中管理）。参考：Zookeeper 介绍与内部原理 - 云+社区 - 腾讯云 (tencent.com)
使用对接	通过sdk包对接，c语言版本，java版本。	可以通过sdk包对接，也提供了restful api接口，ssl安全。
事件监听器watcher	通过事件监听器watcher获取最新配置信息，或者节点的变动信息，只能收到一次事件通知。	可以持续监听
其他	1、leader提供读写参与选举、follower提供读且参与选举、observer仅提供读不参与选举，observer和follower可以将写请求转发给leader。 2、分为持久节点和临时节点。持久节点一直存在，除非主动移除。临时节点的客户端会话如果一直保持活动，临时节点就会一直存在。 3、顺序访问，对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号zxid。	部署简单、提供API对接、安全、高性能、持久化

参考：ZooKeeper概念详解，最全整理_春风化作秋雨的博客-CSDN博客_zookeeper
Zookeeper vs Etcd - 知乎

Zookeeper
选举状态：
LOOKING: 竞选状态
FOLLOWING: 随从状态，同步 leader 状态，参与投票
OBSERVING: 观察状态，同步 leader 状态，不参与投票
LEADING: 领导者状态
参考：13.0 Zookeeper Leader 选举原理 | 菜鸟教程 (runoob.com)
leader选举过程（FastLeaderElection）：
1、leader挂掉之后，其他非leader节点变为looking状态，每个节点发出一个投票（myid，zxid）给其他所有节点，第一轮都投的自己。
2、接收其他节点的投票，并判断投票的有效性，如投票的节点是否是looking状态、是否是本轮投票等。
3、投票PK，将其他节点的投票和自己的进行对比，优先zxid最大的，然后myid大的，据此更新自己节点的投票情况，再次发送自己的投票结果（为了刷新自己的选举轮次，无论投票是否变更，都要再次发送）。
逻辑时钟(epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是相同的，每投完一次值会增加。
事务ID(zxid)：值越大说明数据越新，权重越大。
服务器ID(myid)：编号越大在选举算法中权重越大。
4、统计投票，如果发现某个节点票数已经过半，则该节点竞选胜出。
5、每个节点更新自己的状态为FOLLOWING或者LEADING。
有可能要多轮投票才能决定出。
在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举。
参考：【分布式】Zookeeper的Leader选举-选举过程介绍比较清晰_gaoshan12345678910的博客-CSDN博客_zk选举过程

消息队列的作用：异步、解耦、削峰

1、事务一致性
2PC（prepare、confirm）
TCC（try、confirm、cancel）
最终一致性（Kafka、RocketMQ）：发送失败（消息表，RocketMQ本身支持事务消息，内部实现了该步骤）、丢失消费（ACK机制）、重复消费（去重表）
状态表
对账：增量对账、全量堆栈，使用定时任务或者消息队列。
弱一致性：先扣库存后生成订单，库存会多扣，再通过状态表来校正。

2、多副本一致性
paxos（多写多读）、zab（单写多读、双向心跳检测）、raft（单写多读、单向心跳检测）算法。
Raft 算法解读 · SOFAStack

分布式
CAP理论：P是固定的，CA中取舍。
BASE理论：满足最终一致性。

SOA -> MSA
1、SOA中心化，MSA去中心化。
2、MSA耦合度更低。

MySQL高可用
使用HAProxy、Keepalived的主从半同步复制（原生）。
MMM（Master-Master replication manager for MySQL），整个 MySQL 集群提供 1 个写 VIP(Virtual IP）和 N（N>=1）个读 VIP 的对外服务。在从节点中选择一个候选主节点作为新的主节点，进行数据补齐，然后将原有的master尝试加到新的master上。
MHA（master HA） manager，解决传统MySQL主从架构中只有一台主MySQL的单点故障问题，能做到30s内完成故障切换，找一台最接近master的slave提升为master，根据binlog时间点最新的那个。管理节点仍然是单点。
ZooKeeper+Proxy仍然依赖MySQL本身的半同步复制。
SAN共享储存
DRBD磁盘复制
官方提供的集群部署方案，国内较少人使用，收费。
基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。能够保证强一致性，有成熟社区，有互联网公司在大规模使用。
参考：10款常见MySQL高可用方案选型解读 - 腾讯云开发者社区-腾讯云
踩坑无数，美团点评高可用数据库架构演进-51CTO.COM Mysql高可用架构 - 是谁扭曲了时空 - 博客园