消息队列基本原理

📦 本文已归档到：「blog」

消息队列（Message Queue，简称 MQ）技术是分布式应用间交换信息的一种技术。

消息队列主要解决应用耦合，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

注意：_为了简便，下文中除了文章标题，一律使用 MQ 简称_。

为什么要使用 MQ

MQ 比较核心的优点有 3 个：解耦、异步、削峰。

解耦

不同系统如果要建立通信，传统的做法是：调用接口。

如果需要和新的系统建立通信或删除已建立的通信，都需要修改代码，这种方案显然耦合度很高。

如果使用 MQ，系统间的通信只需要通过发布/订阅（Pub/Sub）模型即可，彼此没有直接联系，也就不需要相互感知，从而达到 解耦。

异步

假设这样一个场景，用户向系统 A 发起请求，系统 A 处理计算只需要 10 ms，然后通知系统 BCD 写库，系统 BCD 写库耗时分别为：100ms、200ms、300ms。最终总耗时为： 10+100ms+200ms+300ms=610ms。此外，加上请求和响应的网络传输时间，从用户角度看，可能要等待将近 1s 才能得到结果。

如果使用 MQ，系统 A 接到请求后，耗时 10ms 处理计算，然后向系统 BCD 连续发送消息，假设耗时 5ms。那么 这一过程的总耗时为 3ms + 5ms = 8ms，这相比于 610 ms，大大缩短了响应时间。至于系统 BCD 的写库操作，只要自行消费 MQ 后处理即可，用户无需关注。

削峰

假设某个系统读写数据库的稳定性能为每秒处理 1000 条数据。平常情况下，远远达不到这么大的处理量。假设，因为因为做活动，系统的瞬时请求量剧增，达到每秒 10000 个并发请求，数据库根本承受不了，可能直接就把数据库给整崩溃了，这样系统服务就不可用了。

如果使用 MQ，每秒写入 10000 条请求，但是系统 A 每秒只从 MQ 中消费 1000 条请求，然后写入数据库。这样，就不会超过数据库的承受能力，而是把请求积压在 MQ 中。只要高峰期一过，系统 A 就会很快把积压的消息给处理掉。

MQ 引入的问题

凡事有利有弊，使用 MQ 给系统带来很多好处，也会付出一定的代价。

它引入了以下问题：

• 系统可用性降低 - 引入了 MQ 后，通信需要基于 MQ 完成，如果 MQ 宕机，则服务不可用。因此，MQ 要保证是高可用的，详情参考：MQ 的高可用
• 系统复杂度提高 - 使用 MQ，需要关注一些新的问题：
  • 如何保证消息没有重复消费？
  • 如何处理消息丢失的问题？
  • 如何保证消息传递的顺序性？
  • 如何处理大量消息积压的问题？
• 一致性问题 - 假设系统 A 处理完直接返回成功的结果给用户，用户认为请求成功。但如果此时，系统 BCD 中只要有任意一个写库失败，那么数据就不一致了。这种情况如何处理？

重复消费

如何保证消息不被重复消费 和 如何保证消息消费的幂等性 是同一个问题。

必须先明确产生重复消费的原因，才能对症下药。

重复消费问题原因

重复消费问题通常不是 MQ 来处理，而是由开发来处理的。

以 Kafka 举例：Kafka 每个 Partition 都是一个有序的、不可变的记录序列，不断追加到结构化的提交日志中。Partition 中的记录每个分配一个连续的 id 号，称为偏移量（Offset），用于唯一标识 Partition 内的每条记录。

Kafka 的客户端和 Broker 都会保存 Offset。客户端消费消息后，每隔一段时间，就把已消费的 Offset 提交给 Kafka Broker，表示已消费。

在这个过程中，如果客户端应用消费消息后，因为宕机、重启等情况而没有提交已消费的 Offset 。当系统恢复后，会继续消费消息，由于 Offset 未提交，就会出现重复消费的问题。

重复消费解决方案

应对重复消费问题，就要通过幂等性来解决。

这个问题可以从业务层面来解决。

MQ 重复消费不可怕，可怕的是没有应对机制，可以借鉴的思路有：

• 如果是写库，可以先根据主键查询，判断数据是否已存在，存在则更新，不存在则插入；
• 如果是写 Redis，set 操作，由于天然具有幂等性，大可放心；
• 如果是根据消息做较复杂的逻辑处理，可以在消息中加入全局唯一 ID，例如：订单 ID 等。在客户端存储中（Mysql、Redis 等）保存已消费消息的 ID。一旦接受到新消息，先判断消息中的 ID 是否在已消费消息 ID 表中存在，存在则不再处理，不存在则处理。

消息丢失

如何处理消息丢失的问题 和 如何保证消息不被重复消费 是同一个问题。关注点有按个：

• Kafka 丢失数据
• 消费方丢失数据
• 生产方丢失数据

消费方丢失数据

唯一可能导致消费方丢失数据的情况，就是：消费方设置了自动提交 Offset。设置了自动提交 Offset，接受到消息后就会自动提交 Offset 给 Kafka ，Kafka 就认为消息已被消费。如果此时，消费方尚未来得及处理消息就挂了，那么消息就丢了。

解决方法就是消费方关闭自动提交 Offset，处理完消息后手动提交 Offset。但这种情况下可能会出现重复消费的情形，需要自行保证幂等性。

Kafka 丢失数据

当 Kafka 某个 Broker 宕机，需要重新选举 Partition 的 Leader。若此时其他的 Follower 尚未同步 Leader 的数据，那么新选某个 Follower 为 Leader 后，就丢失了部分数据。

为此，一般要求至少设置 4 个参数：

• 给 Topic 设置 replication.factor 参数 - 这个值必须大于 1，要求每个 Partition 必须有至少 2 个副本。
• 在 Kafka 服务端设置 min.insync.replicas 参数 - 这个值必须大于 1，这是要求一个 Leader 需要和至少一个 Follower 保持通信，这样才能确保 Leader 挂了还有替补。
• 在 Producer 端设置 acks=all - 这意味着：要求每条数据，必须是写入所有 replica 之后，才能认为是写成功了。
• 在 Producer 端设置 retries=MAX（很大很大很大的一个值，无限次重试的意思） - 这意味着要求一旦写入失败，就无限重试，卡在这里了。

生产方丢失数据

如果按照上述的思路设置了 acks=all，生产方一定不会丢数据。

要求是，你的 Leader 接收到消息，所有的 Follower 都同步到了消息之后，才认为本生产消息成功了。如果未满足这个条件，生产者会自动不断的重试，重试无限次。

消息的顺序性

以 Kafka 为例

要保证 MQ 的顺序性，势必要付出一定的代价，所以实施方案前，要先明确业务场景是不是有必要保证消息的顺序性。只有那些明确对消息处理顺序有要求的业务场景才值得去保证消息顺序性。

方案一

一个 Topic，一个 Partition，一个 Consumer，内部单线程消费，单线程吞吐量太低，一般不会用这个。

方案二

• 写入数据到 Partition 时指定一个唯一的 Key，例如订单 ID。由发送方保证相同 Key 的消息只能发送到同一个 Partition 并且这个 Partition 中的数据一定是顺序的。
• 基于上一点，消费方从 Kafka Partition 中消费消息时，此刻一定是顺序的。但如果消费方式以并发方式消费消息，顺序就可能会被打乱。为此，还有做到以下几点：
  • 消费方维护 N 个缓存队列，具有相同 key 的数据都写入同一个队列中；
  • 创建 N 个线程，每个线程只负责从指定的一个队列中取数据。

消息积压

假设一个 MQ 消费者可以一秒处理 1000 条消息，三个 MQ 消费者可以一秒处理 3000 条消息，那么一分钟的处理量是 18 万条。如果 MQ 中积压了几百万到上千万的数据，即使消费者恢复了，也需要大概很长的时间才能恢复过来。

对于产线环境来说，漫长的等待是不可接受的，所以面临这种窘境时，只能临时紧急扩容以应对了，具体操作步骤和思路如下：

• 先修复 Consumer 的问题，确保其恢复消费速度，然后将现有 Consumer 都停掉。
• 新建一个 Topic，Partition 是原来的 10 倍，临时建立好原先 10 倍的 Queue 数量。
• 然后写一个临时的分发数据的 Consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 Queue。
• 接着临时征用 10 倍的机器来部署 Consumer ，每一批 Consumer 消费一个临时 Queue 的数据。这种做法相当于是临时将 Queue 资源和 Consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
• 等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。

MQ 的高可用

不同 MQ 实现高可用的原理各不相同。因为 Kafka 比较具有代表性，所以这里以 Kafka 为例。

Kafka 的高可用

Kafka 的核心概念

了解 Kafka，必须先了解 Kafka 的核心概念：

• Broker - Kafka 集群包含一个或多个节点，这种节点被称为 Broker。

• Topic - 每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为 Topic。（不同 Topic 的消息是物理隔离的；同一个 Topic 的消息保存在一个或多个 Broker 上，但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处）。对于每一个 Topic， Kafka 集群都会维持一个分区日志。

• Partition - 了提高 Kafka 的吞吐率，每个 Topic 包含一个或多个 Partition，每个 Partition 在物理上对应一个文件夹，该文件夹下存储这个 Partition 的所有消息和索引文件。

  • Kafka 日志的分区（Partition）分布在 Kafka 集群的节点上。每个节点在处理数据和请求时，共享这些分区。每一个分区都会在已配置的节点上进行备份，确保容错性。

Kafka 的副本机制

Kafka 是如何实现高可用的呢？

Kafka 在 0.8 以前的版本中，如果一个 Broker 宕机了，其上面的 Partition 都不能用了，这自然不是高可用的。

为了实现高可用，Kafka 引入了复制功能。

简单来说，就是副本机制（ Replicate ）。

每个 Partition 都有一个 Broker 作为 Leader，零个或者多个 Broker 作为 Follower。每个 Broker 都会成为某些分区的 Leader 和某些分区的 Follower，因此集群的负载是平衡的。

• Leader 处理一切对 Partition （分区）的读写请求；
• 而 Follower 只需被动的同步 Leader 上的数据。

同一个 Topic 的不同 Partition 会分布在多个 Broker 上，而且一个 Partition 还会在其他的 Broker 上面进行备份，Producer 在发布消息到某个 Partition 时，先找到该 Partition 的 Leader，然后向这个 Leader 推送消息；每个 Follower 都从 Leader 拉取消息，拉取消息成功之后，向 Leader 发送一个 ACK 确认。

FAQ

问：为什么让 Leader 处理一切对对 Partition （分区）的读写请求？

答：因为如果允许所有 Broker 都可以处理读写请求，就可能产生数据一致性问题。

Kafka 选举 Leader

由上文可知，Partition 在多个 Broker 上存在副本。

如果某个 Follower 宕机，啥事儿没有，正常工作。

如果 Leader 宕机了，会从 Follower 中重新选举一个新的 Leader。

MQ 的通信模式

MQ 可驻留在内存或磁盘上，队列存储消息直到它们被应用程序读取。通过 MQ，应用程序可独立地执行，它们不需要知道彼此的位置，不需要等待接收程序接收此消息。在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。

• 点对点 - 点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。
• 多点广播 - MQ 适用于不同类型的应用。其中重要的，也是正在发展中的是”多点广播”应用，即能够将消息发送到多个目标站点 (Destination List)。可以使用一条 MQ 指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ 不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ 将消息的一个复制版本和该系统上接收者的名单发送到目标 MQ 系统。目标 MQ 系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。
• 发布/订阅 (Publish/Subscribe) - 发布/订阅模式使消息的分发可以突破目的队列地理位置的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅模式使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。
• 集群 (Cluster) - 为了简化点对点通讯模式中的系统配置，MQ 提供 Cluster(集群) 的解决方案。集群类似于一个域 (Domain)，集群内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用集群 (Cluster) 通道与其它成员通讯，从而大大简化了系统配置。此外，集群中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性。

常用 MQ 对比

综上，各种对比之后，有如下建议：

• 一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
• 后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
• 不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。
• 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
• 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

JMS

谈 MQ 就不得不提一下 JMS 。

JMS（JAVA Message Service，java 消息服务）API 是一个消息服务的标准/规范，允许应用程序组件基于 JavaEE 平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。

在 EJB 架构中，有消息 bean 可以无缝的与 JM 消息服务集成。在 J2EE 架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。

消息模型

在 JMS 标准中，有两种消息模型：

• P2P(Point to Point)
• Pub/Sub(Publish/Subscribe)

P2P 模式

P2P 的特点

• 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在 MQ 中)
• 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
• 接收者在成功接收消息之后需向队列应答成功

如果希望发送的每个消息都会被成功处理的话，那么需要 P2P 模式。

Pub/sub 模式

Pub/Sub 的特点

• 每个消息可以有多个消费者
• 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
• 为了消费消息，订阅者必须保持运行的状态。

为了缓和这样严格的时间相关性，JMS 允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。

如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用 Pub/Sub 模型。

消息消费

在 JMS 中，消息的产生和消费都是异步的。对于消费来说，JMS 的消息者可以通过两种方式来消费消息。

• 同步 - 订阅者或接收者通过 receive 方法来接收消息，receive 方法在接收到消息之前（或超时之前）将一直阻塞；
• 异步 - 订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的 onMessage 方法。

JNDI - Java 命名和目录接口,是一种标准的 Java 命名系统接口。可以在网络上查找和访问服务。通过指定一个资源名称，该名称对应于数据库或命名服务中的一个记录，同时返回资源连接建立所必须的信息。

JNDI 在 JMS 中起到查找和访问发送目标或消息来源的作用。

JMS 编程模型

ConnectionFactory

