简介

# 事务

事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。事务应该具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。

# 分布式事务

分布式事务是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了ACID事务的特性。

# 强一致性、弱一致性、最终一致性

强一致性

任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。

弱一致性

数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

最终一致性

不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

由于分布式事务方案，无法做到完全的ACID的保证，没有一种完美的方案，能够解决掉所有业务问题。因此在实际应用中，会根据业务的不同特性，选择最适合的分布式事务方案。

# 分布式事务的基础

# CAP理论

Consistency（一致性）：数据一致更新，所有数据变动都是同步的（强一致性）。

Availability（可用性）：好的响应性能。

Partition tolerance（分区容错性） ：可靠性。

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

CA系统（放弃P）：指将所有数据（或者仅仅是那些与事务相关的数据）都放在一个分布式节点上，就不会存在网络分区。所以强一致性以及可用性得到满足。

CP系统（放弃A）：如果要求数据在各个服务器上是强一致的，然而网络分区会导致同步时间无限延长，那么如此一来可用性就得不到保障了。坚持事务ACID（原子性、一致性、隔离性和持久性）的传统数据库以及对结果一致性非常敏感的应用通常会做出这样的选择。

AP系统（放弃C）：这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。如果即要求系统高可用又要求分区容错，那么就要放弃一致性了。因为一旦发生网络分区，节点之间将无法通信，为了满足高可用，每个节点只能用本地数据提供服务，这样就会导致数据不一致。一些遵守BASE原则数据库，（如：Cassandra、CouchDB等）往往会放宽对一致性的要求（满足最终一致性即可），一次来获取基本的可用性。

# BASE理论

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展。

1. 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
2. 软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
3. 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。

BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

# 分布式事务解决方案

分布式事务的实现主要有以下 6 种方案：

• 2PC 方案
• TCC 方案
• 本地消息表
• MQ事务
• Saga事务
• 最大努力通知方案

# 2PC方案

2PC方案分为两阶段:

第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

优点： 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是从5.5开始支持。

缺点:

• 单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
• 同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
• 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

总的来说，2PC方案比较简单，成本较低，但是其单点问题，以及不能支持高并发（由于同步阻塞）依然是其最大的弱点。

# TCC

TCC 的全称是：Try、Confirm、Cancel。

• Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行 锁定或者预留。
• Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作。
• Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要 进行补偿，就是执行已经执行成功的业务逻辑的回滚操作。（把那些执行成功的回滚）

举个简单的例子如果你用100元买了一瓶水， Try阶段:你需要向你的钱包检查是否够100元并锁住这100元，水也是一样的。

如果有一个失败，则进行cancel(释放这100元和这一瓶水)，如果cancel失败不论什么失败都进行重试cancel，所以需要保持幂等。

如果都成功，则进行confirm,确认这100元扣，和这一瓶水被卖，如果confirm失败无论什么失败则重试(会依靠活动日志进行重试)。

这种方案说实话几乎很少人使用，但是也有使用的场景。因为这个事务回滚实际上是严重依赖于你自己写代码来回滚和补偿了，会造成补偿代码巨大。

# 本地消息表

查看更多

传统的单体架构的时候，我们基本是单库然后业务单表的结构。每个业务表的ID一般我们都是从1增，通过AUTO_INCREMENT=1设置自增起始值，但是在分布式服务架构模式下分库分表的设计，使得多个库或多个表存储相同的业务数据。这种情况根据数据库的自增ID就会产生相同ID的情况，不能保证主键的唯一性。

如上图，如果第一个订单存储在 DB1 上则订单 ID 为1，当一个新订单又入库了存储在 DB2 上订单 ID 也为1。我们系统的架构虽然是分布式的，但是在用户层应是无感知的，重复的订单主键显而易见是不被允许的。那么针对分布式系统如何做到主键唯一性呢？

# UUID

