想象一下，我有一个称为 VPC vpc-1，它有一个与之关联的 Memorystore (Redis) 实例。我的理解是 Redis 存在于它自己的 VPC 中，并且有 VPC 对等互连用于连接vpc-1到 Redis 的 VPC。现在让我们想象一下，我创建了第二个 VPC vpc-2，并将该 VPC 与vpc-1. 我现在创建一个带有网络接口的虚拟机到vpc-2. vpc-1此 VM 现在可以访问附加到和的VPC 资源vpc-2。但是，由于 VPC 对等互连不具有传递性，因此 VM 无法访问 Redis 实例。
我的困惑现在变成了……连接到vpc-2VPC的 VM 是否有可能vpc-1与其关联的 Memorystore (Redis) 实例 ( vpc-1) 访问该 Redis 实例？
我意识到我可以切换我的故事以使用共享 VPC ......但是我想知道如果我想专门使用 VPC 对等互连有哪些选择。
在与非常了解 GCP VPC 和 GCP Memorystore 的技术人员讨论之后，似乎无法使用 VPC Peering 实现传递对等。有人提出了一个解决方案，对于我的用例来说，效果很好。关于最初的故事，我们在vpc-1VPC 中创建了一个新的 Compute Engine，它可以访问 Redis。在那个 Compute Engine 上，我们安装了一个名为nutcracker的开源包，它提供了一个 Redis 代理。这意味着发送到此计算引擎的 Redis 客户端请求通过 Memorystore 代理到由 Google 管理的真实 Redis 服务器。由于 Compute Engine 是 VPC 中的普通计算资源，vpc-1它的内部 IP 地址可以从与之对等的其他 VPC 访问vpc-1（例如，在我们的故事中）vpc-2）。最终结果是，在其中创建的 Compute Enginevpc-2可以针对nutcracker使用 Redis 协议运行的 Compute Engine。然后，该 Compute Engine 将请求中继到真正的 Redis 服务器，一切都按预期工作。
我有类似的设置相同的情况。经过一些研究，我发现了一些建议，例如 Kolban 关于使用 twemproxy（胡桃夹子）的建议。您还可以在 Google 的文档中找到这种情况：
https://cloud.google.com/blog/products/databases/running-redis-on-gcp-four-deployment-scenarios