创建 Connection 对象的工厂，针对两种不同的 jms 消息模型，分别有 QueueConnectionFactory 和 TopicConnectionFactory 两种。可以通过 JNDI 来查找 ConnectionFactory 对象。

Destination

Destination 的意思是消息生产者的消息发送目标或者说消息消费者的消息来源。对于消息生产者来说，它的 Destination 是某个队列（Queue）或某个主题（Topic）;对于消息消费者来说，它的 Destination 也是某个队列或主题（即消息来源）。

所以，Destination 实际上就是两种类型的对象：Queue、Topic。可以通过 JNDI 来查找 Destination。

(3) Connection

Connection 表示在客户端和 JMS 系统之间建立的链接（对 TCP/IP socket 的包装）。Connection 可以产生一个或多个 Session。跟 ConnectionFactory 一样，Connection 也有两种类型：QueueConnection 和 TopicConnection。

(4) Session

Session 是操作消息的接口。可以通过 session 创建生产者、消费者、消息等。Session 提供了事务的功能。当需要使用 session 发送/接收多个消息时，可以将这些发送/接收动作放到一个事务中。同样，也分 QueueSession 和 TopicSession。

消息的生产者

消息生产者由 Session 创建，并用于将消息发送到 Destination。同样，消息生产者分两种类型：QueueSender 和 TopicPublisher。可以调用消息生产者的方法（send 或 publish 方法）发送消息。

消息消费者

消息消费者由 Session 创建，用于接收被发送到 Destination 的消息。两种类型：QueueReceiver 和 TopicSubscriber。可分别通过 session 的 createReceiver(Queue)或 createSubscriber(Topic)来创建。当然，也可以 session 的 creatDurableSubscriber 方法来创建持久化的订阅者。

MessageListener

消息监听器。如果注册了消息监听器，一旦消息到达，将自动调用监听器的 onMessage 方法。EJB 中的 MDB（Message-Driven Bean）就是一种 MessageListener。

深入学习 JMS 对掌握 JAVA 架构，EJB 架构有很好的帮助，消息中间件也是大型分布式系统必须的组件。本次分享主要做全局性介绍，具体的深入需要大家学习，实践，总结，领会。

参考资料

• 大型网站架构系列：分布式 MQ（一）
• 大型网站架构系列：MQ（二）
• 分布式开放 MQ(RocketMQ)的原理与实践
• 阿里 RocketMQ 优势对比
• advanced-java 之 MQ

缓存基本原理

📦 本文已归档到：「blog」

• 1. 缓存概述
  • 1.1. 什么是缓存
  • 1.2. 为什么引入缓存
  • 1.3. 缓存的基本原理
  • 1.4. 缓存淘汰算法
  • 1.5. 缓存的分类
  • 1.6. 缓存整体架构
• 2. CDN 缓存
  • 2.1. CDN 原理
  • 2.2. CDN 特点
• 3. 反向代理缓存
  • 3.1. 缓存原理
  • 3.2. 代理缓存比较
• 4. 进程内缓存
  • 4.1. ConcurrentHashMap
  • 4.2. LRUHashMap
  • 4.3. Guava Cache
  • 4.4. Caffeine
  • 4.5. 选择进程内缓存
• 5. 分布式缓存
  • 5.1. Memcache
  • 5.2. Redis
  • 5.3. 选择分布式缓存
• 6. 多级缓存
  • 6.1. 使用进程内缓存
  • 6.2. 使用分布式缓存
  • 6.3. 使用多级缓存
• 7. 缓存问题
  • 7.1. 缓存雪崩
  • 7.2. 缓存穿透
  • 7.3. 缓存击穿
  • 7.4. 缓存更新
  • 7.5. 缓存预热
  • 7.6. 缓存降级
• 参考资料

一、缓存简介

什么是缓存

缓存就是数据交换的缓冲区。

缓存是用于存储数据的硬件或软件的组成部分，以使得后续更快访问相应的数据。缓存中的数据可能是提前计算好的结果、数据的副本等。典型的应用场景：有 cpu cache, 磁盘 cache 等。本文中提及到缓存主要是指互联网应用中所使用的缓存组件。

为什么引入缓存

传统的后端业务场景中，访问量以及对响应时间的要求均不高，通常只使用数据库即可满足要求。这种架构简单，便于快速部署，很多网站发展初期均考虑使用这种架构。但是随着访问量的上升，以及对响应时间的要求提升，一个数据库服务已无法再满足要求。这时候通常会考虑数据库拆分(sharding)、读写分离、甚至硬件升级(SSD)等以满足新的业务需求。但是这种方式仍然会面临很多问题，主要体现在：

• 性能提升有限，很难达到数量级上的提升，尤其在互联网业务场景下，随着网站的发展，访问量经常会面临十倍、百倍的上涨。
• 成本高昂，为了承载 N 倍的访问量，通常需要 N 倍的机器，这个代价难以接受。

在数据层引入缓存，有以下几个好处：

• 提升数据读取速度。
• 提升系统扩展能力，通过扩展缓存，提升系统承载能力。
• 降低存储成本，Cache+DB 的方式可以承担原有需要多台 DB 才能承担的请求量，节省机器成本。

根据业务场景，通常缓存有以下几种使用方式：

• 懒汉式(读时触发)：写入 DB 后, 然后把相关的数据也写入 Cache。
• 饥饿式(写时触发)：先查询 DB 里的数据, 然后把相关的数据写入 Cache。
• 定期刷新：适合周期性的跑数据的任务，或者列表型的数据，而且不要求绝对实时性。

缓存的基本原理

1. 将数据写入/读取速度更快的存储（设备）；
2. 将数据缓存到离应用最近的位置；
3. 将数据缓存到离用户最近的位置。

缓存淘汰算法

常见的缓存淘汰算法有以下几种：

• FIFO - 先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰。这种可谓是最简单的了，但是会导致我们命中率很低。试想一下我们如果有个访问频率很高的数据是所有数据第一个访问的，而那些不是很高的是后面再访问的，那这样就会把我们的首个数据但是他的访问频率很高给挤出。
• LRU - 最近最少使用算法。在这种算法中避免了上面的问题，每次访问数据都会将其放在我们的队尾，如果需要淘汰数据，就只需要淘汰队首即可。但是这个依然有个问题，如果有个数据在 1 个小时的前 59 分钟访问了 1 万次(可见这是个热点数据),再后一分钟没有访问这个数据，但是有其他的数据访问，就导致了我们这个热点数据被淘汰。
• LFU - 最近最少频率使用。在这种算法中又对上面进行了优化，利用额外的空间记录每个数据的使用频率，然后选出频率最低进行淘汰。这样就避免了 LRU 不能处理时间段的问题。

这三种缓存淘汰算法，实现复杂度一个比一个高，同样的命中率也是一个比一个好。而我们一般来说选择的方案居中即可，即实现成本不是太高，而命中率也还行的 LRU。

缓存的分类

在分布式系统中，缓存的应用非常广泛，从部署角度有以下几个方面的缓存应用。

• CDN 缓存 - 存放 HTML、CSS、JS 等静态资源。
• 反向代理缓存 - 动静分离，只缓存用户请求的静态资源。
• 进程内缓存 - 缓存应用字典等常用数据。
• 分布式缓存 - 缓存数据库中的热点数据。

缓存整体架构

通常，网站的缓存整体架构如下图所示：

1. 浏览器向客户端发起请求，如果 CDN 有缓存则直接返回；
2. 如果 CDN 无缓存，则访问反向代理服务器；
3. 如果反向代理服务器有缓存则直接返回；
4. 如果反向代理服务器无缓存或动态请求，则访问应用服务器；
5. 应用服务器访问进程内缓存；如果有缓存，则返回代理服务器，并缓存数据；（动态请求不缓存）
6. 如果进程内缓存无数据，则读取分布式缓存；并返回应用服务器；应用服务器将数据缓存到本地缓存（部分）；
7. 如果分布式缓存无数据，则应用程序读取数据库数据，并放入分布式缓存；

二、CDN 缓存

CDN 将数据缓存到离用户物理距离最近的服务器，使得用户可以就近获取请求内容。CDN 一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。

国内网络异常复杂，跨运营商的网络访问会很慢。为了解决跨运营商或各地用户访问问题，可以在重要的城市，部署 CDN 应用。使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

CDN 的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

（1）未部署 CDN 应用前的网络路径：

• 请求：本机网络（局域网）=> 运营商网络 => 应用服务器机房
• 响应：应用服务器机房 => 运营商网络 => 本机网络（局域网）

在不考虑复杂网络的情况下，从请求到响应需要经过 3 个节点，6 个步骤完成一次用户访问操作。

（2）部署 CDN 应用后网络路径：

• 请求：本机网络（局域网） => 运营商网络
• 响应：运营商网络 => 本机网络（局域网）

在不考虑复杂网络的情况下，从请求到响应需要经过 2 个节点，2 个步骤完成一次用户访问操作。

与不部署 CDN 服务相比，减少了 1 个节点，4 个步骤的访问。极大的提高的系统的响应速度。

CDN 特点

• 优点
  • 本地 Cache 加速 - 提升访问速度，尤其含有大量图片和静态页面站点；
  • 镜像服务 - 消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量；
  • 远程加速 - 远程访问用户根据 DNS 负载均衡技术智能自动选择 Cache 服务器，选择最快的 Cache 服务器，加快远程访问的速度；
  • 带宽优化 - 自动生成服务器的远程 Mirror（镜像）cache 服务器，远程用户访问时从 cache 服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点 WEB 服务器负载等功能。
  • 集群抗攻击 - 广泛分布的 CDN 节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种 D.D.o.S 攻击对网站的影响，同时保证较好的服务质量。
• 缺点
  • 不适宜缓存动态资源
    • 解决方案：主要缓存静态资源，动态资源建立多级缓存或准实时同步；
  • 存在数据的一致性问题
    • 解决方案（主要是在性能和数据一致性二者间寻找一个平衡）
      • 设置缓存失效时间（1 个小时，过期后同步数据）。
      • 针对资源设置版本号。

三、反向代理缓存

反向代理（Reverse Proxy）方式是指以代理服务器来接受 internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

反向代理位于应用服务器同一网络，处理所有对 WEB 服务器的请求。

反向代理缓存的原理：

• 如果用户请求的页面在代理服务器上有缓存的话，代理服务器直接将缓存内容发送给用户。
• 如果没有缓存则先向 WEB 服务器发出请求，取回数据，本地缓存后再发送给用户。

这种方式通过降低向 WEB 服务器的请求数，从而降低了 WEB 服务器的负载。

反向代理缓存一般针对的是静态资源，而将动态资源请求转发到应用服务器处理。常用的缓存应用服务器有 Varnish，Ngnix，Squid。

代理缓存比较

常用的代理缓存有 Varnish，Squid，Ngnix，简单比较如下：

• Varnish 和 Squid 是专业的 cache 服务，Ngnix 需要第三方模块支持；
• Varnish 采用内存型缓存，避免了频繁在内存、磁盘中交换文件，性能比 Squid 高；
• Varnish 由于是内存 cache，所以对小文件如 css、js、小图片的支持很棒，后端的持久化缓存可以采用的是 Squid 或 ATS；
• Squid 功能全而大，适合于各种静态的文件缓存，一般会在前端挂一个 HAProxy 或 Ngnix 做负载均衡跑多个实例；
• Nginx 采用第三方模块 ncache 做的缓冲，性能基本达到 Varnish，一般作为反向代理使用，可以实现简单的缓存。

四、进程内缓存

进程内缓存是指应用内部的缓存，标准的分布式系统，一般有多级缓存构成。本地缓存是离应用最近的缓存，一般可以将数据缓存到硬盘或内存。

• 硬盘缓存 - 将数据缓存到硬盘到，读取时从硬盘读取。原理是直接读取本机文件，减少了网络传输消耗，比通过网络读取数据库速度更快。可以应用在对速度要求不是很高，但需要大量缓存存储的场景。
• 内存缓存 - 直接将数据存储到本机内存中，通过程序直接维护缓存对象，是访问速度最快的方式。

常见的本地缓存实现方案：HashMap、Guava Cache、Caffeine、Ehcache。

ConcurrentHashMap

最简单的进程内缓存可以通过 JDK 自带的 HashMap 或 ConcurrentHashMap 实现。

适用场景：不需要淘汰的缓存数据。

缺点：无法进行缓存淘汰，内存会无限制的增长。

LRUHashMap

可以通过继承 LinkedHashMap 来实现一个简单的 LRUHashMap。重写 removeEldestEntry 方法，即可完成一个简单的最近最少使用算法。

• 缺点：
  • 锁竞争严重，性能比较低。
  • 不支持过期时间
  • 不支持自动刷新

Guava Cache

解决了 LRUHashMap 中的几个缺点。

Guava Cache 采用了类似 ConcurrentHashMap 的思想，分段加锁，减少锁竞争。

Guava Cache 对于过期的 Entry 并没有马上过期(也就是并没有后台线程一直在扫)，而是通过进行读写操作的时候进行过期处理，这样做的好处是避免后台线程扫描的时候进行全局加锁。

直接通过查询，判断其是否满足刷新条件，进行刷新。

Caffeine

Caffeine 实现了 W-TinyLFU(LFU+LRU 算法的变种)，其命中率和读写吞吐量大大优于 Guava Cache。

其实现原理较复杂，可以参考你应该知道的缓存进化史。

选择进程内缓存

常用进程内缓存技术对比：