UUID （Universally Unique Identifier），通用唯一识别码的缩写。UUID是由一组32位数的16进制数字所构成，所以UUID理论上的总数为 1632=2128，约等于 3.4 x 10^38。也就是说若每纳秒产生1兆个UUID，要花100亿年才会将所有UUID用完。

生成的UUID是由 8-4-4-4-12格式的数据组成，其中32个字符和4个连字符’ – ‘，一般我们使用的时候会将连字符删除 uuid.toString().replaceAll("-","")。

目前UUID的产生方式有5种版本，每个版本的算法不同，应用范围也不同。

• 基于时间的UUID – 版本1： 这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，可以通过 org.apache.logging.log4j.core.util包中的 UuidUtil.getTimeBasedUuid()来使用或者其他包中工具。由于使用了MAC地址，因此能够确保唯一性，但是同时也暴露了MAC地址，私密性不够好。
• DCE安全的UUID – 版本2 DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。
• 基于名字的UUID（MD5）- 版本3 基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了：相同名字空间中不同名字生成的UUID的唯一性；不同名字空间中的UUID的唯一性；相同名字空间中相同名字的UUID重复生成是相同的。
• 随机UUID – 版本4 根据随机数，或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的，但是重复的可能性可以忽略不计，因此该版本也是被经常使用的版本。JDK中使用的就是这个版本。
• 基于名字的UUID（SHA1） – 版本5 和基于名字的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法。

我们 Java中 JDK自带的 UUID产生方式就是版本4根据随机数生成的 UUID 和版本3基于名字的 UUID，有兴趣的可以去看看它的源码。

public static void main(String[] args) {

    //获取一个版本4根据随机字节数组的UUID。
    UUID uuid = UUID.randomUUID();
    System.out.println(uuid.toString().replaceAll("-",""));

    //获取一个版本3(基于名称)根据指定的字节数组的UUID。
    byte[] nbyte = {10, 20, 30};
    UUID uuidFromBytes = UUID.nameUUIDFromBytes(nbyte);
    System.out.println(uuidFromBytes.toString().replaceAll("-",""));
}

得到的UUID结果，

59f51e7ea5ca453bbfaf2c1579f09f1d
7f49b84d0bbc38e9a493718013baace6

虽然 UUID 生成方便，本地生成没有网络消耗，但是使用起来也有一些缺点，

• 不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
• 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，暴露使用者的位置。
• 对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能，可以查阅 Mysql 索引原理 B+树的知识。

# 数据库生成

是不是一定要基于外界的条件才能满足分布式唯一ID的需求呢，我们能不能在我们分布式数据库的基础上获取我们需要的ID？

由于分布式数据库的起始自增值一样所以才会有冲突的情况发生，那么我们将分布式系统中数据库的同一个业务表的自增ID设计成不一样的起始值，然后设置固定的步长，步长的值即为分库的数量或分表的数量。

以MySQL举例，利用给字段设置auto_increment_increment和auto_increment_offset来保证ID自增。

• auto_increment_offset：表示自增长字段从那个数开始，他的取值范围是1 .. 65535。
• auto_increment_increment：表示自增长字段每次递增的量，其默认值是1，取值范围是1 .. 65535。

假设有三台机器，则DB1中order表的起始ID值为1，DB2中order表的起始值为2，DB3中order表的起始值为3，它们自增的步长都为3，则它们的ID生成范围如下图所示：

通过这种方式明显的优势就是依赖于数据库自身不需要其他资源，并且ID号单调自增，可以实现一些对ID有特殊要求的业务。

但是缺点也很明显，首先它强依赖DB，当DB异常时整个系统不可用。虽然配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。还有就是ID发号性能瓶颈限制在单台MySQL的读写性能。

# 使用redis实现

Redis实现分布式唯一ID主要是通过提供像 INCR 和 INCRBY 这样的自增原子命令，由于Redis自身的单线程的特点所以能保证生成的 ID 肯定是唯一有序的。

