概括： Leader选举。选择一台服务器作为leader，心跳监测，如果Leader崩溃则选择一台服务器作为Leader 系统正常运行（日志复制） Leader变化后的安全性和一致性 处理旧Leader 客户端和服务端的交互 配置的变更 服务的状态： 在任何时候，每个服务器都处于三种状态之一： Leader：处理所有客户端交互、日志复制。同时只能有一个Leader Followe

1 CAP定理 C：Consistency 强一致性 A：Avaliablity 可用性 P：partition Tolerance 分区容错性 2 分布式一致性的三种级别 01 强一致性：系统写入什么，读出来的就是什么 02 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态 03 最终一致性：弱一致性的升级版，系统会保证在

服务的状态 Leader：处理所有客户端的线性写操作，日志复制。同时只能有一个Leader Follower：被动处理Leader请求和客户端读请求 Looking：用来重新选举Leader Observer：特殊节点状态，不参与Leader选举，负责接收客户端读请求 正常情况下，1个Leader，n-1个Follower Leader选举 Epoch > Counter > SI

概念：基于公平性考虑的P2C算法， 对于每次调用，从可用的服务列表中选择两个节点，然后选择一个“当前正在处理的连接数”较少的那个节点。 使用场景：服务器机器配置比较均匀下，高并发下快速选择负载较轻的服务器。 优点：公平性、均衡性 缺点：随机性，简单的P2C无法考虑服务器的实时负载情况和性能指标 实现思路： 1.获取可用的服务提供列表 2.选择两个随机的服务提供者 3.通过负载指标选择负载较轻的服

概念：一致性哈希算法将所有服务器和数据节点映射到一个虚拟的哈希环上，哈希环的范围通常是0到2^32-1（或其他合适的范围） 适用场景：分布式系统中需要动态增减节点、实现负载均匀和保持数据一致性的场景 优点：整体负载均匀，可扩展性和容错性 缺点：节点倾斜，节点动态变化，哈希函数和哈希内容 实现思路： 1.构建哈希环：哈希环是一个循环数组，所有的服务器节点和请求都要依赖这个数组排序计算 2.哈希映射

概念：为每个服务器分配一个权重值，表示其处理请求的能力，与加权轮询算法类似。不同之处在于选择响应时间短且权重合适的服务来分配。 适用场景：服务器性能和负载差异较大，注重用户体验 代码实现：Next Page 优点：响应时间优化，动态负载适应 缺点：算法的复杂性，资源开销，权重设置不准确导致负载不均衡 实现思路：1.定义一个数据结构：用于保存服务器权重值和最短响应时间数等信息 2.初始化服务器列表

1 基础1.1 随机算法概念：将请求随机分发到候选服务器 使用场景：请求调用量大的情况较为适用，调用量越大，负载越均衡；调用量越小，容易出现热点 代码实现：ThreadLocalRandom.current().nextInt(随机数) 优点：简单易用，通用性强，容易实现 缺点：不考虑服务器实时负载，存在累积请求的问题 1.2 加权随机算法概念：为每个服务器分配一个权重值，根据权重比例进行随机访问

概念：为每个服务器分配一个权重值，表示其处理请求的能力，与加权轮询算法类似。不同之处在于服务器的选择是基于当前服务器的活跃连接数进行决策。 适用场景：服务器性能和负载差异较大的场景，适用有不同服务器性能差异和负载波动的情况 代码实现：Next Page 优点：精准负载分配，动态负载分配，避免不活跃的服务器 缺点：算法的复杂性，资源开销，权重设置不准确导致负载不均衡 实现思路： 1.定义一个数据结

Google Guava RateLimiter 12345<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>22.0</version></dependency&

实现思路： 把时间线划分为多个独立且固定大小的窗口 设置一个计数器，用于记录限流阈值 拦截所有请求执行canPass操作，如果在当前数据窗口计数器超过了阈值，则后续落在该窗口的请求都会被拒绝，没有超过则计数器 +1 时间到达下一个时间窗口后，重置时间窗口 123456789101112131415161718192021222324252627282930313233343536373839