From 0ebbbe3e0c8386f1a355f95ea3c762393e8d7757 Mon Sep 17 00:00:00 2001 From: isno Date: Sun, 23 Jun 2024 14:24:50 +0800 Subject: [PATCH] =?UTF-8?q?=E5=BC=80=E5=A7=8B=E5=88=86=E5=B8=83=E5=BC=8F?= =?UTF-8?q?=E7=B3=BB=E7=BB=9F=E7=9A=84=E5=86=85=E5=AE=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- assets/balancer7.svg | 2 +- balance/balance4-ha.md | 12 ++++++------ balance/balance7.md | 12 +++++++----- distributed-transaction/ACID.md | 4 +++- distributed-transaction/CAP.md | 7 ++++--- 5 files changed, 21 insertions(+), 16 deletions(-) diff --git a/assets/balancer7.svg b/assets/balancer7.svg index e944f8eb..0527ac5d 100644 --- a/assets/balancer7.svg +++ b/assets/balancer7.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/balance/balance4-ha.md b/balance/balance4-ha.md index 1740c2c3..e1b77217 100644 --- a/balance/balance4-ha.md +++ b/balance/balance4-ha.md @@ -23,19 +23,19 @@ ## 2.一致性哈希容错方式 -接下来我们再看**基于集群的一致性哈希容错和可扩展设计方案**，它的工作原理如图 4-12 所示。 +接下来我们继续看**基于集群的一致性哈希容错和可扩展设计方案**，它的工作原理如图 4-12 所示。 :::center ![](../assets/balancer-ha-2.svg)
图 4-12 负载均衡一致性哈希容错和可扩展设计方案 ::: -1. 多个边缘路由器以相同的 BGP 权重通告所有 Anycast VIP，通过 ECMP（Equal-cost, Multi-path routing，等价多路由）保证每个 flow 的所有包都会到达同一个边缘路由器。 -2. 多个四层负载均起以相同的 BGP 权重向所有的边缘路由器通告所有的 VIP 继续使用 ECMP 的方式为相同 flow 的包选择相同的四层负载均衡器。 -3. 每个四层负载均衡器实例会做部分连接跟踪（conntrack）工作，然后使用一致性哈希为每个 flow 选择 一个后端。通过 GRE 封装将包从负载均衡器发送到后端。 -4. 然后使用三角传输模式将应答包从后端直接发送到边缘路由器，最后到客户端。 +- 多个边缘路由器以相同的 BGP 权重通告所有 Anycast VIP，通过 ECMP（Equal-cost, Multi-path routing，等价多路由）保证每个 flow 的所有包都会到达同一个边缘路由器。 +- 多个四层负载均起以相同的 BGP 权重向所有的边缘路由器通告所有的 VIP 继续使用 ECMP 的方式为相同 flow 的包选择相同的四层负载均衡器。 +- 每个四层负载均衡器实例会做部分连接跟踪（conntrack）工作，然后使用一致性哈希为每个 flow 选择 一个后端。通过 GRE 封装将包从负载均衡器发送到后端。 +- 然后使用三角传输模式将应答包从后端直接发送到边缘路由器，最后到客户端。 -可以看到以上的设计如何避免主备方式的不足： +综合上述，看看一致性哈希容错模式是如何避免主备方式的缺陷： - **边缘路由器和负载均衡器实例可以按需添加**。因为每一层都用到了 ECMP，当新实例加入的时候，能最大程度地减少受影响的 flow 数量； - 在预留足够的突发量和容错的前提下，系统的资源利用率想达到多高就可以到多高。 diff --git a/balance/balance7.md b/balance/balance7.md index 72d19d1c..de5cb2dd 100644 --- a/balance/balance7.md +++ b/balance/balance7.md @@ -6,19 +6,21 @@ 七层指的是类似 HTTP 这样的应用层协议，那就要把 TCP 数据传送到用户态中的程序处理，之后再用代理的方式新建一个请求到真实服务器。 ::: -如图 4-13 所示，一个七层 HTTP/2 负载均衡器，此时客户端（client）、负载均衡器（Load Balancer）、真实服务器（RealServer）的工作模式。 +如图 4-13 所示，一个七层 HTTP/2 负载均衡器，此时客户端（client）、负载均衡器（Load Balancer）、业务服务器（RealServer）的工作模式。 :::center ![](../assets/balancer7.svg)
图 4-13 七层负载均衡工作模式 ::: -此时，客户端与七层负载均衡器建立一个 HTTP/2 TCP 连接，负载均衡器根据负载均衡策略和两个后端建立了连接。当客户端向负载均衡器发送两个 HTTP/2 stream 时： +此时，客户端与七层负载均衡器建立一个 HTTP/2 TCP 连接，负载均衡器根据负载均衡策略和两个业务后端建立了连接。当客户端向负载均衡器发送两个 HTTP/2 stream 时： - stream1 会被发送到 RealServer1； - stream2 会被发送到 RealServer2。 -因此，即使不同客户端的请求数量差异巨大，这些请求也可以被平衡到各个后端。因为七层负载均衡具备检测应用层流量的能力，所以做出更多、更明智的决策，也能玩出更多的花样。 +因此，即使不同客户端的请求数量差异巨大，这些请求也可以被平衡到各个业务后端。因为七层负载均衡具备检测应用层流量的能力，所以做出更多、更明智的决策，也能玩出更多的花样。 -既然七层负载均衡的能力更强，**那是否意味着四层负载均衡已经没用了**？肯定不，几乎所有的现代大型分布式架构都是在公网流量入口使用 L4/L7 两级部署的原因是： +七层负载均衡的能力更强，**那是否意味着四层负载均衡已经没用了**？ -- 七层负载均衡承担的更多工作是复杂的分析、变换、以及应用流量路由，他们处理原始流量的能力（按每秒处理的包数和字节数衡量）比经过优化的负载均衡器要差。这使得四层负载均衡更适合处理特定类型的攻击，譬如 SYN 泛洪、通用包泛洪攻击等 +肯定不，几乎所有的现代大型分布式系统都使用 L4/L7 两级部署的原因是： + +- 七层负载均衡承担的更多工作是复杂的分析、变换、以及应用流量路由，他们处理原始流量的能力（按每秒处理的包数和字节数衡量）比经过优化的负载均衡器要差。这使得四层负载均衡更适合处理特定类型的攻击，譬如 SYN 泛洪、通用包泛洪攻击等； - 七层负载均衡部署的更多更频繁，bug 也比四层负载均衡多。在七层负载均衡之前加一层四层负载均衡，可以在调整七层负载均衡部署的时候，对其做健康检查和流量排除，这比单纯使用四层负载均衡要简单的多。 \ No newline at end of file diff --git a/distributed-transaction/ACID.md b/distributed-transaction/ACID.md index 8452a042..b6377785 100644 --- a/distributed-transaction/ACID.md +++ b/distributed-transaction/ACID.md @@ -14,6 +14,8 @@ 事实上对于一致性而言，A、I、D 是手段，C（Consistency）是三者协作的目标，弄到一块是为了读起来顺口。 ::: -当事务的影响范围局限在单机本地内的系统时，一致性通过编码实现起来水到渠成，但倘若事务修改的对象影响涉及外部，譬如跨越网络、跨越不同的数据源时，一致性问题通常很难再使用 A、I、D 来解决，但是外部一致性又是分布式系统中必然会遇到且必须要解决的问题，此时我们就要转变观念，**将一致性从“是或否”的二元问题转变为可以按不同强度分开讨论的多元问题，在确保代价可承受的前提下获得强度尽可能高的一致性保障**。一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。 +当事务的影响范围局限在单机本地内的系统时，一致性通过编码实现起来水到渠成，但倘若事务修改的对象影响涉及外部，譬如跨越网络、跨越不同的数据源时，一致性问题通常很难再使用 A、I、D 来解决，但是外部一致性又是分布式系统中必然会遇到且必须要解决的问题，此时我们就要转变观念，**将一致性从“是或否”的二元问题转变为可以按不同强度分开讨论的多元问题，在确保代价可承受的前提下获得强度尽可能高的一致性保障**。 + +一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。 人们在探索这些架构的设计时产生了诸多思路和理论，这其中最为出名的就是一致性与可用性的权衡定理 —— CAP 定理。 \ No newline at end of file diff --git a/distributed-transaction/CAP.md b/distributed-transaction/CAP.md index 377387a3..7c9f6067 100644 --- a/distributed-transaction/CAP.md +++ b/distributed-transaction/CAP.md @@ -7,8 +7,7 @@ CAP 是分布式系统中**关于一致性与可用性的权衡理论**，也是 虽然 Eric A.Brewer 提出了 CAP，但此时的 CAP 仅是一种猜想，并没有被从理论上证明。2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 联合发表了一篇论文[^3]，用严谨的数学推理证明了 CAP 的正确性，此后 CAP 从原理转变成定理，并开始在分布式系统领域产生深远的影响。 :::center - ![](../assets/cap-theorem.png) - + ![](../assets/cap-theorem.png)
图 5-1 CAP 定理 ::: @@ -34,7 +33,9 @@ CAP 定理描述的是**一个分布式系统中，涉及共享数据问题时 但无论如何，我们设计系统终究还是要确保操作结果至少在最终交付的时刻是正确的，这个意思是允许数据中间不一致，但应该在输出时被修正过来。 -为此，工程师们又重新给一致性下了定义，**将 CAP、ACID 中讨论的一致性称为强一致性，而把牺牲了 C 的 AP 系统但又要尽可能获得正确结果的行为称为追求“弱一致性”**。不过，如果只单纯说“弱一致性”，那其实就是不保证一致性的意思。在弱一致性里，工程师又总结出稍微强一点的特例，被称为最终一致性（由 eBay 的系统架构师 Dan Pritchett 在 BASE 理论提出）。 +为此，工程师们又重新给一致性下了定义，**将 CAP、ACID 中讨论的一致性称为强一致性，而把牺牲了 C 的 AP 系统但又要尽可能获得正确结果的行为称为追求“弱一致性”**。 + +不过，如果只单纯说“弱一致性”，那其实就是不保证一致性的意思。在弱一致性里，工程师又总结出稍微强一点的特例，被称为最终一致性（由 eBay 的系统架构师 Dan Pritchett 在 BASE 理论提出）。 :::tip 额外知识 ACID 在英文中有的“酸”的含义，对应系统设计的强一致性，而 BASE 在英文中有“碱”的含义，对应系统放弃强一致性实现可用性的设计。酸 vs 碱衍生出 CAP 中的 AP 型可用性架构和 CP 型强一致性架构，所以 CAP 理论又戏称度量分布式系统的“Ph试纸”。