但是单机存在性能瓶颈，无法满足高并发的业务需求，所以可以采用集群的方式来实现。集群的方式又会涉及到和数据库集群同样的问题，所以也需要设置分段和步长来实现。

为了避免长期自增后数字过大可以通过与当前时间戳组合起来使用，另外为了保证并发和业务多线程的问题可以采用 Redis + Lua的方式进行编码，保证安全。

Redis 实现分布式全局唯一ID，它的性能比较高，生成的数据是有序的，对排序业务有利，但是同样它依赖于redis，需要系统引进redis组件，增加了系统的配置复杂性。

当然现在Redis的使用性很普遍，所以如果其他业务已经引进了Redis集群，则可以资源利用考虑使用Redis来实现。

# 雪花算法-Snowflake

查看更多

为什么要使用分布式锁

在单机环境下，当存在多个线程可以同时改变某个变量（可变共享变量）时，就会出现线程安全问题。这个问题可以通过 JAVA 提供的 volatile、ReentrantLock、synchronized 以及 concurrent 并发包下一些线程安全的类等来避免。

而在多机部署环境，需要在多进程下保证线程的安全性，Java提供的这些API仅能保证在单个JVM进程内对多线程访问共享资源的线程安全，已经不满足需求了。这时候就需要使用分布式锁来保证线程安全。通过分布式锁，可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。

# 分布式锁应该具备哪些条件

在分析分布式锁的三种实现方式之前，先了解一下分布式锁应该具备哪些条件：

1. 互斥性。在任意时刻，只有一个客户端能持有锁。
2. 不会死锁。具备锁失效机制，防止死锁。即使有客户端在持有锁的期间崩溃而没有主动解锁，也要保证后续其他客户端能加锁。
3. 加锁和解锁必须是同一个客户端。客户端a不能将客户端b的锁解开，即不能误解锁。
4. 高性能、高可用的获取锁与释放锁。
5. 具备可重入特性。
6. 具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

# 分布式锁的三种实现方式

1. 基于数据库实现分布式锁；
2. 基于缓存（Redis等）实现分布式锁；
3. 基于Zookeeper实现分布式锁。

# 基于数据库的实现方式

悲观锁

创建一张锁表，然后通过操作该表中的数据来实现加锁和解锁。当要锁住某个方法或资源时，就向该表插入一条记录，表中设置方法名为唯一键，这样多个请求同时提交数据库时，只有一个操作可以成功，判定操作成功的线程获得该方法的锁，可以执行方法内容；想要释放锁的时候就删除这条记录，其他线程就可以继续往数据库中插入数据获取锁。

乐观锁

每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。

扣减余额就可以使用这种方案。

具体实现：增加个version字段，每次更新修改，都会自增加一，然后去更新余额时，把查出来的那个版本号，带上条件去更新，如果是上次那个版本号，就更新，如果不是，表示别人并发修改过了，就继续重试。

# 基于Redis的实现方式

# 简单实现

Redis 2.6.12 之前的版本中采用 setnx + expire 方式实现分布式锁，在 Redis 2.6.12 版本后 setnx 增加了过期时间参数：

SET lockKey value NX PX expire-time

所以在Redis 2.6.12 版本后，只需要使用setnx就可以实现分布式锁了。

加锁逻辑：

1. setnx争抢key的锁，如果已有key存在，则不作操作，过段时间继续重试，保证只有一个客户端能持有锁。
2. value设置为 requestId（可以使用机器ip拼接当前线程名称），表示这把锁是哪个请求加的，在解锁的时候需要判断当前请求是否持有锁，防止误解锁。比如客户端A加锁，在执行解锁之前，锁过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。
3. 再用expire给锁加一个过期时间，防止异常导致锁没有释放。

解锁逻辑：

首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁。使用lua脚本实现原子操作，保证线程安全。

