Shopify 的基础设施为数百万商家的创业之旅提供支持。当前基础设施的一个关键组成部分是底层的 MySQL 数据库分片，它们共同保存每个商店的关键数据。随着流量模式的变化和新商家加入平台，资源密集型商店有可能最终生活在同一个分片中。某些数据库分片在其数据库利用率、商店流量和负载方面变得不平衡。重要的是要确保分片保持良好平衡，以降低数据库故障的风险，提高更广泛基础设施的生产力，并最终保证买家始终可以访问他们最喜欢的商店。
要全面了解分片平衡，简要回顾一下 Shopify 的架构会有所帮助。Shopify 的应用程序运行时目前是poded：基础设施由许多pod 组成（不要与Kubernetes Pods 混淆）。Pod 是 Shopify 的一个独立实例，由一个单独的 MySQL 数据库分片以及其他数据存储（如 Redis 和 Memcached）组成。每个 pod 都包含平台上独特的商店子集。商店的 Web 请求由负载均衡器处理，该负载均衡器查询路由表并将请求转发到基于商店的正确 Pod。
分片数据库拓扑支持 Pod 应用程序运行时：每个 Pod 由其自己的分片组成。Shopify 的数据模型非常适合这种拓扑结构，因为它shop是大多数数据模型的标识实体。我们可以将 a 附加shop_id到所有商店拥有的表，并将其用作分片键。将商店从一个分片移动到另一个分片涉及从所有表中选择所有具有所需记录的记录shop_id并将它们复制到另一个 MySQL 分片。对于这篇文章，将每个 pod 视为一个 MySQL 分片会很有帮助。
分片再平衡策略
当新商家在平台上注册并加入时，他们会被分配到任意一个分片。随着时间的推移，这些商家的规模不断扩大。某些资源密集型商店可能最终生活在相同的分片中，导致某些分片的数据库使用率较高而其他分片的数据库使用率较低。数据库使用中的这些不一致削弱了基础设施，原因有两个。首先，高流量分片由于可能过度使用而面临更大的故障风险。其次，数据库使用率低的分片没有得到有效使用。
为了平滑分片之间的负载，我们需要重新平衡它们。我们将平衡的基础架构定义为所有 pod 都健康且其分片得到有效利用的基础架构。为了实现这种平衡的基础架构，我们需要一种策略来实现跨分片的商店的持续重新分配。
在设计这种分片平衡策略时，很明显有两个问题需要解决：
- 哪些商店应该住在哪些分片中？
- 商店如何在尽可能少的停机时间的情况下从一个分片转移到另一个分片？
哪些商店应该住在哪些碎片中？
根据商店数量在分片上分布商店并不是一个好的策略，因为每个商店中的数据大小各不相同。以前使用的一种策略是分析分片的历史数据库利用率和流量数据，并根据它们的使用模式（即high_traffic, low_traffic，等）创建分类。适用的商店在这些分片队列之间迁移，使用的方案是将每 N 家商店从一个high_traffic分片移动到另一个分low_traffic片。拟议的举措进行了模拟，其预测效果用于验证假设。
虽然这种策略很有效，但它并不是唯一的策略。放置策略可以任意复杂并优先考虑不同的指标（例如，商店规模、GMV、移动时间、闪购等）。通常会提出多个假设并根据最新数据进行检验。一旦确定了理想的商店分布，就会生成一个商店移动列表，以实现我们系统的理想状态。
商店如何移动？
了解哪些商店需要在哪些分片中居住后，移动商店的过程就可以开始了。当我们很快布局时，将商店从其源分片移动到所需的目标分片可能是一个复杂的过程。由于对我们使用的策略施加了一些关键限制，因此它特别令人感兴趣。
- 可用性：商店搬家必须完全在线。这确保商家和更广泛的平台不会招致明显的停机时间。当数据从源数据库分片移动到目标数据库分片时，商家的店面必须可以进行交互。
- 数据完整性：移动过程中没有数据丢失或损坏。该过程必须确保将移动开始时存在的所有数据复制到目标分片。此外，它必须确保复制自移动开始以来对源数据库的所有写入。
- 吞吐量：将数据从一个分片移动到另一个分片的过程必须及时，并允许合理的吞吐量。商店规模各不相同，因此一次迁移其中许多商店不应对基础设施造成过度压力。
为了帮助描述店铺移动，我们定义了一个虚构的场景：Paarth 的 Peppy Peppers和Xiaoli 的 Xylophones是我们平台上的两个高流量商家。这两家商店目前都在 Pod 1 上。我们的数据科学与工程团队得出结论，将这两个商家放在同一个 pod 上并不是最佳选择。数据库利用率极高，来自这两家商户的突发流量是同步的。Paarth和小丽好像是同一天限时抢购哦！该团队建议将Paarth 的 Peppy Peppers移动到 Pod 2。我们将探索Paarth 的 Peppy Peppers如何进入 Pod 2 的端到端过程。
详细点击标题