• ConcurrentHashMap - 比较适合缓存比较固定不变的元素，且缓存的数量较小的。虽然从上面表格中比起来有点逊色，但是其由于是 JDK 自带的类，在各种框架中依然有大量的使用，比如我们可以用来缓存我们反射的 Method，Field 等等；也可以缓存一些链接，防止其重复建立。在 Caffeine 中也是使用的 ConcurrentHashMap 来存储元素。
• LRUMap - 如果不想引入第三方包，又想使用淘汰算法淘汰数据，可以使用这个。
• Ehcache - 由于其 jar 包很大，较重量级。对于需要持久化和集群的一些功能的，可以选择 Ehcache。需要注意的是，虽然 Ehcache 也支持分布式缓存，但是由于其节点间通信方式为 rmi，表现不如 Redis，所以一般不建议用它来作为分布式缓存。
• Guava Cache - Guava 这个 jar 包在很多 Java 应用程序中都有大量的引入，所以很多时候其实是直接用就好了，并且其本身是轻量级的而且功能较为丰富，在不了解 Caffeine 的情况下可以选择 Guava Cache。
• Caffeine - 其在命中率，读写性能上都比 Guava Cache 好很多，并且其 API 和 Guava cache 基本一致，甚至会多一点。在真实环境中使用 Caffeine，取得过不错的效果。

总结一下：如果不需要淘汰算法则选择 ConcurrentHashMap，如果需要淘汰算法和一些丰富的 API，推荐选择 Caffeine。

五、分布式缓存

分布式缓存解决了进程内缓存最大的问题：如果应用是分布式系统，节点之间无法共享彼此的进程内缓存。

分布式缓存的应用场景：

• 缓存经过复杂计算得到的数据
• 缓存系统中频繁访问的热点数据，减轻数据库压力

不同分布式缓存的实现原理往往有比较大的差异。本文主要针对 Memcached 和 Redis 进行说明。

Memcache

Memcache 是一个高性能，分布式内存对象缓存系统，通过在内存里维护一个统一的巨大的 hash 表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。

简单的说就是：将数据缓存到内存中，然后从内存中读取，从而大大提高读取速度。

Memcache 特性

• 使用物理内存作为缓存区，可独立运行在服务器上。每个进程最大 2G，如果想缓存更多的数据，可以开辟更多的 Memcache 进程（不同端口）或者使用分布式 Memcache 进行缓存，将数据缓存到不同的物理机或者虚拟机上。
• 使用 key-value 的方式来存储数据。这是一种单索引的结构化数据组织形式，可使数据项查询时间复杂度为 O(1)。
• 协议简单，基于文本行的协议。直接通过 telnet 在 Memcached 服务器上可进行存取数据操作，简单，方便多种缓存参考此协议；
• 基于 libevent 高性能通信。Libevent 是一套利用 C 开发的程序库，它将 BSD 系统的 kqueue,Linux 系统的 epoll 等事件处理功能封装成一个接口，与传统的 select 相比，提高了性能。
• 分布式能力取决于 Memcache 客户端，服务器之间互不通信。各个 Memcached 服务器之间互不通信，各自独立存取数据，不共享任何信息。服务器并不具有分布式功能，分布式部署取决于 Memcached 客户端。
• 采用 LRU 缓存淘汰策略。在 Memcached 内存储数据项时，可以指定它在缓存的失效时间，默认为永久。当 Memcached 服务器用完分配的内时，失效的数据被首先替换，然后也是最近未使用的数据。在 LRU 中，Memcached 使用的是一种 Lazy Expiration 策略，自己不会监控存入的 key/vlue 对是否过期，而是在获取 key 值时查看记录的时间戳，检查 key/value 对空间是否过期，这样可减轻服务器的负载。
• 内置了一套高效的内存管理算法。这套内存管理效率很高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。当内存满后，通过 LRU 算法自动删除不使用的缓存。
• 不支持持久化。Memcached 没有考虑数据的容灾问题，重启服务，所有数据会丢失。

Memcache 工作原理

（1）内存管理

Memcached 利用 slab allocation 机制来分配和管理内存，它按照预先规定的大小，将分配的内存分割成特定长度的内存块，再把尺寸相同的内存块分成组，数据在存放时，根据键值 大小去匹配 slab 大小，找就近的 slab 存放，所以存在空间浪费现象。

这套内存管理效率很高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。

（2）缓存淘汰策略

Memcached 的缓存淘汰策略是 LRU + 到期失效策略。

当你在 Memcached 内存储数据项时，你有可能会指定它在缓存的失效时间，默认为永久。当 Memcached 服务器用完分配的内时，失效的数据被首先替换，然后是最近未使用的数据。

在 LRU 中，Memcached 使用的是一种 Lazy Expiration 策略：Memcached 不会监控存入的 key/vlue 对是否过期，而是在获取 key 值时查看记录的时间戳，检查 key/value 对空间是否过期，这样可减轻服务器的负载。

（3）分区

Memcached 服务器之间彼此不通信，它的分布式能力是依赖客户端来实现。

具体来说，就是在客户端实现一种算法，根据 key 来计算出数据应该向哪个服务器节点读/写。

而这种选取集群节点的算法常见的有三种：

• 哈希取余算法 - 使用公式：hash（key）% N 计算出 哈希值 来决定数据映射到哪一个节点。
• 一致性哈希算法 - 可以很好的解决 稳定性问题，可以将所有的 存储节点 排列在 首尾相接 的 Hash 环上，每个 key 在计算 Hash 后会 顺时针 找到 临接 的 存储节点 存放。而当有节点 加入 或 退出 时，仅影响该节点在 Hash 环上 顺时针相邻 的 后续节点。
• 虚拟 Hash 槽算法 - 使用 分散度良好 的 哈希函数 把所有数据 映射 到一个 固定范围 的 整数集合 中，整数定义为 槽（slot），这个范围一般 远远大于 节点数。槽 是集群内 数据管理 和 迁移 的 基本单位。采用 大范围槽 的主要目的是为了方便 数据拆分 和 集群扩展。每个节点会负责 一定数量的槽。

Redis

Redis 是一个开源（BSD 许可）的，基于内存的，多数据结构存储系统。可以用作数据库、缓存和消息中间件。

Redis 还可以使用客户端分片来扩展写性能。内置了 复制（replication），LUA 脚本（Lua scripting），LRU 驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis 哨兵（Sentinel）和自动分区（Cluster）提供高可用性（high availability）。

Redis 特性

• 支持多种数据类型 - string、hash、list、set、sorted set。

• 支持多种数据淘汰策略

  • volatile-lru - 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
  • volatile-ttl - 从已设置过期时间的数据集中挑选将要过期的数据淘汰
  • volatile-random - 从已设置过期时间的数据集中任意选择数据淘汰
  • allkeys-lru - 从所有数据集中挑选最近最少使用的数据淘汰
  • allkeys-random - 从所有数据集中任意选择数据进行淘汰
  • noeviction - 禁止驱逐数据

• 提供两种持久化方式 - RDB 和 AOF

• 通过 Redis cluster 提供集群模式。

Redis 原理

• 缓存淘汰
  • Redis 有两种数据淘汰实现
    • 消极方式 - 访问 Redis key 时，如果发现它已经失效，则删除它
    • 积极方式 - 周期性从设置了失效时间的 key 中，根据淘汰策略，选择一部分失效的 key 进行删除。
• 分区
  • Redis Cluster 集群包含 16384 个虚拟 Hash 槽，它通过一个高效的算法来计算 key 属于哪个 Hash 槽。
  • Redis Cluster 支持请求分发 - 节点在接到一个命令请求时，会先检测这个命令请求要处理的键所在的槽是否由自己负责，如果不是的话，节点将向客户端返回一个 MOVED 错误，MOVED 错误携带的信息可以指引客户端将请求重定向至正在负责相关槽的节点。
• 主从复制
  • Redis 2.8 后支持异步复制。它有两种模式：
    • 完整重同步（full resychronization） - 用于初次复制。执行步骤与 SYNC 命令基本一致。
    • 部分重同步（partial resychronization） - 用于断线后重复制。如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只需接收并执行这些写命令，即可将主从服务器的数据库状态保持一致。
  • 集群中每个节点都会定期向集群中的其他节点发送 PING 消息，以此来检测对方是否在线。
  • 如果一个主节点被认为下线，则在其从节点中，根据 Raft 算法，选举出一个节点，升级为主节点。
• 数据一致性
  • Redis 不保证强一致性，因为这会使得集群性能大大降低。
  • Redis 是通过异步复制来实现最终一致性。

选择分布式缓存

不同的分布式缓存功能特性和实现原理方面有很大的差异，因此他们所适应的场景也有所不同。

这里选取三个比较出名的分布式缓存（MemCache，Redis，Tair）来作为比较：

• MemCache - 这一块接触得比较少，不做过多的推荐。其吞吐量较大，但是支持的数据结构较少，并且不支持持久化。
• Redis - 支持丰富的数据结构，读写性能很高，但是数据全内存，必须要考虑资源成本，支持持久化。
• Tair - 支持丰富的数据结构，读写性能较高，部分类型比较慢，理论上容量可以无限扩充。

总结：如果服务对延迟比较敏感，Map/Set 数据也比较多的话，比较适合 Redis。如果服务需要放入缓存量的数据很大，对延迟又不是特别敏感的话，那就可以选择 Tair。

六、多级缓存

使用进程内缓存

如果应用服务不是分布式系统，那么进程内缓存当然是缓存的首选方案。

对于进程内缓存，其本来受限于内存的大小的限制，以及进程缓存更新后其他缓存无法得知，所以一般来说进程缓存适用于:

1. 数据量不是很大且更新频率较低的数据。
2. 如果更新频繁的数据，也想使用进程内缓存，那么可以将其过期时间设置为较短的时间，或者设置较短的自动刷新时间。

这种方案存在以下问题：

• 如果应用服务是分布式系统，应用节点之间无法共享缓存，存在数据不一致问题。
• 由于进程内缓存受限于内存大小的限制，所以缓存不能无限扩展。

使用分布式缓存

如果应用服务是分布式系统，那么最简单的缓存方案就是直接使用分布式缓存。

其应用场景如图所示：

这种方案存在以下问题：

1. 缓存服务如果挂了，这时应用只能访问数据库，容易造成缓存雪崩。
2. 访问分布式缓存服务会有一定的 I/O 以及序列化反序列化的开销，虽然性能很高，但是其终究没有在内存中查询快。

使用多级缓存

单纯使用进程内缓存和分布式缓存都存在各自的不足。如果需要更高的性能以及更好的可用性，我们可以将缓存设计为多级结构。将最热的数据使用进程内缓存存储在内存中，进一步提升访问速度。

这个设计思路在计算机系统中也存在，比如 CPU 使用 L1、L2、L3 多级缓存，用来减少对内存的直接访问，从而加快访问速度。

一般来说，多级缓存架构使用二级缓存已可以满足大部分业务需求，过多的分级会增加系统的复杂度以及维护的成本。因此，多级缓存不是分级越多越好，需要根据实际情况进行权衡。

一个典型的二级缓存架构，可以使用进程内缓存（如： Caffeine/Google Guava/Ehcache/HashMap）作为一级缓存；使用分布式缓存（如：Redis/Memcached）作为二级缓存。

多级缓存查询

1. 首先，查询 L1 缓存，如果缓存命中，直接返回结果；如果没有命中，执行下一步。
2. 接下来，查询 L2 缓存，如果缓存命中，直接返回结果并回填 L1 缓存；如果没有命中，执行下一步。
3. 最后，查询数据库，返回结果并依次回填 L2 缓存、L1 缓存。

多级缓存更新

对于 L1 缓存，如果有数据更新，只能删除并更新所在机器上的缓存，其他机器只能通过超时机制来刷新缓存。超时设定可以有两种策略:

• 设置成写入后多少时间后过期
• 设置成写入后多少时间刷新

对于 L1 缓存，如果有数据更新，其他机器立马可见。但是，也必须要设置超时时间，其时间应该比 L1 缓存的有效时间长。

为了解决进程内缓存不一致的问题，设计可以进一步优化:

七、缓存问题

缓存雪崩

缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接访问数据库，数据库压力过大导致系统雪崩。

举例来说，对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。

缓存雪崩的事前事中事后的解决方案如下：

• 事前：Redis 高可用，使用 Redis Cluster（主从+哨兵），避免全盘崩溃。
• 事中：本地缓存（Ehcache/Caffine/Google Cache） + Hystrix 限流&降级，避免数据库崩溃。
• 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

上面的解决方案简单来说，就是多级缓存方案。系统收到一个查询请求，先查本地缓存，再查分布式缓存，最后查数据库，只要命中，立即返回。

辅助性手段：

• 通过监控关注缓存的健康程度，根据业务量适当的扩容缓存。
• 缓存的过期时间可以取个随机值。比如以前是设置 10 分钟的超时时间，那每个 Key 都可以随机 8-13 分钟过期，尽量让不同 Key 的过期时间不同。

缓存穿透

缓存穿透是指：查询的数据在数据库中不存在，那么缓存中自然也不存在。所以，应用在缓存中查不到，则会去查询数据库。当这样的请求多了后，数据库的压力就会增大。

解决缓存穿透，一般有两种方法：

• 对于返回为 NULL 的依然缓存，对于抛出异常的返回不进行缓存。

• 过滤不可能存在的数据

缓存击穿

缓存击穿是指，某些 key 是热点数据，访问非常频繁。如果某个 key 失效的瞬间，大量的请求过来，缓存未命中，然后去数据库访问，此时数据库访问量会急剧增加。

为了避免这个问题，我们可以采取下面的两个手段:

• 分布式锁 - 锁住热点数据的 key，避免大量线程同时访问同一个 key。
• 异步加载 - 可以对部分数据采取到期自动刷新的策略，而不是到期自动淘汰。淘汰其实也是为了数据的时效性，所以采用自动刷新也可以。

