标签：Shuffle 每个 infima AWS shard 实例 分片 Sharding shuffle
一、引言
一次抽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/，侵删
如有不当之处，欢迎斧正~
标签：Shuffle,每个,infima,AWS,shard,实例,分片,Sharding,shuffle 来源： https://www.cnblogs.com/gliu/p/11217683.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。