挑战
与技术领导者和建筑师谈论蜻蜓的垂直缩放模式时，我经常遇到最初的怀疑态度：而在大规模管理Redis的团队往往会因高度维护开销而面临困难，而不是每个人最初都抓住龙蝇的多线程和垂直缩放能力，可以解决他们的生产问题和降低成本和成本。
他们的论点通常如下：
“令人印象深刻的是，您可以在单个实例上实现1M QP，但是我可以在集群模式下仅部署32个单个CPU VM，并获得更大的吞吐量。实际上，您的单节点体系结构本质上是有限的，而水平可伸缩性是无限的”
这个论点没有错。垂直缩放永远不会完全是线性的，因为必须花费一些努力来坐标线，并且水平缩放确实可以使用可比数量的CPU实现更高的吞吐量。此外，水平缩放是无限的，而垂直缩放是有界的。实际上，当处理大量实例大小（64个CPU或更多）时，随着服务器网络限制的到来，其缩放效率往往会迅速下降。 但是，此参数重点关注单个度量 - 吞吐量。它不考虑的是水平缩放对群集可靠性的影响。此外，他们吹捧的吞吐量指标取决于对群集性能的某些假设。在这篇博客文章中，我将水平缩放通常在雷达下飞行，从而提供一些问题，从而使水平缩放的无敌和垂直缩放不好的说唱。 在我们深入研究水平缩放分析之前，您可能会发现阅读有关memory-bounded workloads的其他博客文章很有用。 （tldr：对于结合内存的工作负载，垂直缩放节省了内存，因为我们不需要保持过度提供的边距与多碎片群一样大） DataStores作为状态群集运行。要检索键{y}，必须访问shard x， 这与无状态系统（例如Web前端）有所不同，Web前沿所有节点都是可互换的。如果在这些系统中节点离线，则流量将转移到其他节点，从而导致集群容量的真正集合。 下面我们讨论了在增加簇大小的同时如何减小节点大小会导致效率低下和群集不可用的机会更高的机会。 更大的簇更脆弱 在生产系统的世界中，故障是固有的可能性。无论是主机故障，生产环境的变化，突然的交通尖峰还是软件错误，任何系统都不适应这些挑战。这意味着我们应该考虑到失败的设计系统，并且在这样的决策框架下，我们将达到不可避免的结果：集群中的节点越多，其中一个失败的机会就越高。
让我们定义$$ p_ {f} $$作为节点故障概率，然后节点livese的概率由$$ 1-p_ {f} $$表示。当我们通过增加碎片数（n）来扩展群集时，可以将整个群集livices计算为$$（1-p_ {f}）^{n} $$。因此，群集的可用性随着群集大小的增长而呈指数下降。公平地说，我们假设我们在一个在稳定环境中工作的正确设计的系统操作。在这种情况下，$$ p_ {f} $$的值往往很小。因此，我们可以进行近似值并表示$$（1-p_ {f}）^{n} $$ as $$（1-np_ {f}）$$。但是，即使使用此近似值，也很明显群集的可用性相对于集群大小线性降低。 您的节点容量必须比您想象的要大 在管理生产中的水平可扩展群集时，一个常见的观察结果是，每个服务器上的负载很少均匀。某些服务器可能会大量超载，达到90％或更高的利用率，而另一些服务器可能以更轻松的50％容量运行。此外，经历最高和最低负载的服务器会随着时间的流逝而变化。这种变化是如何在群集碎片上分布负载的直接结果，尤其是在将请求定向到托管相关数据的服务器的状态系统中。不平衡的数据分布模式甚至会导致热键的出现，加剧负载不平衡。为了有效处理潜在的载荷尖峰，必须根据其最大预期负载来提供每个碎片， 较小的节点过度提供的边缘。 让数学备份备份这一主张。假设我们使用每秒维持1M请求的单个服务器，每个请求平均使用0.1ms的CPU时间使用。服务器上的负载为$$ L = 1000000*0.0001 = 100 $$。经典的queuing theory说，我们必须为服务器提供支持$$ l +（L）$$或在这种情况下具有10％的利润。现在假设，而不是使用单个服务器，而是提供100片群集。每个碎片平均要维持10k Qps（100倍），其负载将为$$ l _ {\ text {shard}} = 10000 \ times 0.0001 = 1 $$，但是，对于稳健而顺利的经验，我们需要为$$ l _ {\ text {shard}} + text $ text}提供$$ l _ { ％保证金！ 您的每个节点的吞吐量都不会像您想象的那样多，因为云量过高 当我们在云中分配一个小的单CPU VM时，我们将无法获得保证的吞吐量。相反，我们共享该服务器上所有VM之间的资源。如果主机利用不足，云可能会暂时为我们提供更多的网络带宽。但是，不能保证此吞吐量。一旦一个嘈杂的邻居跳上主机，它可能会从我们的VM中取宽一些。如您所见，最佳情况和最坏情况之间的区别很大。 我们进行了以下实验以证明它： 这是有趣的部分。原始Redis服务器的流量下降了 总结这三个点，水平缩放是达到分布式系统高度可扩展工作负载的重要技术。但是，在小实例中水平扩展可能会导致生产环境中的不稳定，并且由于节点能力的积极性过度提供的基础设施成本更高。 蜻蜓是一种替换式替换，与Redis不同，它垂直缩放。数百万QP或最多1TB数据的工作负载可以在所有主要云上的一个蜻蜓实例上运行。 据我们所知，蜻蜓是唯一的成本效益且维护良好的源可用技术，可以从开箱即用。单个蜻蜓实例与重新使用实例的群集一样强大，比负载更具可预测性，并且比托管Redis服务更具成本效益。通过在选择云上的正确实例类型上部署community edition蜻蜓，与替代品相比，您可以将基础架构成本降低2-3倍。 DragonflyDB Cloud（我们的托管服务）将支持任何大小的水平可扩展群集。 Dragonflydb Cloud旨在提供世界上最可靠，最具成本效益的内存服务。
-Hidden Hidden Hushdles的水平缩放障碍
这意味着集群容量在碎片之间被划分。当将所有碎片一起使用时，就可以使用状态系统。这意味着每个碎片过载可以独立地渲染整个群集。
vms运行redis服务器到同一主机，并同时将流量发送给所有人。
m5.large VM部署到了我们的保留主机中，并在此启动了一个单线REDIS服务器。 Redis服务器上达到153K QPS。
从153K QPS到18.5k QP-惊人的8.3倍！
主机上所有REDIS服务器的总吞吐量为890K QP，而不是73m，因为人们可以期望第一个实验会插值结果。顺便说一句，当我们加载在 m5.24xlarge 的所有资源上测试一只蜻蜓时，它达到了1M
QPS，这与该主机上48个Redis服务器相一致。
尺寸垂直与蜻蜓