缓存更新

一般来说，系统如果不是严格要求缓存和数据库保持一致性的话，尽量不要将读请求和写请求串行化。串行化可以保证一定不会出现数据不一致的情况，但是它会导致系统的吞吐量大幅度下降。

一般来说缓存的更新有两种情况:

• 先删除缓存，再更新数据库。
• 先更新数据库，再删除缓存。

为什么是删除缓存，而不是更新缓存呢？

你可以想想当有多个并发的请求更新数据，你并不能保证更新数据库的顺序和更新缓存的顺序一致，那就会出现数据库中和缓存中数据不一致的情况。所以一般来说考虑删除缓存。

• 先删除缓存，再更新数据库

对于一个更新操作简单来说，就是先去各级缓存进行删除，然后更新数据库。

这个操作有一个比较大的问题，在对缓存删除完之后，有一个读请求，这个时候由于缓存被删除所以直接会读库，读操作的数据是老的并且会被加载进入缓存当中，后续读请求全部访问的老数据。

先删除缓存也有一个好处是，如果对数据库操作失败了，那么由于先删除的缓存，最多只是造成 Cache Miss。

• 先更新数据库，再删除缓存

注：更推荐使用这种策略

如果我们使用更新数据库，再删除缓存就能避免上面的问题。

但是同样的引入了新的问题：假设执行更新操作时，又接收到查询请求，此时就会返回缓存中的老数据。更麻烦的是，如果数据库更新操作执行失败，则缓存中可能永远是脏数据。

• 应该选择哪种更新策略

通过上面的内容，我们知道，两种更新策略都存在并发问题。

但是建议选择先更新数据库，再删除缓存，因为其并发问题出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且同时有一个并发写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

如果需要数据库和缓存保证强一致性，则可以通过 2PC 或 Paxos 协议来实现。但是 2PC 太慢，而 Paxos 太复杂，所以如果不是非常重要的数据，不建议使用强一致性方案。

缓存预热

缓存预热是指系统启动后，将常用的数据直接缓存。这样就可以避免用户请求的时候，先查询数据库，然后再更新缓存的问题。

解决方案：

• 直接写个缓存刷新页面，上线时手工操作下。
• 数据量不大，可以在项目启动的时候自动进行加载。
• 定时刷新缓存。

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

参考资料

• 《大型网站技术架构：核心原理与案例分析》
• 你应该知道的缓存进化史
• 如何优雅的设计和使用缓存？
• 理解分布式系统中的缓存架构(上)

分布式事务基本原理

📦 本文已归档到：「blog」

分布式事务指的是事务操作跨越多个节点，并且要求满足事务的 ACID 特性。

• 一、分布式事务简介
  • 本地事务
  • 分布式事务
  • 分布式事务的难点
  • CAP 和 BASE
  • 柔性事务
• 二、两阶段提交
  • 方案简介
  • 处理流程
  • 方案总结
• 三、三阶段提交
  • 方案简介
  • 处理流程
  • 方案总结
• 四、补偿事务
  • 方案简介
  • 处理流程
  • 方案总结
• 五、本地消息表
  • 方案简介
  • 处理流程
  • 方案总结
• 六、MQ 事务
  • 方案简介
  • 处理流程
  • 方案总结
• 七、SAGA
  • 方案简介
  • 处理流程
  • 方案总结
• 总结
  • 各方案使用场景
  • 分布式事务方案设计
• 参考资料

一、分布式事务简介

本地事务

学习分布式之前，先了解一下本地事务的概念。

事务简单来说：一个会话中所进行所有的操作，要么同时成功，要么同时失败。

具体来说，事务指的是满足 ACID 特性的一组操作，可以通过 Commit 提交一个事务，也可以使用 Rollback 进行回滚。

• 原子性（Atomicity）
• 一致性（Consistency）
• 隔离性（Isolation）
• 持久性（Durability）

💡 更详细的内容可以参考：事务

分布式事务

分布式事务指的是事务操作跨越多个节点，并且要求满足事务的 ACID 特性。

随着互联网快速发展，微服务，SOA 等服务架构模式正在被大规模的使用，现在分布式系统一般由多个独立的子系统组成，多个子系统通过网络通信互相协作配合完成各个功能。

有很多用例会跨多个子系统才能完成，比较典型的是电子商务网站的下单支付流程，至少会涉及交易系统和支付系统，而且这个过程中会涉及到事务的概念，即保证交易系统和支付系统的数据一致性，此处我们称这种跨系统的事务为分布式事务，具体一点而言，分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

举个互联网常用的交易业务为例：

上图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库。在交易系统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服务，创建订单记录。

可以看到，如果多个数据库之间的数据更新没有保证事务，将会导致出现子系统数据不一致，业务出现问题。

分布式事务的难点

• 事务的原子性 事务操作跨不同节点，当多个节点某一节点操作失败时，需要保证多节点操作的都做或都不做（All or Nothing）的原子性。
• 事务的一致性 当发生网络传输故障或者节点故障，节点间数据复制通道中断，在进行事务操作时需要保证数据一致性，保证事务的任何操作都不会使得数据违反数据库定义的约束、触发器等规则。
• 事务的隔离性 事务隔离性的本质就是如何正确多个并发事务的处理的读写冲突和写写冲突，因为在分布式事务控制中，可能会出现提交不同步的现象，这个时候就有可能出现“部分已经提交”的事务。此时并发应用访问数据如果没有加以控制，有可能出现“脏读”问题。

CAP 和 BASE

CAP 定理又称为 CAP 原则，指的是：在一个分布式系统中， 一致性（C：Consistency）、可用性（A：Availability） 和 分区容忍性（P：Partition Tolerance），最多只能同时满足其中两项。

BASE 是 基本可用（Basically Available）、软状态（Soft State） 和 最终一致性（Eventually Consistent） 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，它的理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

💡 更详细的内容可以参考：分布式基础理论

柔性事务

柔性事务的概念

在电商等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于 CAP 理论以及 BASE 理论，有人就提出了柔性事务的概念。

基于 BASE 理论的设计思想，柔性事务下，在不影响系统整体可用性的情况下(Basically Available 基本可用)，允许系统存在数据不一致的中间状态(Soft State 软状态)，在经过数据同步的延时之后，最终数据能够达到一致。并不是完全放弃了 ACID，而是通过放宽一致性要求，借助本地事务来实现最终分布式事务一致性的同时也保证系统的吞吐。

柔性事务的特性

下面介绍的是实现柔性事务的一些常见特性，这些特性在具体的方案中不一定都要满足，因为不同的方案要求不一样。

可见性(对外可查询) 在分布式事务执行过程中，如果某一个步骤执行出错，就需要明确的知道其他几个操作的处理情况，这就需要其他的服务都能够提供查询接口，保证可以通过查询来判断操作的处理情况。

为了保证操作的可查询，需要对于每一个服务的每一次调用都有一个全局唯一的标识，可以是业务单据号（如订单号）、也可以是系统分配的操作流水号（如支付记录流水号）。除此之外，操作的时间信息也要有完整的记录。

操作幂等性 幂等性，其实是一个数学概念。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。也就是说，同一个方法，使用同样的参数，调用多次产生的业务结果与调用一次产生的业务结果相同。

之所以需要操作幂等性，是因为为了保证数据的最终一致性，很多事务协议都会有很多重试的操作，如果一个方法不保证幂等，那么将无法被重试。幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。

二、两阶段提交

方案简介

二阶段提交协议（Two-phase Commit，即 2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。

在分布式系统里，每个节点都可以知晓自己操作的成功或者失败，却无法知道其他节点操作的成功或失败。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚（rollback）。

二阶段提交的思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。

处理流程

简单一点理解，可以把协调者节点比喻为带头大哥，参与者理解比喻为跟班小弟，带头大哥统一协调跟班小弟的任务执行。

阶段 1：准备阶段

1. 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
2. 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
3. 如参与者执行成功，给协调者反馈 yes，即可以提交；如执行失败，给协调者反馈 no，即不可提交。

阶段 2：提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源) 接下来分两种情况分别讨论提交阶段的过程。

情况 1，当所有参与者均反馈 yes，提交事务：

1. 协调者向所有参与者发出正式提交事务的请求（即 commit 请求）。
2. 参与者执行 commit 请求，并释放整个事务期间占用的资源。
3. 各参与者向协调者反馈 ack(应答)完成的消息。
4. 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况 2，当任何阶段 1 一个参与者反馈 no，中断事务：

1. 协调者向所有参与者发出回滚请求（即 rollback 请求）。
2. 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。
3. 各参与者向协调者反馈 ack 完成的消息。
4. 协调者收到所有参与者反馈的 ack 消息后，即完成事务中断。

方案总结

2PC 方案实现起来简单，实际项目中使用比较少，主要因为以下问题：

• 性能问题 - 所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
• 可靠性问题 - 如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。
• 数据一致性问题 - 在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

三、三阶段提交

方案简介

三阶段提交协议（Three-phase Commit，3PC），是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制。

三阶段提交将二阶段的准备阶段拆分为 2 个阶段，插入了一个 preCommit 阶段，使得原先在二阶段提交中，参与者在准备之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。

处理流程

阶段 1：canCommit

协调者向参与者发送 commit 请求，参与者如果可以提交就返回 yes 响应(参与者不执行事务操作)，否则返回 no 响应：

1. 协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
2. 参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段 2：preCommit

协调者根据阶段 1 canCommit 参与者的反应情况来决定是否可以基于事务的 preCommit 操作。根据响应情况，有以下两种可能。

情况 1：阶段 1 所有参与者均反馈 yes，参与者预执行事务：

1. 协调者向所有参与者发出 preCommit 请求，进入准备阶段。
2. 参与者收到 preCommit 请求后，执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
3. 各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。

情况 2：阶段 1 任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务:

1. 协调者向所有参与者发出 abort 请求。
2. 无论收到协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段 3：doCommit

该阶段进行真正的事务提交，也可以分为以下两种情况：

情况 1：阶段 2 所有参与者均反馈 ack 响应，执行真正的事务提交：

1. 如果协调者处于工作状态，则向所有参与者发出 do Commit 请求。
2. 参与者收到 do Commit 请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
3. 各参与者向协调者反馈 ack 完成的消息。
4. 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

阶段 2 任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务：

1. 如果协调者处于工作状态，向所有参与者发出 abort 请求。
2. 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。
3. 各参与者向协调者反馈 ack 完成的消息。
4. 协调者收到所有参与者反馈的 ack 消息后，即完成事务中断。

注意：进入阶段 3 后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的 do Commit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。

方案总结

优点：

• 相比二阶段提交，三阶段降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段 3 中协调者出现问题时，参与者会继续提交事务。

缺点：

• 数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

四、补偿事务

方案简介

TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC 是服务化的二阶段编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现；

• Try - 操作作为一阶段，负责资源的检查和预留。
• Confirm - 操作作为二阶段提交操作，执行真正的业务。
• Cancel - 是预留资源的取消。

TCC 事务的 Try、Confirm、Cancel 可以理解为 SQL 事务中的 Lock、Commit、Rollback。

处理流程

为了方便理解，下面以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建 2 个步骤，库存服务和订单服务分别在不同的服务器节点上。

Try 阶段

从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC 机制中的 Try 仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：

• 完成所有业务检查( 一致性 )
• 预留必须业务资源( 准隔离性 )
• Try 尝试执行业务 TCC 事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try 阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。

假设商品库存为 100，购买数量为 2，这里检查和更新库存的同时，冻结用户购买数量的库存，同时创建订单，订单状态为待确认。

Confirm / Cancel 阶段

根据 Try 阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。 Confirm 和 Cancel 操作满足幂等性，如果 Confirm 或 Cancel 操作执行失败，将会不断重试直到执行完成。

Confirm：当 Try 阶段服务全部正常执行， 执行确认业务逻辑操作

这里使用的资源一定是 Try 阶段预留的业务资源。在 TCC 事务机制中认为，如果在 Try 阶段能正常的预留资源，那 Confirm 一定能完整正确的提交。Confirm 阶段也可以看成是对 Try 阶段的一个补充，Try+Confirm 一起组成了一个完整的业务逻辑。

Cancel：当 Try 阶段存在服务执行失败， 进入 Cancel 阶段

Cancel 取消执行，释放 Try 阶段预留的业务资源，上面的例子中，Cancel 操作会把冻结的库存释放，并更新订单状态为取消。

方案总结

TCC 事务机制相对于传统事务机制（X/Open XA），TCC 事务机制相比于上面介绍的 XA 事务机制，有以下优点:

• 性能提升 - 具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。
• 数据最终一致性 - 基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。
• 可靠性 - 解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

缺点： TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。

五、本地消息表

方案简介

本地消息表的方案最初是由 ebay 提出，核心思路是将分布式事务拆分成本地事务进行处理。

方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。

这样设计可以避免”业务处理成功 + 事务消息发送失败“，或”业务处理失败 + 事务消息发送成功“的棘手情况出现，保证 2 个系统事务的数据一致性。

处理流程

下面把分布式事务最先开始处理的事务方成为事务主动方，在事务主动方之后处理的业务内的其他事务成为事务被动方。

为了方便理解，下面继续以电商下单为例进行方案解析，这里把整个过程简单分为扣减库存，订单创建 2 个步骤，库存服务和订单服务分别在不同的服务器节点上，其中库存服务是事务主动方，订单服务是事务被动方。

事务的主动方需要额外新建事务消息表，用于记录分布式事务的消息的发生、处理状态。

整个业务处理流程如下：

