Redis 8 已发布，它是开源的
了解更多
分享
大约在 18 个月前，我们迈出了第一步，自那以后，这被证明是一段狂野而令人兴奋的旅程。对于不了解情况的局外人来说，云服务提供商的存在可能看起来枯燥乏味、波澜不惊。然而，任何不懈地寻找那个能够统治一切的平台调整的人；任何追溯难以捉摸的（吞吐量）之河流动的人；任何勇敢地与多头九头蛇（又称 Ssssp-lit）战斗的人，都会讲述一个不同的故事。
这是一个美妙而充满冒险的世界，在这个世界里，没有什么是确定的，只有一个真理：使用私有网络接口，也就是私有 DNS，总是更好的选择。至少我们曾经如此认为。
从那以后，我们发现了并非如此，但首先让我们回顾一下过去…… 在遥远的时代，在虚拟化黎明和云时代之前，服务器是物理对象，是由零部件组成的机器，协同工作以进行计算。随着网络的出现和发展，私有网络和公共网络之间产生了明确的分隔。私有网络的特点是使用自己的地址空间，仅对直接连接到它们的服务器可见，并且通常是本地化的。公共网络，顾名思义，是全球性的，对任何人开放。
这种网络之间的基本区别很好地反映了它们各自所扮演的角色。公共网络用于向其消费者提供系统的服务，而私有网络则用于内部连接系统的组件服务器。此外，考虑到它们的性质和位置，私有网络通常被认为比其公共网络对应方更安全、更快、更便宜、更可靠且带宽更高。然后服务器升维，从而变成了云。
在它们新获得的虚幻存在中，服务器抛弃了物理属性，取而代之的是虚拟化的替代品。不再有服务器，现在取而代之的是实例。实际的 CPU 和核心不见了，取而代之的是计算单元和 vCPU。硬盘消失了，取而代之的是临时存储和“网络附加持久存储”。甚至网络接口也被剥夺了物质实体，取而代之的是“与实例关联的 IP 地址”。但我们仍然认为私有 IP 地址对于系统内部通信更可取，而且简直非常棒。但随着时间的推移，经验告诉我们并非如此。
在我们服务的开发和测试过程中，我们花费了无数时间试图定义和重现一个特别棘手的“幽灵”问题。我们最终设法捕获了它，并了解到了以下情况：AWS 的私有地址有时比公有地址更糟！
一旦确定了问题，我们就能够轻松并反复地展示这种行为。上图是一个实时记录的图示，显示了一个简单应用程序连接到我们的一个 Redis Cloud 实例所需的时间。该应用程序使用两个线程，一个连接到公有地址，另一个连接到私有地址。一旦两个连接都建立完成，应用程序会将每个连接完成所需的时间写入该实例并重新启动。
请注意，客户端每次重启后，在大多数情况下，连接到私有地址所需的时间比连接到公有地址要长得多，有时甚至是几个数量级，并且很少能像连接到公有地址那样快。虽然这些症状很容易展示出来，但这种行为的原因更难解释。我们怀疑这种不受欢迎的行为至少部分是由于私有接口所获得的额外保护造成的。由于 AWS 使用基于软件的防火墙来保护私有实例，前者可能因为需要强制执行的规则过多而迅速不堪重负。这种负载不一定是由特定的 EC2 实例（在我们的测试中，我们使用了不到 10 个安全组）产生的，而是由许多在 AWS 网络中共享同一防火墙的 EC2 实例产生的。
一旦负载过高，防火墙可能会引入延迟，甚至阻止连接尝试。如上所示，当使用 PaaS 部署应用程序时，可以可靠地重现这种现象。有趣的是，独立 EC2 用户遇到这种情况的可能性要小得多。
因此，我们对 PaaS 用户的结论和一贯建议是：避免使用私有接口，转而使用公有接口——后者可能会引入高达一毫秒的延迟，但至少它比私有接口表现得更稳定。好了，这就是我们的发现，又一天，又一个迷思被打破了。