下面我们通过Jedis（基于java语言的redis客户端）来演示分布式锁的实现。

Jedis实现分布式锁

查看更多

RPC简介

RPC，英文全名remote procedure call，即远程过程调用。就是说一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

可以这么说，RPC就是要像调用本地的函数一样去调远程函数。

RPC是一个完整的远程调用方案，它通常包括通信协议和序列化协议。

其中，通信协议包含http协议（如gRPC使用http2）、自定义报文的tcp协议（如dubbo）。序列化协议包含基于文本编码的xml、json，基于二进制编码的protobuf、hessian等。

protobuf 即 Protocol Buffers，是一种轻便高效的结构化数据存储格式，与语言、平台无关，可扩展可序列化。protobuf 性能和效率大幅度优于 JSON、XML 等其他的结构化数据格式。protobuf 是以二进制方式存储，占用空间小，但也带来了可读性差的缺点（二进制协议，因为不可读而难以调试，不好定位问题）。

Protobuf序列化协议相比JSON有什么优点？

1：序列化后体积相比Json和XML很小，适合网络传输

2：支持跨平台多语言

3：序列化反序列化速度很快，快于Json的处理速速

一个完整的RPC过程，都可以用下面这张图来描述：

stub说的都是“一小块代码”，通常是有个caller要调用callee的时候，中间需要一些特殊处理的逻辑，就会用这种“小块代码”去做。

1. 服务消费端（client）以本地调用的方式调用远程服务；
2. 客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：RpcRequest；
3. 客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端；
4. 服务端 Stub（桩）收到消息将消息反序列化为Java对象: RpcRequest；
5. 服务端 Stub（桩）根据RpcRequest中的类、方法、方法参数等信息调用本地的方法；
6. 服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：RpcResponse（序列化）发送至消费方；
7. 客户端 Stub（client stub）接收到消息并将消息反序列化为Java对象:RpcResponse ，这样也就得到了最终结果。

# RPC 解决了什么问题？

让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。

# 常见的 RPC 框架有哪些?

• Dubbo: Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。目前 Dubbo 已经成为 Spring Cloud Alibaba 中的官方组件。
• gRPC ：基于HTTP2。gRPC是可以在任何环境中运行的现代开源高性能RPC框架。它可以通过可插拔的支持来有效地连接数据中心内和跨数据中心的服务，以实现负载平衡，跟踪，运行状况检查和身份验证。它也适用于分布式计算的最后一英里，以将设备，移动应用程序和浏览器连接到后端服务。
• Hessian： Hessian是一个轻量级的remoting on http工具，使用简单的方法提供了RMI的功能。 采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
• Thrift： Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。

# 有了HTTP ，为啥还要用RPC进行服务调用?

首先，RPC是一个完整的远程调用方案，它通常包括通信协议和序列化协议。而HTTP只是一个通信协议，不是一个完整的远程调用方案。这两者不是对等的概念，用来比较不太合适。

RPC框架可以使用 HTTP协议作为传输协议或者直接使用自定义的TCP协议作为传输协议，使用不同的协议一般也是为了适应不同的场景。

HTTP+Restful，其优势很大。它可读性好，且应用广、跨语言的支持。

但是使用该方案也有其缺点，这是与其优点相对应的：

• 首先是有用信息占比少，毕竟HTTP工作在第七层，包含了大量的HTTP头等信息。
• 其次是效率低，还是因为第七层的缘故，必须按照HTTP协议进行层层封装。

而使用自定义tcp协议的话，可以极大地精简了传输内容，这也是为什么有些后端服务之间会采用自定义tcp协议的rpc来进行通信的原因。

# 各种序列化技术

查看更多

大多数情况下，我们不需要自己实现一个限流系统，但限流在实际应用中是一个非常微妙、有很多细节的系统保护手段，尤其是在高流量时，了解你所使用的限流系统的限流算法，将能很好地帮助你充分利用该限流系统达到自己的商业需求和目的，并规避一些使用限流系统可能带来的大大小小的问题。