1. 步骤 1 事务主动方处理本地事务。 事务主动发在本地事务中处理业务更新操作和写消息表操作。 上面例子中库存服务阶段再本地事务中完成扣减库存和写消息表(图中 1、2)。
2. 步骤 2 事务主动方通过 MQ 通知事务被动方处理事务。 消息中间件可以基于 Kafka、RocketMQ 消息队列，事务主动方法主动写消息到消息队列，事务消费方消费并处理消息队列中的消息。 上面例子中，库存服务把事务待处理消息写到消息中间件，订单服务消费消息中间件的消息，完成新增订单（图中 3 - 5）。
3. 步骤 3 事务被动方通过 MQ 反会处理结果。 上面例子中，订单服务把事务已处理消息写到消息中间件，库存服务消费中间件的消息，并将事务消息的状态更新为已完成(图中 6 - 8)

为了数据的一致性，当处理错误需要重试，事务发送方和事务接收方相关业务处理需要支持幂等。具体保存一致性的容错处理如下：

• 当步骤 1 处理出错，事务回滚，相当于什么都没发生。
• 当步骤 2、步骤 3 处理出错，由于未处理的事务消息还是保存在事务发送方，事务发送方可以定时轮询为超时消息数据，再次发送的消息中间件进行处理。事务被动方消费事务消息重试处理。
• 如果是业务上的失败，事务被动方可以发消息给事务主动方进行回滚。
• 如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚。

方案总结

方案的优点如下：

• 从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖。
• 方案轻量，容易实现。

缺点如下：

• 与具体的业务场景绑定，耦合性强，不可复用。
• 消息数据与业务数据同库，占用业务系统资源。
• 业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。

六、MQ 事务

方案简介

基于 MQ 的分布式事务方案其实是对本地消息表的封装，将本地消息表基于 MQ 内部，其他方面的协议基本与本地消息表一致。

处理流程

下面主要基于 RocketMQ4.3 之后的版本介绍 MQ 的分布式事务方案。

在本地消息表方案中，保证事务主动方发写业务表数据和写消息表数据的一致性是基于数据库事务，RocketMQ 的事务消息相对于普通 MQ，相对于提供了 2PC 的提交接口，方案如下：

正常情况——事务主动方发消息 这种情况下，事务主动方服务正常，没有发生故障，发消息流程如下：

1. 发送方向 MQ 服务端(MQ Server)发送 half 消息。
2. MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功。
3. 发送方开始执行本地事务逻辑。
4. 发送方根据本地事务执行结果向 MQ Server 提交二次确认（commit 或是 rollback）。
5. MQ Server 收到 commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 rollback 状态则删除半消息，订阅方将不会接受该消息。

异常情况——事务主动方消息恢复 在断网或者应用重启等异常情况下，图中 4 提交的二次确认超时未到达 MQ Server，此时处理逻辑如下：

5. MQ Server 对该消息发起消息回查。
6. 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
7. 发送方根据检查得到的本地事务的最终状态再次提交二次确认
8. MQ Server 基于 commit / rollback 对消息进行投递或者删除

方案总结

相比本地消息表方案，MQ 事务方案优点是：

• 消息数据独立存储 ，降低业务系统与消息系统之间的耦合。
• 吞吐量优于使用本地消息表方案。

缺点是：

• 一次消息发送需要两次网络请求(half 消息 + commit/rollback 消息)
• 业务处理服务需要实现消息状态回查接口

七、SAGA

方案简介

Saga 事务源于 1987 年普林斯顿大学的 Hecto 和 Kenneth 发表的如何处理 long lived transaction（长活事务）论文，Saga 事务核心思想是将长事务拆分为多个本地短事务，由 Saga 事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。

处理流程

Saga 事务基本协议如下：

• 每个 Saga 事务由一系列幂等的有序子事务(sub-transaction) Ti 组成。
• 每个 Ti 都有对应的幂等补偿动作 Ci，补偿动作用于撤销 Ti 造成的结果。

可以看到，和 TCC 相比，Saga 没有“预留”动作，它的 Ti 就是直接提交到库。

下面以下单流程为例，整个操作包括：创建订单、扣减库存、支付、增加积分 Saga 的执行顺序有两种：

• 事务正常执行完成 T1, T2, T3, …, Tn，例如：扣减库存(T1)，创建订单(T2)，支付(T3)，依次有序完成整个事务。
• 事务回滚 T1, T2, …, Tj, Cj,…, C2, C1，其中 0 < j < n，例如：扣减库存(T1)，创建订单(T2)，支付(T3，支付失败)，支付回滚(C3)，订单回滚(C2)，恢复库存(C1)。

恢复策略

Saga 定义了两种恢复策略：

• 向前恢复(forward recovery)

对应于上面第一种执行顺序，适用于必须要成功的场景，发生失败进行重试，执行顺序是类似于这样的：T1, T2, …, Tj(失败), Tj(重试),…, Tn，其中 j 是发生错误的子事务(sub-transaction)。该情况下不需要 Ci。

• 向后恢复(backward recovery)

对应于上面提到的第二种执行顺序，其中 j 是发生错误的子事务(sub-transaction)，这种做法的效果是撤销掉之前所有成功的子事务，使得整个 Saga 的执行结果撤销。

Saga 事务常见的有两种不同的实现方式：命令协调和事件编排。

命令协调

• 命令协调(Order Orchestrator)：中央协调器负责集中处理事件的决策和业务逻辑排序。

中央协调器（Orchestrator，简称 OSO）以命令/回复的方式与每项服务进行通信，全权负责告诉每个参与者该做什么以及什么时候该做什么。

以电商订单的例子为例：

1. 事务发起方的主业务逻辑请求 OSO 服务开启订单事务。
2. OSO 向库存服务请求扣减库存，库存服务回复处理结果。
3. OSO 向订单服务请求创建订单，订单服务回复创建结果。
4. OSO 向支付服务请求支付，支付服务回复处理结果。
5. 主业务逻辑接收并处理 OSO 事务处理结果回复。

中央协调器必须事先知道执行整个订单事务所需的流程(例如通过读取配置)。如果有任何失败，它还负责通过向每个参与者发送命令来撤销之前的操作来协调分布式的回滚。基于中央协调器协调一切时，回滚要容易得多，因为协调器默认是执行正向流程，回滚时只要执行反向流程即可。

事件编排

