一、引言

一次抽4 张扑克牌，有 30 万种组合，如果放回去后重新抽一次，将低于 1/300,000 的几率才能抽到相同组合的牌，几乎不可能了

二、概念

infima: infima provides a Lattice container framework that allows you to categorize each endpoint along one or more fault-isolation dimensions such as availability-zone, software implementation, underlying datastore or any other common point of dependency endpoints may share.(https://github.com/awslabs/route53-infima)

infima 提供了一种网格容器框架，允许沿着一个或多个故障隔离维度（可用区、软件实现、基础数据存储或者任何其他可能共享的公共依赖点）对每个端点做分类

compartmentalization aware: https://docs.mesosphere.com/cn/1.11/hybrid-cloud/features/fault-domain-awareness-with-zones/

每个地域包含许多不同的称为“可用分区”的位置，相同地域内可用分区之间内网互通，不同可用分区之间物理隔离。每个可用分区都被设计成不受其他可用分区故障的影响，并提供低价、低延迟的网络连接，以连接到同一地区其他可用分区。通过使用独立可用分区内的态势感知，可以保护您的应用程序不受单一位置故障的影响。

Rubbertrees:

类似ShuffleShards 的一种方法

三、传统的水平缩放

大部分服务通常运行在多个实例上，使用多个实例意味着我们可以拥有主动冗余：当一个实例出现问题时，其他实例可以接管。通常流量和请求都分布在健康的实例上。

尽管这种模式非常适合处理平衡流量和实例级别的故障，但如果请求本身有害的话会很糟糕，会影响每个实例。
如果该服务为多个客户提供服务，则一个忙碌的客户可能淹没其他的所有用户。基于每个用户限制请求可以提供帮助，但即使限流机制本身也会不堪重负。

再糟糕点，如果问题是一类“有毒请求”，限流将不会有帮助。如果某个特定请求触发一个bug 引起系统故障转移，则调用者可能通过反复尝试相同的请求触发级联故障，直到全部实例故障。这是最糟糕的情况，构建服务时应该极力避免这种情况发生。

四、分片与隔离

为了避免“有毒请求”把所有实例都弄烂，简单一点的方法就是直接把实例分组，切成不同的cell，两两成组。

这样遇到之前同样的影响，问题可以被控制在一个分片中，只对分布在同一分片的客户受到影响，这样对服务能力就有了 4 倍的改进，从对 100%的客户影响降至 25%。

如果客户或者对象被赋予特定的dns 名称，则可以使用dns 来保持每个客户在分片间干净地分离。（ps：从流量入口做分离）

五、随机分片

有了上面的概念，再理解 Shuffle Sharding 就不难了。我们不一定要让客户在固定的分组中，目标只是要分配客户 的请求到两个不同的实例上，通过随机的分配到不同的实例上。

通过从八个中选择两个实例，有 56 个潜在的随机分片，远超过我们之前使用的 4 个简单分片。起初，Shuffle Shards 貌似不太适合故障隔离，两个shuffle shards 共享实例 5，因此该实例的问题会影响两个分片。解决这个问题的关键是让客户端容错，通过客户端简单的重试策略，使其尝试shuffle shard 的每个节点，直到成功，我们将得到显著的隔离效果。

当客户端尝试shuffle shard 1 的每个实例的情况下，实际影响了实例 3、5。但shuffle shard 2 的客户如果重试的话几乎不受影响。因此实际影响被限制在整个shuffle shard 的 1/56。

相比 1/4 的影响已经是非常大的改进了，但我们可以做得更好。之前通过简单分片，我们需要对每个分片放置在两个实例获得冗余。随着shuffle sharding - 传统的 n + 1 水平缩放，我们有更多的实例可用。我们可以分片到尽量多的实例上去，因为我们愿意重试。通过三次重试，一个常见的重试值，我们可以使用四个实例来冗余每个shuffle shard 分片。

每次shuffle shard 有四个实例，我们可以将影响降低到总客户群的 1/1680，并使”noisy neighbor“ 问题更易于管理。（p.s.：1680 的计算来源？）

六、infima 与 随机分片

Route Infima 库包含两种Shuffle 分片。第一种是简单的无状态随机分片，无状态随机分片使用哈希（就像布隆过滤器那样）来获取用户、对象、或其他标识符将转化为随机分片模式。这种技术会导致客户间出现重叠的可能性。但通过无状态的shuffle 方式可以很容易地使用。

第二种是有状态搜索随机分片，这些shuffle shard 使用随机分配生成，但内置支持检查每个新生成的分片对每个先前分配的分片，以便保证重叠。例如：我们可能选择 20 个节点，但要求没有两个shuffle shard 共享两个以上的指定节点。

infima 的两种shuffle 分片策略都是分区感知的。例如，我们可以确保 shuffle 分片也使用每个可用区。所以我们的实例可以部署在 两个可用区域内，每个区域 4 个。infima 可以确保从每个区域内选择两个节点，而不是随机选择两个节点。

最后，infima 可以轻松地使用shuffe shard 和Rubbertrees。

七、引用

https://kkc.github.io/2019/03/04/AWS-Shuffle-Sharding/
https://aws.amazon.com/cn/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/
https://github.com/awslabs/route53-infima
图片均摘自：https://kkc.github.io/2019/03/04/AWS-Shuffle-Sharding/，侵删

---

如有不当之处，欢迎斧正~