# 令牌桶算法

令牌桶（token bucket）算法，指的是设计一个容器（即“桶”），由某个组件持续运行往该容器中添加令牌（token），令牌可以是简单的数字、字符或组合，也可以仅仅是一个计数，然后每个请求进入系统时，需要从桶中领取一个令牌，所有请求都必须有令牌才能进入后端系统。当令牌桶空时，拒绝请求；当令牌桶满时，不再往其中添加新的令牌。 令牌桶算法的架构如图1所示：

令牌桶算法的实现逻辑如下：

首先会有一个定义的时间窗口的访问次数阈值，例如每天1000人，每秒5个请求之类，限流系统一般最小粒度是秒，再小就会因为实现和性能的原因而变得不准确或不稳定，假设是T秒内允许N个请求，那么令牌桶算法则会使令牌添加组件每T秒往令牌桶中添加N个令牌。

其次，令牌桶需要有一个最大值M，当令牌添加组件检测到令牌桶中已经有M个令牌时，剩余的令牌会被丢弃。反映到限流系统中，可以认为是当前系统允许的瞬时最大流量，但不是持续最大流量。例如令牌桶中的令牌最大数量是100个，每秒钟会往其中添加10个新令牌，当令牌满的时候，突然出现100 TPS的流量，这时候是可以承受的，但是假如连续两秒的100 TPS流量就不行，因为令牌添加速度是一秒10个，添加速度跟不上使用速度。

因此，凡是使用令牌桶算法的限流系统，我们都会注意到它在配置时要求两个参数：

• 平均阈值（rate或average）
• 高峰阈值（burst或peak）

通过笔者的介绍，读者应该意识到，令牌桶算法的高峰阈值是有特指的，并不是指当前限流系统允许的最高流量。因为这一描述可能会使人认为只要低于该阈值的流量都可以，但事实上不是这样，因为只要高于添加速度的流量持续一段时间都会出现问题。

反过来说，令牌桶算法的限流系统不容易计算出它支持的最高流量，因为它能实时支持的最高流量取决于那整个时间段内的流量变化情况即令牌存量，而不是仅仅取决于一个瞬时的令牌量。

最后，当有组件请求令牌的时候，令牌桶会随机挑选一个令牌分发出去，然后将该令牌从桶中移除。注意，此时令牌桶不再做别的操作，令牌桶永远不会主动要求令牌添加组件补充新的令牌。

令牌桶算法有一个同一思想、方向相反的变种，被称为漏桶（leaky bucket）算法，它是令牌桶的一种改进，在商业应用中非常广泛。

漏桶算法的基本思想，是将请求看作水流，用一个底下有洞的桶盛装，底下的洞漏出水的速率是恒定的，所有请求进入系统的时候都会先进入这个桶，并慢慢由桶流出交给后台服务。桶有一个固定大小，当水流量超过这个大小的时候，多余的请求都会被丢弃。

漏桶算法的架构如图所示：

漏桶算法的实现逻辑如下：

• 首先会有一个容器存放请求，该容器有一个固定大小M，所有请求都会被先存放到该容器中。
• 该容器会有一个转发逻辑，该转发以每T秒N个请求的速率循环发生。
• 当容器中请求数已经达到M个时，拒绝所有新的请求。

因此同样地，漏桶算法的配置也需要两个值：平均值（rate）和峰值（burst）。只是平均值这时候是用来表示漏出的请求数量，峰值则是表示桶中可以存放的请求数量。

注意：漏桶算法和缓冲的限流思想不是一回事！

同样是将请求放在一个容器中，漏桶算法和缓冲不是一个用途，切不可搞混，它们的区别如下：