• 事件编排 (Event Choreography0：没有中央协调器（没有单点风险）时，每个服务产生并观察其他服务的事件，并决定是否应采取行动。

在事件编排方法中，第一个服务执行一个事务，然后发布一个事件。该事件被一个或多个服务进行监听，这些服务再执行本地事务并发布（或不发布）新的事件。

当最后一个服务执行本地事务并且不发布任何事件时，意味着分布式事务结束，或者它发布的事件没有被任何 Saga 参与者听到都意味着事务结束。

以电商订单的例子为例：

1. 事务发起方的主业务逻辑发布开始订单事件
2. 库存服务监听开始订单事件，扣减库存，并发布库存已扣减事件
3. 订单服务监听库存已扣减事件，创建订单，并发布订单已创建事件
4. 支付服务监听订单已创建事件，进行支付，并发布订单已支付事件
5. 主业务逻辑监听订单已支付事件并处理。

事件/编排是实现 Saga 模式的自然方式，它很简单，容易理解，不需要太多的代码来构建。如果事务涉及 2 至 4 个步骤，则可能是非常合适的。

方案总结

命令协调设计的优点和缺点：

优点如下：

• 服务之间关系简单，避免服务之间的循环依赖关系，因为 Saga 协调器会调用 Saga 参与者，但参与者不会调用协调器
• 程序开发简单，只需要执行命令/回复(其实回复消息也是一种事件消息)，降低参与者的复杂性。
• 易维护扩展，在添加新步骤时，事务复杂性保持线性，回滚更容易管理，更容易实施和测试

缺点如下：

• 中央协调器容易处理逻辑容易过于复杂，导致难以维护。
• 存在协调器单点故障风险。

事件/编排设计的优点和缺点

优点如下：

• 避免中央协调器单点故障风险。
• 当涉及的步骤较少服务开发简单，容易实现。

缺点如下：

• 服务之间存在循环依赖的风险。
• 当涉及的步骤较多，服务间关系混乱，难以追踪调测。

值得补充的是，由于 Saga 模型中没有 Prepare 阶段，因此事务间不能保证隔离性，当多个 Saga 事务操作同一资源时，就会产生更新丢失、脏数据读取等问题，这时需要在业务层控制并发，例如：在应用层面加锁，或者应用层面预先冻结资源。

总结

各方案使用场景

介绍完分布式事务相关理论和常见解决方案后，最终的目的在实际项目中运用，因此，总结一下各个方案的常见的使用场景。

• 2PC/3PC 依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
• TCC 适用于执行时间确定且较短，实时性要求高，对数据一致性要求高，比如互联网金融企业最核心的三个服务：交易、支付、账务。
• 本地消息表/MQ 事务 都适用于事务中参与方支持操作幂等，对一致性要求不高，业务上能容忍数据不一致到一个人工检查周期，事务涉及的参与方、参与环节较少，业务上有对账/校验系统兜底。
• Saga 事务 由于 Saga 事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。 Saga 相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。Saga 事务较适用于补偿动作容易处理的场景。

分布式事务方案设计

本文介绍的偏向于原理，业界已经有不少开源的或者收费的解决方案，篇幅所限，就不再展开介绍。

实际运用理论时进行架构设计时，许多人容易犯“手里有了锤子，看什么都觉得像钉子”的错误，设计方案时考虑的问题场景过多，各种重试，各种补偿机制引入系统，导致设计出来的系统过于复杂，落地遥遥无期。

世界上解决一个计算机问题最简单的方法：“恰好”不需要解决它！—— 阿里中间件技术专家沈询

有些问题，看起来很重要，但实际上我们可以通过合理的设计或者将问题分解来规避。设计分布式事务系统也不是需要考虑所有异常情况，不必过度设计各种回滚，补偿机制。如果硬要把时间花在解决问题本身，实际上不仅效率低下，而且也是一种浪费。

如果系统要实现回滚流程的话，有可能系统复杂度将大大提升，且很容易出现 Bug，估计出现 Bug 的概率会比需要事务回滚的概率大很多。在设计系统时，我们需要衡量是否值得花这么大的代价来解决这样一个出现概率非常小的问题，可以考虑当出现这个概率很小的问题，能否采用人工解决的方式，这也是大家在解决疑难问题时需要多多思考的地方。

参考资料

• 聊聊分布式事务，再说说解决方案
• 理解分布式事务

总结 MIT6.824 Lab3B Log Compaction 实验笔记。

在PHP的源码中经常会看到的一些很常见的宏，或者有些对于才开始接触源码的读者比较难懂的代码。 这些代码在PHP的源码中出现的频 率极高，基本在每个模块都会有他们的身影。本篇文章我们提取中间的一些进行说明。

1. “##” 和 “#”

宏是C/C++是非常强大，使用也很多的一个功能，有时用来实现类似函数内联的效果，或者将复杂的代码进行简单封装，提高可读性或可 移植性等。在PHP的宏定义中经常使用双井号。下面对 “##” 及 “#” 进行详细介绍。

- 双井号（##）

在C语言的宏中，”##”被称为 连接符(concatenator)，它是一种预处理运算符， 用来把两个语言符号(Token)组合成单个语言符号。 这里的语言符号不一定是宏的变量。并且双井号不能作为第一个或最后一个元素存在。如下所示源码:

1
2
3
4
5
6
7
8
9

#define PHP_FUNCTION ZEND_FUNCTION
#define ZEND_FUNCTION(name) ZEND_NAMED_FUNCTION(ZEND_FN(name))
#define ZEND_FN(name) zif_##name
#define ZEND_NAMED_FUNCTION(name) void name(INTERNAL_FUNCTION_PARAMETERS)
#define INTERNAL_FUNCTION_PARAMETERS int ht, zval *return_value, zval **return_value_ptr, \ zval *this_ptr, int return_value_used TSRMLS_DC

PHP_FUNCTION(count);
// 预处理器处理以后， PHP_FUCNTION(count);就展开为如下代码
void zif_count(int ht, zval *return_value, zval **return_value_ptr, zval *this_ptr, int return_value_used TSRMLS_DC)

宏 ZEND_FN(name) 中有一个 ##，它的作用一如之前所说，是一个连接符，将 zif 和宏的变量 name 的值连接起来。以这种连接的方式为基 础，多次使用这种宏形式，可以将它当作一个代码生成器，这样可以在一定程度上减少代码密度，我们也可以将它理解为一种代码重用的手段，间接地减少不小心所造成的错误。

-单井号（#）

“#”是一种预处理运算符，它的功能是将其后面的宏参数进行字符串化操作， 简单说就是在对它所引用的宏变量通过替换后在其左右各加上一个双引号，用比较官方的话说就是将语言符号(Token)转化为字符串。例如:

1
2
3
4
5
6

#define STR(x) #x

int main(int argc char** argv) {
    printf("%s\n", STR(It's a long string)); // 输出 It's a long string
    return 0;
}

如前文所说，It's a long string 是宏 STR 的参数，在展开后被包裹成一个字符串了。所以 printf 函数能直接输出这个字符串， 当然这个使用场景并不是很适合，因为这种用法并没有实际的意义，实际中在宏中可能会包裹其他的逻辑，比如对字符串进行封装等等。

关于宏定义中的 do-while 循环

PHP源码中大量使用了宏操作，比如 PHP5.3 新增加的垃圾收集机制中的一段代码:

1
2
3
4
5
6

#define ALLOC_ZVAL(z)                           \
do {                                            \
    (z) = (zval*)emalloc(sizeof(zval_gc_info)); \
    GC_ZVAL_INIT(z);                            \
} while (0)

这段代码，在宏定义中使用了 do{ }while(0) 语句格式。如果我们搜索整个PHP的源码目录，会发现这样的语句还有很多。在其他使用 C/C++ 编写的程序中也会有很多这种编写宏的代码，多行宏的这种格式已经是一种公认的编写方式了。为什么在宏定义时需要使用 do-while 语句呢？我们知道 do-while 循环语句是先执行循环体再判断条件是否成立，所以说至少会执行一次。当使用 do{ }while(0) 时由于条件肯定为 false，代码也肯定只执行一次，肯定只执行一次的代码为什么要放在 do-while 语句里呢? 这种方式适用于宏定义中存在多语句的情况。如下所示代码:

1
2
3
4
5
6

#define TEST(a, b) a++;b++;

if (expr)
    TEST(a, b);
else
    do_else();

代码进行预处理后，会变成：

1
2
3
4

if (expr)
    a++;b++;
else
    do_else();

这样 if-else 的结构就被破坏了 if 后面有两个语句，这样是无法编译通过的，那为什么非要 do-while 而不是简单的用 {} 括起来呢。这样也能保证if后面只有一个语句。例如上面的例子，在调用宏 TEST 的时候后面加了一个分号，虽然这个分号可有可无，但是出于习惯我们一般都会写上。 那如果是把宏里的代码用 {} 括起来，加上最后的那个分号。还是不能通过编译。所以一般的多表达式宏定义中都采用 do-while(0) 的方式。

了解了 do-while 循环在宏中的作用，再来看 空操作 的定义。由于 PHP 需要考虑到平台的移植性和不同的系统配置，所以需要在某些时候 把一些宏的操作定义为空操作。例如在 sapi\thttpd\thttpd.c 文件中的 VEC_FREE():

1
2
3
4
5

#ifdef SERIALIZE_HEADERS
#   define VEC_FREE() smart_str_free(&vec_str)
#else
#   define VEC_FREE() do {} while (0)
#endif

这里涉及到条件编译，在定义了 SERIALIZE_HEADERS 宏的时候将 VEC_FREE() 定义为如上的内容，而没有定义时，不需要做任何操作，所以后面的宏将 VEC_FREE() 定义为一个空操作，不做任何操作，通常这样来保证一致性，或者充分利用系统提供的功能。有时也会使用如下的方式来定义“空操作”，这里的空操作和上面的还是不一样，例如很常见的 Debug 日志打印宏:

1
2
3
4
5

#ifdef DEBUG
#   define LOG_MSG printf
#else
#   define LOG_MSG(...)
#endif

在编译时如果定义了 DEBUG 则将 LOG_MSG 当做 printf 使用，而不需要调试，正式发布时则将 LOG_MSG() 宏定义为空，由于宏是在预编译阶段进行处理的，所以上面的宏相当于从代码中删除了。

上面提到了两种将宏定义为空的定义方式，看上去一样，实际上只要明白了宏都只是简单的代码替换就知道该如何选择了。

- #line 预处理

#line 838 "Zend/zend_language_scanner.c"

#line预处理用于改变当前的行号 (__LINE__) 和文件名 (__FILE__)。如上所示代码，将当前的行号改变为838，文件名 Zend/zend_language_scanner.c 它的作用体现在编译器的编写中，我们知道编译器对 C 源码编译过程中会产生一些中间文件，通过这条指令，可以保证文件名是固定的，不会被这些中间文件代替，有利于进行调试分析。

- PHP 中的全局变量宏

在PHP代码中经常能看到一些类似 PG()、EG() 之类的函数，他们都是 PHP 中定义的宏，这系列宏主要的作用是解决线程安全所写的全局变量包裹宏，如 main/php_globals.h 文件中就包含了很多这类的宏。例如 PG 这个 PHP 的核心全局变量的宏。如下所示代码为其定义：

1
2
3
4
5

#ifdef ZTS // 编译时开启了线程安全则使用线程安全库
#   define PG(v) TSRMG(core_globals_id, php_core_globals *, v) extern PHPAPI int core_globals_id;
#else
#   define PG(v) (core_globals.v) // 否则这其实就是一个普通的全局变量 extern ZEND_API struct _php_core_globals core_globals;
#endif

如上，ZTS是线程安全的标记。下面简单说说，PHP运行时的一些全局参数， 这个全局 变量为如下的一个结构体，各字段的意义如字段后的注释：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118

struct _php_core_globals {
    zend_bool magic_quotes_gpc; //  是否对输入的GET/POST/Cookie数据使用自动字符串转义。
    zend_bool magic_quotes_runtime; //是否对运行时从外部资源产生的数据使用自动字符串转义
    zend_bool magic_quotes_sybase;  //   是否采用Sybase形式的自动字符串转义

    zend_bool safe_mode;    //  是否启用安全模式

    zend_bool allow_call_time_pass_reference;   //是否强迫在函数调用时按引用传递参数
    zend_bool implicit_flush;   //是否要求PHP输出层在每个输出块之后自动刷新数据

    long output_buffering;  //输出缓冲区大小(字节)

    char *safe_mode_include_dir;    //在安全模式下，该组目录和其子目录下的文件被包含时，将跳过UID/GID检查。
    zend_bool safe_mode_gid;    //在安全模式下，默认在访问文件时会做UID比较检查
    zend_bool sql_safe_mode;
    zend_bool enable_dl;    //是否允许使用dl()函数。dl()函数仅在将PHP作为apache模块安装时才有效。

    char *output_handler;   // 将所有脚本的输出重定向到一个输出处理函数。

    char *unserialize_callback_func;    // 如果解序列化处理器需要实例化一个未定义的类，这里指定的回调函数将以该未定义类的名字作为参数被unserialize()调用，
    long serialize_precision;   //将浮点型和双精度型数据序列化存储时的精度(有效位数)。

    char *safe_mode_exec_dir;   //在安全模式下，只有该目录下的可执行程序才允许被执行系统程序的函数执行。

    long memory_limit;  //一个脚本所能够申请到的最大内存字节数(可以使用K和M作为单位)。
    long max_input_time;    // 每个脚本解析输入数据(POST, GET, upload)的最大允许时间(秒)。

    zend_bool track_errors; //是否在变量$php_errormsg中保存最近一个错误或警告消息。
    zend_bool display_errors;   //是否将错误信息作为输出的一部分显示。
    zend_bool display_startup_errors;   //是否显示PHP启动时的错误。
    zend_bool log_errors;   // 是否在日志文件里记录错误，具体在哪里记录取决于error_log指令
    long      log_errors_max_len;   //设置错误日志中附加的与错误信息相关联的错误源的最大长度。
    zend_bool ignore_repeated_errors;   //   记录错误日志时是否忽略重复的错误信息。
    zend_bool ignore_repeated_source;   //是否在忽略重复的错误信息时忽略重复的错误源。
    zend_bool report_memleaks;  //是否报告内存泄漏。
    char *error_log;    //将错误日志记录到哪个文件中。

    char *doc_root; //PHP的”根目录”。
    char *user_dir; //告诉php在使用 /~username 打开脚本时到哪个目录下去找
    char *include_path; //指定一组目录用于require(), include(), fopen_with_path()函数寻找文件。
    char *open_basedir; // 将PHP允许操作的所有文件(包括文件自身)都限制在此组目录列表下。
    char *extension_dir;    //存放扩展库(模块)的目录，也就是PHP用来寻找动态扩展模块的目录。

    char *upload_tmp_dir;   // 文件上传时存放文件的临时目录
    long upload_max_filesize;   // 允许上传的文件的最大尺寸。

    char *error_append_string;  // 用于错误信息后输出的字符串
    char *error_prepend_string; //用于错误信息前输出的字符串

    char *auto_prepend_file;    //指定在主文件之前自动解析的文件名。
    char *auto_append_file; //指定在主文件之后自动解析的文件名。

    arg_separators arg_separator;   //PHP所产生的URL中用来分隔参数的分隔符。

    char *variables_order;  // PHP注册 Environment, GET, POST, Cookie, Server 变量的顺序。

    HashTable rfc1867_protected_variables;  //  RFC1867保护的变量名，在main/rfc1867.c文件中有用到此变量

    short connection_status;    //  连接状态，有三个状态，正常，中断，超时
    short ignore_user_abort;    //  是否即使在用户中止请求后也坚持完成整个请求。

    unsigned char header_is_being_sent; //  是否头信息正在发送

    zend_llist tick_functions;  //  仅在main目录下的php_ticks.c文件中有用到，此处定义的函数在register_tick_function等函数中有用到。

    zval *http_globals[6];  // 存放GET、POST、SERVER等信息

    zend_bool expose_php;   //  是否展示php的信息

    zend_bool register_globals; //  是否将 E, G, P, C, S 变量注册为全局变量。
    zend_bool register_long_arrays; //   是否启用旧式的长式数组(HTTP_*_VARS)。
    zend_bool register_argc_argv;   //  是否声明$argv和$argc全局变量(包含用GET方法的信息)。
    zend_bool auto_globals_jit; //  是否仅在使用到$_SERVER和$_ENV变量时才创建(而不是在脚本一启动时就自动创建)。

    zend_bool y2k_compliance;   //是否强制打开2000年适应(可能在非Y2K适应的浏览器中导致问题)。

    char *docref_root;  // 如果打开了html_errors指令，PHP将会在出错信息上显示超连接，
    char *docref_ext;   //指定文件的扩展名(必须含有’.')。

    zend_bool html_errors;  //是否在出错信息中使用HTML标记。
    zend_bool xmlrpc_errors;

    long xmlrpc_error_number;

    zend_bool activated_auto_globals[8];

    zend_bool modules_activated;    //  是否已经激活模块
    zend_bool file_uploads; //是否允许HTTP文件上传。
    zend_bool during_request_startup;   //是否在请求初始化过程中
    zend_bool allow_url_fopen;  //是否允许打开远程文件
    zend_bool always_populate_raw_post_data;    //是否总是生成$HTTP_RAW_POST_DATA变量(原始POST数据)。
    zend_bool report_zend_debug;    //  是否打开zend debug，仅在main/main.c文件中有使用。

    int last_error_type;    //  最后的错误类型
    char *last_error_message;   //  最后的错误信息
    char *last_error_file;  //  最后的错误文件
    int  last_error_lineno; //  最后的错误行

    char *disable_functions;    //该指令接受一个用逗号分隔的函数名列表，以禁用特定的函数。
    char *disable_classes;  //该指令接受一个用逗号分隔的类名列表，以禁用特定的类。
    zend_bool allow_url_include;    //是否允许include/require远程文件。
    zend_bool exit_on_timeout;  //  超时则退出
#ifdef PHP_WIN32
    zend_bool com_initialized;
#endif
    long max_input_nesting_level;   //最大的嵌套层数
    zend_bool in_user_include;  //是否在用户包含空间

    char *user_ini_filename;    //  用户的ini文件名
    long user_ini_cache_ttl;    //  ini缓存过期限制

    char *request_order;    //  优先级比variables_order高，在request变量生成时用到，个人觉得是历史遗留问题

    zend_bool mail_x_header;    //  仅在ext/standard/mail.c文件中使用，
    char *mail_log;

    zend_bool in_error_log;
};

上面的字段很大一部分是与 php.ini 文件中的配置项对应的。在 PHP 启动并读取 php.ini 文件时就会对这些字段进行赋值，而用户空间的 ini_get() 及 ini_set() 函数操作的一些配置也是对这个全局变量进行操作的。

在 PHP 代码的其他地方也存在很多类似的宏，这些宏和 PG 宏一样，都是为了将线程安全进行封装，同时通过约定的 G 命名来表明这是全局的， 一般都是个缩写，因为这些全局变量在代码的各处都会使用到，这也算是减少了键盘输入。 我们都应该尽可能的懒不是么？

如果你阅读过一些 PHP 扩展话应该也见过类似的宏，这也算是一种代码规范，在编写扩展时全局变量最好也使用这种方式命名和包裹，因为我们不能对用户的 PHP 编译条件做任何假设。

在PHP的源码中经常会看到的一些很常见的宏，或者有些对于才开始接触源码的读者比较难懂的代码。 这些代码在PHP的源码中出现的频 率极高，基本在每个模块都会有他们的身影。本篇文章我们提取中间的一些进行说明。

分布式锁基本原理

📦 本文已归档到：「blog」

• 1. 分布式锁思路
• 2. 数据库分布式锁
  • 2.1. 具体实现
  • 2.2. 问题
  • 2.3. 解决办法
  • 2.4. 小结
• 3. Redis 分布式锁
  • 3.1. 实现思路
  • 3.2. 具体实现
  • 3.3. 小结
  • 3.4. RedLock 算法
• 4. ZooKeeper 分布式锁
  • 4.1. 实现思路
  • 4.2. 具体实现
  • 4.3. 小结
• 5. 分布式锁方案对比
• 参考资料

Java 原生 API 虽然有并发锁，但并没有提供分布式锁的能力，所以针对分布式场景中的锁需要解决的方案。

分布式锁的解决方案大致有以下几种：

• 基于数据库实现
• 基于缓存（redis，memcached 等）实现
• 基于 Zookeeper 实现 ✅

注：推荐基于 ZooKeeper 实现分布式锁，具体原因看完本文即可明了。

1. 分布式锁思路

分布式锁的总体思路大同小异，仅在实现细节上有所不同。

分布式锁的主要思路如下：

• 互斥 - 创建锁必须是唯一的，表现形式为向数据存储服务器或容器插入一个唯一的 key，一旦有一个线程插入这个 key，其他线程就不能再插入了。
• 避免永远不释放锁 - 数据库分布式锁和缓存分布式锁（Redis）的思路都是引入超时机制，即成功申请锁后，超过一定时间，锁失效（删除 key），原因在于它们无法感知申请锁的客户端节点状态。而 ZooKeeper 由于其 znode 以目录、文件形式组织，天然就存在物理空间隔离，只要 znode 存在，即表示客户端节点还在工作，所以不存在这种问题。
• 容错（只要大部分 redis 节点创建了这把锁就可以）

2. 数据库分布式锁

2.1. 具体实现

（1）创建表

1
2
3
4
5
6
7
8

CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

（2）获取锁

想要锁住某个方法时，执行以下 SQL：

1

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

因为我们对 method_name 做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

成功插入则获取锁。

（3）释放锁

当方法执行完毕之后，想要释放锁的话，需要执行以下 Sql:

1

delete from methodLock where method_name ='method_name'

2.2. 问题

• 这把锁强依赖数据库的可用性。如果数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
• 这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
• 这把锁只能是非阻塞的，因为数据的 insert 操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
• 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

2.3. 解决办法

• 单点问题可以用多数据库实例，同时塞 N 个表，N/2+1 个成功就任务锁定成功
• 写一个定时任务，隔一段时间清除一次过期的数据。
• 写一个 while 循环，不断的重试插入，直到成功。
• 在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

2.4. 小结

• 优点: 直接借助数据库，容易理解。
• 缺点: 会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。操作数据库需要一定的开销，性能问题需要考虑。

3. Redis 分布式锁

相比于用数据库来实现分布式锁，基于缓存实现的分布式锁的性能会更好一些。目前有很多成熟的分布式产品，包括 Redis、memcache、Tair 等。这里以 Redis 举例。

3.1. 实现思路

这个分布式锁有 3 个重要的考量点：

1. 互斥（只能有一个客户端获取锁）
2. 不能死锁
3. 容错（只要大部分 redis 节点创建了这把锁就可以）

对应的 Redis 指令如下：

• setnx - setnx key val：当且仅当 key 不存在时，set 一个 key 为 val 的字符串，返回 1；若 key 存在，则什么都不做，返回 0。
• expire - expire key timeout：为 key 设置一个超时时间，单位为 second，超过这个时间锁会自动释放，避免死锁。
• delete - delete key：删除 key

3.2. 具体实现

（1）申请锁

1

SET resource_name my_random_value NX PX 30000

执行这个命令就 ok。

• NX：表示只有 key 不存在的时候才会设置成功。（如果此时 redis 中存在这个 key，那么设置失败，返回 nil）
• PX 30000：意思是 30s 后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了。

（2）释放锁

释放锁就是删除 key ，但是一般可以用 lua 脚本删除，判断 value 一样才删除：

1
2
3
4
5
6

-- 删除锁的时候，找到 key 对应的 value，跟自己传过去的 value 做比较，如果是一样的才删除。
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

3.3. 小结

为啥要用 random_value 随机值呢？因为如果某个客户端获取到了锁，但是阻塞了很长时间才执行完，比如说超过了 30s，此时可能已经自动释放锁了，此时可能别的客户端已经获取到了这个锁，要是你这个时候直接删除 key 的话会有问题，所以得用随机值加上面的 lua 脚本来释放锁。

但是这样是肯定不行的。因为如果是普通的 redis 单实例，那就是单点故障。或者是 redis 普通主从，那 redis 主从异步复制，如果主节点挂了（key 就没有了），key 还没同步到从节点，此时从节点切换为主节点，别人就可以 set key，从而拿到锁。

3.4. RedLock 算法

这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：

1. 获取当前时间戳，单位是毫秒；
2. 跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
3. 尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n / 2 + 1；
4. 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
5. 要是锁建立失败了，那么就依次之前建立过的锁删除；
6. 只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。

Redis 官方给出了以上两种基于 Redis 实现分布式锁的方法，详细说明可以查看：https://redis.io/topics/distlock 。

4. ZooKeeper 分布式锁

4.1. 实现思路

这也是 ZooKeeper 客户端 curator 的分布式锁实现。

1. 创建一个目录 mylock；
2. 线程 A 想获取锁就在 mylock 目录下创建临时顺序节点；
3. 获取 mylock 目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁；
4. 线程 B 获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；
5. 线程 A 处理完，删除自己的节点，线程 B 监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

4.2. 具体实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138

/**
 * ZooKeeperSession
 *
 * @author bingo
 * @since 2018/11/29
 *
 */
public class ZooKeeperSession {

    private static CountDownLatch connectedSemaphore = new CountDownLatch(1);

    private ZooKeeper zookeeper;
    private CountDownLatch latch;

    public ZooKeeperSession() {
        try {
            this.zookeeper = new ZooKeeper("192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181", 50000, new ZooKeeperWatcher());
            try {
                connectedSemaphore.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            System.out.println("ZooKeeper session established......");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * 获取分布式锁
     *
     * @param productId
     */
    public Boolean acquireDistributedLock(Long productId) {
        String path = "/product-lock-" + productId;

        try {
            zookeeper.create(path, "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
            return true;
        } catch (Exception e) {
            while (true) {
                try {
                    // 相当于是给node注册一个监听器，去看看这个监听器是否存在
                    Stat stat = zk.exists(path, true);

                    if (stat != null) {
                        this.latch = new CountDownLatch(1);
                        this.latch.await(waitTime, TimeUnit.MILLISECONDS);
                        this.latch = null;
                    }
                    zookeeper.create(path, "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
                    return true;
                } catch (Exception ee) {
                    continue;
                }
            }

        }
        return true;
    }

    /**
     * 释放掉一个分布式锁
     *
     * @param productId
     */
    public void releaseDistributedLock(Long productId) {
        String path = "/product-lock-" + productId;
        try {
            zookeeper.delete(path, -1);
            System.out.println("release the lock for product[id=" + productId + "]......");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * 建立zk session的watcher
     *
     * @author bingo
     * @since 2018/11/29
     *
     */
    private class ZooKeeperWatcher implements Watcher {

        public void process(WatchedEvent event) {
            System.out.println("Receive watched event: " + event.getState());

            if (KeeperState.SyncConnected == event.getState()) {
                connectedSemaphore.countDown();
            }

            if (this.latch != null) {
                this.latch.countDown();
            }
        }

    }

    /**
     * 封装单例的静态内部类
     *
     * @author bingo
     * @since 2018/11/29
     *
     */
    private static class Singleton {

        private static ZooKeeperSession instance;

        static {
            instance = new ZooKeeperSession();
        }

        public static ZooKeeperSession getInstance() {
            return instance;
        }

    }

    /**
     * 获取单例
     *
     * @return
     */
    public static ZooKeeperSession getInstance() {
        return Singleton.getInstance();
    }

    /**
     * 初始化单例的便捷方法
     */
    public static void init() {
        getInstance();
    }

}

也可以采用另一种方式，创建临时顺序节点：

如果有一把锁，被多个人给竞争，此时多个人会排队，第一个拿到锁的人会执行，然后释放锁；后面的每个人都会去监听排在自己前面的那个人创建的 node 上，一旦某个人释放了锁，排在自己后面的人就会被 zookeeper 给通知，一旦被通知了之后，就 ok 了，自己就获取到了锁，就可以执行代码了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124

public class ZooKeeperDistributedLock implements Watcher {

    private ZooKeeper zk;
    private String locksRoot = "/locks";
    private String productId;
    private String waitNode;
    private String lockNode;
    private CountDownLatch latch;
    private CountDownLatch connectedLatch = new CountDownLatch(1);
    private int sessionTimeout = 30000;

    public ZooKeeperDistributedLock(String productId) {
        this.productId = productId;
        try {
            String address = "192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181";
            zk = new ZooKeeper(address, sessionTimeout, this);
            connectedLatch.await();
        } catch (IOException e) {
            throw new LockException(e);
        } catch (KeeperException e) {
            throw new LockException(e);
        } catch (InterruptedException e) {
            throw new LockException(e);
        }
    }

    public void process(WatchedEvent event) {
        if (event.getState() == KeeperState.SyncConnected) {
            connectedLatch.countDown();
            return;
        }

        if (this.latch != null) {
            this.latch.countDown();
        }
    }

    public void acquireDistributedLock() {
        try {
            if (this.tryLock()) {
                return;
            } else {
                waitForLock(waitNode, sessionTimeout);
            }
        } catch (KeeperException e) {
            throw new LockException(e);
        } catch (InterruptedException e) {
            throw new LockException(e);
        }
    }

    public boolean tryLock() {
        try {
 		    // 传入进去的locksRoot + “/” + productId
		    // 假设productId代表了一个商品id，比如说1
		    // locksRoot = locks
		    // /locks/10000000000，/locks/10000000001，/locks/10000000002
            lockNode = zk.create(locksRoot + "/" + productId, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);

            // 看看刚创建的节点是不是最小的节点
	 	    // locks：10000000000，10000000001，10000000002
            List<String> locks = zk.getChildren(locksRoot, false);
            Collections.sort(locks);

            if(lockNode.equals(locksRoot+"/"+ locks.get(0))){
                //如果是最小的节点,则表示取得锁
                return true;
            }

            //如果不是最小的节点，找到比自己小1的节点
	  int previousLockIndex = -1;
            for(int i = 0; i < locks.size(); i++) {
		if(lockNode.equals(locksRoot + “/” + locks.get(i))) {
	         	    previousLockIndex = i - 1;
		    break;
		}
	   }

	   this.waitNode = locks.get(previousLockIndex);
        } catch (KeeperException e) {
            throw new LockException(e);
        } catch (InterruptedException e) {
            throw new LockException(e);
        }
        return false;
    }

    private boolean waitForLock(String waitNode, long waitTime) throws InterruptedException, KeeperException {
        Stat stat = zk.exists(locksRoot + "/" + waitNode, true);
        if (stat != null) {
            this.latch = new CountDownLatch(1);
            this.latch.await(waitTime, TimeUnit.MILLISECONDS);
            this.latch = null;
        }
        return true;
    }

    public void unlock() {
        try {
            // 删除/locks/10000000000节点
            // 删除/locks/10000000001节点
            System.out.println("unlock " + lockNode);
            zk.delete(lockNode, -1);
            lockNode = null;
            zk.close();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (KeeperException e) {
            e.printStackTrace();
        }
    }

    public class LockException extends RuntimeException {
        private static final long serialVersionUID = 1L;

        public LockException(String e) {
            super(e);
        }

        public LockException(Exception e) {
            super(e);
        }
    }
}

4.3. 小结

ZooKeeper 版本的分布式锁问题相对比较来说少。

• 锁的占用时间限制：redis 就有占用时间限制，而 ZooKeeper 则没有，最主要的原因是 redis 目前没有办法知道已经获取锁的客户端的状态，是已经挂了呢还是正在执行耗时较长的业务逻辑。而 ZooKeeper 通过临时节点就能清晰知道，如果临时节点存在说明还在执行业务逻辑，如果临时节点不存在说明已经执行完毕释放锁或者是挂了。由此看来 redis 如果能像 ZooKeeper 一样添加一些与客户端绑定的临时键，也是一大好事。
• 是否单点故障：redis 本身有很多中玩法，如客户端一致性 hash，服务器端 sentinel 方案或者 cluster 方案，很难做到一种分布式锁方式能应对所有这些方案。而 ZooKeeper 只有一种玩法，多台机器的节点数据是一致的，没有 redis 的那么多的麻烦因素要考虑。

总体上来说 ZooKeeper 实现分布式锁更加的简单，可靠性更高。但 ZooKeeper 因为需要频繁的创建和删除节点，性能上不如 Redis 方式。

5. 分布式锁方案对比

• 数据库分布式锁，问题比较多，解决起来比较麻烦，不推荐

• redis 分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能。

• zk 分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。

另外一点就是，如果是 redis 获取锁的那个客户端出现 bug 挂了，那么只能等待超时时间之后才能释放锁；而 zk 的话，因为创建的是临时 znode，只要客户端挂了，znode 就没了，此时就自动释放锁。

总体上来说，ZooKeeper 实现分布式锁更加的简单，可靠性更高。

参考资料

• 分布式锁实现汇总

分布式会话基本原理

📦 本文已归档到：「blog」

由于 Http 是一种无状态的协议，服务器单单从网络连接上无从知道客户身份。

会话跟踪是 Web 程序中常用的技术，用来跟踪用户的整个会话。常用会话跟踪技术是 Cookie 与 Session。

1. 简介

1.1. 什么是 Cookie

Cookie 实际上是存储在用户浏览器上的文本信息，并保留了各种跟踪的信息。

Cookie 工作步骤：

1. 客户端请求服务器，如果服务器需要记录该用户的状态，就是用 response 向客户端浏览器颁发一个 Cookie。
2. 客户端浏览器会把 Cookie 保存下来。
3. 当浏览器再请求该网站时，浏览器把该请求的网址连同 Cookie 一同提交给服务器。服务器检查该 Cookie，以此来辨认用户状态。

Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

注：Cookie 功能需要浏览器的支持，如果浏览器不支持 Cookie 或者 Cookie 禁用了，Cookie 功能就会失效。

1.2. 什么是 Session

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

1.3. Cookie 和 Session 的区别

• 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
• 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

1.4. 为什么需要 Cookie 和 Session，他们有什么关联？

说起来为什么需要 Cookie ，这就需要从浏览器开始说起，我们都知道浏览器是没有状态的(HTTP 协议无状态)，这意味着浏览器并不知道是张三还是李四在和服务端打交道。这个时候就需要有一个机制来告诉服务端，本次操作用户是否登录，是哪个用户在执行的操作，那这套机制的实现就需要 Cookie 和 Session 的配合。

那么 Cookie 和 Session 是如何配合的呢？我画了一张图大家可以先了解下。

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。

当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

1.5. 如果浏览器禁用 Cookie 怎么办

既然服务端是根据 Cookie 中的信息判断用户是否登录，那么如果浏览器中禁止了 Cookie，如何保障整个机制的正常运转。

第一种方案，每次请求中都携带一个 SessionID 的参数，也可以 Post 的方式提交，也可以在请求的地址后面拼接 xxx?SessionID=123456...。

第二种方案，Token 机制。Token 机制多用于 App 客户端和服务器交互的模式，也可以用于 Web 端做用户状态管理。

Token 的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。Token 机制和 Cookie 和 Session 的使用机制比较类似。

当用户第一次登录后，服务器根据提交的用户信息生成一个 Token，响应时将 Token 返回给客户端，以后客户端只需带上这个 Token 前来请求数据即可，无需再次登录验证。

2. 分布式 Session

在分布式场景下，一个用户的 Session 如果只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另一个服务器上，该服务器没有用户的 Session，就可能导致用户需要重新进行登录等操作。

分布式 Session 的几种实现策略：

1. 粘性 session
2. 应用服务器间的 session 复制共享
3. 基于缓存的 session 共享 ✅

推荐：基于缓存的 session 共享

2.1. 粘性 Session

粘性 Session（Sticky Sessions）需要配置负载均衡器，使得一个用户的所有请求都路由到一个服务器节点上，这样就可以把用户的 Session 存放在该服务器节点中。

缺点：当服务器节点宕机时，将丢失该服务器节点上的所有 Session。

2.2. Session 复制共享

Session 复制共享（Session Replication）在服务器节点之间进行 Session 同步操作，这样的话用户可以访问任何一个服务器节点。

缺点：占用过多内存；同步过程占用网络带宽以及服务器处理器时间。

2.3. 基于缓存的 session 共享

使用一个单独的存储服务器存储 Session 数据，可以存在 MySQL 数据库上，也可以存在 Redis 或者 Memcached 这种内存型数据库。

缺点：需要去实现存取 Session 的代码。

3. 具体实现

3.1. JWT Token

使用 JWT Token 储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓。

3.2. tomcat + redis

这个其实还挺方便的，就是使用 session 的代码，跟以前一样，还是基于 tomcat 原生的 session 支持即可，然后就是用一个叫做 Tomcat RedisSessionManager 的东西，让所有我们部署的 tomcat 都将 session 数据存储到 redis 即可。

在 tomcat 的配置文件中配置：

1
2
3
4
5
6
7

<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />

<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
         host="{redis.host}"
         port="{redis.port}"
         database="{redis.dbnum}"
         maxInactiveInterval="60"/>

然后指定 redis 的 host 和 port 就 ok 了。

1
2
3
4
5

<Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />
<Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"
	 sentinelMaster="mymaster"
	 sentinels="<sentinel1-ip>:26379,<sentinel2-ip>:26379,<sentinel3-ip>:26379"
	 maxInactiveInterval="60"/>

还可以用上面这种方式基于 redis 哨兵支持的 redis 高可用集群来保存 session 数据，都是 ok 的。

3.3. spring session + redis

上面那种 tomcat + redis 的方式好用，但是会严重依赖于 web 容器，不好将代码移植到其他 web 容器上去，尤其是你要是换了技术栈咋整？比如换成了 spring cloud 或者是 spring boot 之类的呢？

所以现在比较好的还是基于 Java 一站式解决方案，也就是 spring。人家 spring 基本上承包了大部分我们需要使用的框架，spirng cloud 做微服务，spring boot 做脚手架，所以用 sping session 是一个很好的选择。

在 pom.xml 中配置：

1
2
3
4
5
6
7
8
9
10

<dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-data-redis</artifactId>
  <version>1.2.1.RELEASE</version>
</dependency>
<dependency>
  <groupId>redis.clients</groupId>
  <artifactId>jedis</artifactId>
  <version>2.8.1</version>
</dependency>

在 spring 配置文件中配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<bean id="redisHttpSessionConfiguration"
     class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
    <property name="maxInactiveIntervalInSeconds" value="600"/>
</bean>

<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
    <property name="maxTotal" value="100" />
    <property name="maxIdle" value="10" />
</bean>

<bean id="jedisConnectionFactory"
      class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory" destroy-method="destroy">
    <property name="hostName" value="${redis_hostname}"/>
    <property name="port" value="${redis_port}"/>
    <property name="password" value="${redis_pwd}" />
    <property name="timeout" value="3000"/>
    <property name="usePool" value="true"/>
    <property name="poolConfig" ref="jedisPoolConfig"/>
</bean>

在 web.xml 中配置：

1
2
3
4
5
6
7
8

<filter>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSessionRepositoryFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@RestController
@RequestMapping("/test")
public class TestController {

    @RequestMapping("/putIntoSession")
    public String putIntoSession(HttpServletRequest request, String username) {
        request.getSession().setAttribute("name",  "leo");
        return "ok";
    }

    @RequestMapping("/getFromSession")
    public String getFromSession(HttpServletRequest request, Model model){
        String name = request.getSession().getAttribute("name");
        return name;
    }
}

上面的代码就是 ok 的，给 sping session 配置基于 redis 来存储 session 数据，然后配置了一个 spring session 的过滤器，这样的话，session 相关操作都会交给 spring session 来管了。接着在代码中，就用原生的 session 操作，就是直接基于 spring sesion 从 redis 中获取数据了。

实现分布式的会话有很多种方式，我说的只不过是比较常见的几种方式，tomcat + redis 早期比较常用，但是会重耦合到 tomcat 中；近些年，通过 spring session 来实现。

4. 参考资料

• 集群/分布式环境 Session 的几种策略
• 你真的了解 Cookie 和 Session 吗
• 聊一聊 session 和 cookie

网络通信知识点面经

📦 本文已归档到：「blog」

如果你不是从事于通信领域，面试时问及计算机网络的知识，一般也就限定在：HTTP（含 HTTPS、Cookie、Session）、TCP、UDP、Socket 这些

• 1. 综合
  • 1.1. 计算机网络如何分层？
• 2. HTTP
• 3. DNS
• 4. TCP/UDP
  • 4.1. 什么是 TCP？
  • 4.2. TCP 的特性是什么？
  • 4.3. TCP 三次握手
  • 4.4. TCP 四次挥手
  • 4.5. TCP 滑动窗口
  • 4.6. TCP 重传机制

1. 综合

1.1. 计算机网络如何分层？

❓ 问题：计算机网络如何分层？各层的作用是什么？各层的主要协议、设备分别是什么？

这是学习计算机网络知识宏观层面必须要了解的核心点。知道了这些，对于网络的体系结构就基本上了解了。

• OSI 的七层体系结构概念清楚，理论完整，但是比较复杂且不实用，所以并不流行。
• 五层协议分层是一种折中方案，在现实中更为流行。

物理层（Physical Layer）只接收和发送一串比特(bit)流，不考虑信息的意义和信息结构。

扩展阅读：计算机网络之物理层

• 关键词：调制、解调、数字信号、模拟信号、通信媒介、信道复用
• 数据单元：比特流。
• 典型设备：光纤、同轴电缆、双绞线、中继器和集线器。

数据链路层

网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，数据链路层（Data Link Layer）就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。

扩展阅读：计算机网络之数据链路层

• 关键词：点对点信道、广播信道、PPP、CSMA/CD、局域网、以太网、MAC、适配器、集线器、网桥、交换机
• 主要协议：PPP、CSMA/CD 等。
• 数据单元：帧（frame）。
• 典型设备：二层交换机、网桥、网卡。

网络层

网络层（network layer）为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组或包进行传送。

扩展阅读：计算机网络之网络层

• 关键词：IP、ICMP、ARP、路由
• 主要协议：IP。
• 数据单元：IP 数据报（packet）。
• 典型设备：网关、路由器。

传输层

传输层（transport layer）为两台主机中进程间的通信提供通用的数据传输服务。

扩展阅读：计算机网络之网络层

• 关键词：UDP、TCP、滑动窗口、拥塞控制、三次握手
• 主要协议：TCP、UDP。
• 数据单元：报文段（segment）或用户数据报。

\会话层~~

~~会话层（Session Layer）不参与具体的传输，它提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制。~~

\表示层~~

~~表示层（Presentation Layer）是为在应用过程之间传送的信息提供表示方法的服务，它关心的只是发出信息的语法与语义。表示层要完成某些特定的功能，主要有不同数据编码格式的转换，提供数据压缩、解压缩服务，对数据进行加密、解密。~~

应用层

应用层（application layer）通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间通信和交互的规则。

扩展阅读：计算机网络之应用层

• 关键词：HTTP、DNS、FTP、TELNET、DHCP
• 主要协议：HTTP、DNS、SMTP、Telnet、FTP、SNMP 等。
• 数据单元：报文（message）。

2. HTTP

扩展阅读：超文本传输协议 HTTP

3. DNS

扩展阅读：域名系统 DNS

4. TCP/UDP

扩展阅读：传输控制协议 TCP，用户数据报协议 UDP

4.1. 什么是 TCP？

TCP（Transmission Control Protocol），即传输控制协议，它是一种面向连接的、可靠的、基于字节流的传输层通信协议。

4.2. TCP 的特性是什么？

• 面向连接的 - 面向连接是指 TCP 需要通过三次握手、四次挥手原则建立和断开双向连接。
• 可靠的 - 可靠是指 TCP 传输的数据包保证以原始顺序到达目的地，且数据包不被损坏。为了实现这点，TCP 通过以下技术来保证：
  • 数据包的序列号和校验码
  • 确认包和自动重传
    • 如果发送者没有收到正确的响应，它将重新发送数据包。如果多次超时，连接就会断开。
    • TCP 实行流量控制和拥塞控制。这些确保措施会导致延迟，而且通常导致传输效率比 UDP 低。
• 基于字节流的
  • 虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序看成是一连串的无结构的字节流。TCP 有一个缓冲，当应用程序传送的数据块太长，TCP 就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP 也可以等待积累有足够多的字节后再构成报文段发送出去。
  • 在 TCP 建立连接前两次握手的 SYN 报文中选项字段的 MSS 值，通信双方商定通信的最大报文长度。如果应用层交付下来的数据过大，就会对数据分段，然后发送；否则通过滑动窗口来控制通信双发的数据。

4.3. TCP 三次握手

❓ 问题：三次握手有什么用？什么是三次握手？为什么需要三次握手？

（1）三次握手有什么用？

• 三次握手负责建立 TCP 双向连接。

（2）什么是三次握手？

1. 第一次握手 - 客户端向服务端发送带有 SYN 标志的数据包。
2. 第二次握手 - 服务端向客户端发送带有 SYN/ACK 标志的数据包。
3. 第三次握手 - 客户端向服务端发送带有带有 ACK 标志的数据包。

至此，TCP 三次握手完成，客户端与服务端已建立双向连接。

💡 说明：SYN 为 synchronize 的缩写，ACK 为 acknowledgment 的缩写。

（3）为什么需要三次握手？

为了便于说明，假设客户端为 A, 服务端为 B。

1. 第一次握手，A 向 B 发同步消息。B 收到消息后，B 认为：A 发消息没问题；B 收消息没问题。
2. 第二次握手，B 向 A 发同步消息和确认消息。A 收到消息后，A 认为：A 发消息、收消息都没问题；B 发消息、收消息都没问题。但是，此时 B 不确定自己发消息是否没问题，所以就需要第三次握手。
3. 第三次握手，A 向 B 发确认消息。B 收到消息后。B 认为：B 发消息没问题。

4.4. TCP 四次挥手

❓ 问题：四次挥手有什么用？什么是四次挥手？为什么建立连接是三次握手，关闭连接确是四次挥手呢？

（1）四次挥手有什么用？

• 四次挥手负责断开 TCP 连接。

（2）什么是四次挥手？

如上图所示，四次挥手流程如下：

（3）为什么建立连接是三次握手，关闭连接确是四次挥手呢？

• 建立连接的时候， 服务器在 LISTEN 状态下，收到建立连接请求的 SYN 报文后，把 ACK 和 SYN 放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的 FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送 FIN 报文给对方来表示同意现在关闭连接，因此，己方 ACK 和 FIN 一般都会分开发送，从而导致多了一次。

4.5. TCP 滑动窗口

❓ 问题：什么是滑动窗口？滑动窗口原理是什么？

什么是滑动窗口？

滑动窗口是 TCP 的一种控制网络流量的技术。

TCP 必需要解决的可靠传输以及包乱序（reordering）的问题，所以，TCP 必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包。

TCP 头里有一个字段叫 Window，又叫 Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

滑动窗口原理是什么？

4.6. TCP 重传机制

❓ 问题：为什么需要重传机制？TCP 有哪些重传机制，原理是什么？

TCP 要保证所有的数据包都可以到达，所以，必需要有重传机制。

TCP 重传机制主要有两种：

• 超时重传机制
• 快速重传机制

（1）超时重传机制

超时重传机制是指：发送数据包在一定的时间周期内没有收到相应的 ACK，等待一定的时间，超时之后就认为这个数据包丢失，就会重新发送。这个等待时间被称为 RTO(Retransmission TimeOut)，即重传超时时间。

没有确认的数据包不会从窗口中移走，定时器在重传时间到期内，每个片段的位置不变。

这种机制的重点是 RTO 的设置：

• RTO 设长了，重发就慢，丢了老半天才重发，没有效率，性能差；
• RTO 设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发

（2）快速重传机制

快速重传机制，实现了另外的一种丢包评定标准，即如果连续收到 3 次重复 ACK，发送方就认为这个 seq 的包丢失了，立刻进行重传。

当接收方收到乱序片段时，需要重复发送 ACK。

总结 6.824 Lab3A kvDB 的实验笔记。