2.分布式-算法

os-lee

已于 2024-05-13 10:31:45 修改

阅读量1.1k

点赞数 11

分类专栏：分布式文章标签：分布式

于 2024-05-12 09:53:51 首次发布

本文链接：https://blog.csdn.net/qq_22321199/article/details/138655637

版权

分布式专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、限流算法有哪些？

1.计数器算法（Counter-Based Algorithm）

2.固定窗口算法（Fixed Window）

3.滑动窗口算法（Sliding Window）

4.令牌桶算法（Token Bucket）

一、限流算法有哪些？

分布式限流算法主要用于控制系统的并发请求量，保护系统免受过载影响，确保服务稳定性。以下是一些常见的分布式限流算法：

1.计数器算法（Counter-Based Algorithm）

一种简化的限流方式，通过维护全局或针对特定资源的计数器，在单位时间内只允许一定数量的请求通过。这是一种非常直接的方法，但可能不够精确，且在高并发下可能需要复杂的锁机制来保证计数的准确性。

2.固定窗口算法（Fixed Window）

最简单的限流算法之一，将时间划分为多个固定大小的时间窗口，每个窗口内分配固定的请求数量配额。一旦窗口内的请求超过配额，则后续请求被限制。这种方法简单但存在突刺问题，即在窗口切换时刻可能瞬间允许大量请求通过。

3.滑动窗口算法（Sliding Window）

为了解决固定窗口算法的突刺问题，滑动窗口算法将时间窗口设计为滑动的，可以更精确地统计任意时间跨度内的请求量。它通过维护一系列连续的固定大小窗口来实现，能够平滑地处理请求流量波动。

4.令牌桶算法（Token Bucket）

该算法模拟一个桶，系统按照恒定速率向桶中添加令牌，请求需要消耗令牌才能通过。如果桶满，新加入的令牌会被丢弃；如果没有足够的令牌则请求被拒绝。这种方式可以平滑突发请求，并允许一定程度的突发流量。

实现方案：Guava RateLimiter是谷歌提供的限流，基于令牌桶算法，适用于单实例的系统。

5.漏桶算法（Leaky Bucket）

与令牌桶相反，漏桶算法限制的是流出速率而非流入速率。请求先进入一个“桶”中，然后以恒定速率“漏出”并被处理。当桶满时，新来的请求将被丢弃或拒绝。它保证了输出速率的恒定，适合控制发送速率场景。

算法实现：可以准备一个队列来保存暂时处理不了的请求，然后通过一个线程池定期从队列中获取请求来执行。

二、什么是幂等性？

幂等性（Idempotence）是一个源于数学的概念，后来被广泛应用于计算机科学和分布式系统设计中。在数学上，一个幂等操作是指一个元素在某一操作下作用多次的结果与作用一次的结果相同。换言之，对于一个幂等函数即多次应用该函数结果不变。

在计算机科学及网络通信领域，特别是分布式系统和API设计中，幂等性的含义稍有不同，但核心思想一致。一个操作或一个接口被称为幂等的，如果它能够被重复执行任意次数，而系统状态保持不变，结果也与首次执行时相同。这意味着，即使由于网络延迟、重传或其他因素导致请求被发送多次，幂等操作也不会对系统产生额外的影响，保证了结果的一致性和系统的稳定性。

幂等性的几个关键点包括：

安全性：重复执行不改变系统状态。
可靠性：在网络不稳定导致请求重发时，幂等性保证了服务的正确性。
简化重试逻辑：在需要重试操作时，无需复杂的逻辑来判断操作是否已完成，直接重试即可。
常见场景：读取数据的操作天然幂等，修改或写入操作往往需要特别设计以实现幂等性，例如通过条件更新、事务控制或唯一标识符来避免重复处理。

实现幂等性的策略有：

使用唯一交易号或事务ID，确保同一操作不会被执行多次。
检查前置条件，只有在条件满足时才执行操作。
乐观锁或悲观锁机制，防止并发修改冲突。
记录已处理请求的标识，如利用Redis等缓存系统存储处理状态。
设计补偿机制，对非幂等操作进行结果校验和回滚处理。

三、Raft算法

1.Raft是什么

Raft算法是一种分布式共识算法，设计初衷是为了替代Paxos算法，又名易于理解的一致性算法。算法的过程如同选举一样，参选者需要说服大多数选民（Server）投票给它，一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。

2.Raft的工作流程

2.1.Raft算法的角色

Raft算法将Server进程分为三种角色：

Leader（领导者）
Follower（跟随者）
Candidate（候选者）

就像一个民主社会，领导者由跟随者投票选出。在大选期间所有跟随者会变成候选者参与竞选，投票选出领导者。领导者开始这届任期（Term），候选者变回跟随者服从领导者的领导。

三类角色的变迁图如下：

2.2.Leader的选举过程

Raf使用心跳（heartbeat）触发Leader选举，Leader向所有Followers周期性发送heartbeat。如果某个Follower在选举超时时间没有收到Leader的heartbeat，就会询问其他Follower在确定Leader离线后发起一次Leader选举。

Follower将其当前的term加1然后转换为Candidate。它首先给自己投票并且给集群中的其他服务器发送RequestVote RPC。结果有以下三种：

赢得了多数（超过1/2）选票，成功当选为Leader；
收到了Leader的消息，表示有其他服务器已经抢先当选了Leader；
没有赢得多数选票，Leader竞选失败，等待选举超时（Election Timeout）后发起下一次选举。

竞选过程中除了term，还有权重，数据同步，网络等其他因素作为竞选条件。

四、分布式锁

分布式锁是分布式系统中用于解决资源竞争和保持数据一致性的关键技术。以下是几种主流的分布式锁解决方案：

1.基于数据库的分布式锁

这种方案通过关系型数据库实现锁机制。一种常见做法是在数据库中创建一个锁表，包含锁的标识、持有者、过期时间等字段。获取锁时，通过插入一条记录尝试获取锁，如果插入成功表示获取锁成功；释放锁则通过删除记录实现。需要注意的是，为防止死锁和提高效率，通常需要实现锁的超时与自动释放机制。

2.基于缓存的分布式锁（如Redis）

SETNX 是 Redis 中的一个命令，全称是 SET if Not eXists，用于设置键的值，当且仅当键不存在。这个命令在分布式系统中非常有用，特别是在实现分布式锁时，因为它提供了一种原子性的方式来避免并发问题。

# key: 键名，用于唯一标识锁。
# value: 要设置的值，通常用于标记锁的持有者或者存放一些元数据，如锁的过期时间等。
SETNX key value

行为说明：

如果 key 已经存在，那么 SETNX 命令不做任何操作，返回 0（false）。
如果 key 不存在，那么 SETNX 命令会将 key 的值设置为 value，并返回 1（true）。

分布式锁中的应用：

在分布式锁场景中，SETNX 常常与一个过期时间 (EX 或 PX) 结合使用，以避免锁因为某些原因（如持有锁的客户端崩溃）无法被正常释放。这样的组合能够实现一个具有自动过期特性的锁，减少死锁的风险。

SETNX my_lock some_unique_value PX 10000

3.基于Zookeeper的分布式锁

ZooKeeper作为一个分布式协调服务，提供了临时有序节点的功能，非常适合实现分布式锁。客户端可以在特定的路径下创建临时有序节点，通过节点的顺序性和临时性来决定锁的拥有者。获取锁时创建节点，判断自己是否为序号最小的节点以确认是否获取锁；释放锁时删除节点。Zookeeper还提供了监听机制，使得等待锁的客户端可以在锁释放时得到通知。