• 漏桶算法中，存在桶中的请求会以恒定的速率被漏给后端业务服务器，而缓冲思想中，放在缓冲区域的请求只有等到后端服务器空闲下来了，才会被发出去。
• 漏桶算法中，存在桶中的请求是原本就应该被系统处理的，是系统对外界宣称的预期，不应该被丢失，而缓冲思想中放在缓冲区域的请求仅仅是对意外状况的尽量优化，并没有任何强制要求这些请求可以被处理。

漏桶算法和令牌桶算法在思想上非常接近，而实现方向恰好相反，它们有如下的相同和不同之处：

• 令牌桶算法以固定速率补充可以转发的请求数量（令牌），而漏桶算法以固定速率转发请求；
• 令牌桶算法限制数量的是预算数，漏桶算法限制数量的是实际请求数；
• 令牌桶算法在有爆发式增长的流量时可以一定程度上接受，漏桶算法也是，但当流量爆发时，令牌桶算法会使业务服务器直接承担这种流量，而漏桶算法的业务服务器感受到的是一样的速率变化。

因此，通过以上比较，我们会发现漏桶算法略优于令牌桶算法，因为漏桶算法对流量控制更平滑，而令牌桶算法在设置的数值范围内，会将流量波动忠实地转嫁到业务服务器头上。

漏桶算法在Nginx和分布式的限流系统例如Redis的限流功能中都有广泛应用，是目前业界最流行的算法之一。

# 时间窗口算法

查看更多

一、 什么是负载均衡？

什么是负载均衡？

记得第一次接触 Nginx 是在实验室，那时候在服务器部署网站需要用 Nginx 。Nginx 是一个服务组件，用来反向代理、负载平衡和 HTTP 缓存等。那么这里的 负载均衡 是什么？

负载均衡（LB，Load Balance），是一种技术解决方案。用来在多个资源（一般是服务器）中分配负载，达到最优化资源使用，避免过载。

资源，相当于每个服务实例的执行操作单元，负载均衡就是将大量的数据处理操作分摊到多个操作单元进行执行，用来解决互联网分布式系统的大流量、高并发和高可用的问题。那什么是高可用呢？

# 二、什么是高可用？

首先了解什么是高可用？

这是 CAP 定理是分布式系统的基础，也是分布式系统的 3 个指标：

1. Consistency（一致性）
2. Availability（可用性）
3. Partition tolerance（分区容错性）

那高可用（High Availability）是什么？高可用，简称 HA，是系统一种特征或者指标，通常是指，提供一定性能上的服务运行时间，高于平均正常时间段。反之，消除系统服务不可用的时间。

衡量系统是否满足高可用，就是当一台或者多台服务器宕机的时候，系统整体和服务依然正常可用。

举个例子，一些知名的网站保证 4 个 9 以上的可用性，也就是可用性超过 99.99%。那 0.01% 就是所谓故障时间的百分比。比如电商网站有赞，服务不可用会造成商家损失金钱和用户。那么在提高可用性基础上同时，对系统宕机和服务不可用会有补偿。

比如下单服务，可以使用带有负载均衡的多个下单服务实例，代替单一的下单服务实例，即使用冗余的方式来提高可靠性。

总而言之，负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一。一般通过负载均衡，冗余同一个服务实例的方式，解决分布式系统的大流量、高并发和高可用的问题。负载均衡核心关键：在于是否分配均匀。

# 三、常见的负载均衡案例

场景1：微服务架构中，网关路由到具体的服务实例 hello：

• 两个相同的服务实例 hello service ，一个端口 8000 ，另一个端口 8082
• 通过 Kong 的负载均衡 LB 功能，让请求均匀的分发到两个 hello 服务实例
• Kong 的负载均衡策略算法很多：默认 weighted-round-robin 算法，还有 consumer: consumer id 作为 hash 算法输入值等

场景2：微服务架构中，A 服务调用 B 服务的集群。通过了 Ribbon 客户端负载均衡组件：

• 负载均衡策略算法并不高级，最简单的是随机选择和轮循

查看更多