现已上线：Amazon ElastiCache Global Datastore for Redis

Original URL: https://amazonaws-china.com/cn/blogs/aws/now-available-amazon-elasticache-global-datastore-for-redis/

内存数据存储早已在应用程序可扩展性领域发挥重要作用，而开发人员也意识到这项技术在存储高频访问数据（包括易失性与持久性数据）方面的巨大优势。以Redis为代表的各类系统能够有效将数据库/后端与传入流量剥离开来，显著降低流量水平，并借此改善应用程序给用户带来的延迟体验。

很明显，管理这些服务器本身也是一项核心任务。无论发生何种情况，我们都必须小心谨慎以保持其正常运行。在之前的项目中，我所在的团队曾负责在不同托管设施之间迁移一组物理缓存服务器。具体来讲，我们需要将每一台缓存服务器分别接入外部电池、拔掉电源、拆下机架、使用手推车将其移至新的机房，然后从头开始重复新的搬运过程。值得庆幸的是，整个过程中没有出现任何服务中断问题，工作完成后每个人都松了一口气……相信大家也很清楚，在高流量平台上丢失缓存数据是件多么恐怖的事。更值得庆幸的是，如今我们有了更加灵活的云基础设施。为了帮助用户尽可能减少由突发事故造成的服务中断，我们为Amazon ElastiCache（AWS专为Memcached与Redis打造的内存内数据存储服务）添加了多项高可用性功能，具体包括集群模式以及带有故障转移机制的多可用区方案等等。

当下，众多组织都在利用Redis为全球用户提供低延迟流量；因此AWS的客户向我们反映称，他们希望能够在不同AWS区域之间复制Amazon ElastiCache集群。我们听到了客户的声音，着手进行研发，并正式宣布这一复制功能已经在Redis集群上正式推出。

关于Amazon ElastiCache Global Datastore For Redis

简而言之，Amazon ElastiCache Global Datastore for Redis允许大家将某一区域内的集群复制到最多两个其他区域的集群当中。客户选择这种操作的常见诉求包括：

• 缩短缓存数据与用户之间的地理距离，借此降低网络延迟并提高应用程序的响应速度。
• 如果某一区域部分或者完全瘫痪，则可借此建立灾难恢复功能。

设置全局数据存储非常简单。首先，我们指定某一集群作为接收应用程序写入操作的主集群——这个主集群可以是新建集群，也可以是现有集群，唯一的要求就是其必须运行有Redis 5.06或者更高版本。接下来，您可以在其他区域当中添加最多两个从集群，用于从主集群处接收更新。

这样的设置适用于除单节点集群之外的所有Redis配置形式；当然，大家也可以将单节点集群转换为复制组集群，而后将其作为主集群使用。

同样重要的是，这样的集群设置允许用户依照原有习惯对全局数据存储中的各集群进行修改与大小调整（包括添加或删除节点、变更节点类型、添加或删除分片、添加或删除副本节点等）。

下面我们通过快速演示具体进行解释。

跨区域复制Redis集群

下面，我们共同来看如何从头开始构建一套包含三个集群的全局数据存储体系：主集群将位于us-east-1区域，两个次集群则分别位于us-west-1与us-west-2区域。为了简单起见，我们在所有集群中使用相同的默认配置：三个cache.r5.large节点、多可用区、单一分片。

下面前往AWS Console，在这里点击“Global Datastore”，而后点击“Create”以创建我的全局数据存储。系统询问我是否要创建一个支持数据存储的新集群，抑或是使用现有集群。我选择前者，并创建出一个名为global-ds-1-useast的新集群。

接着点击“Next”，填写细节信息在us-west-1区域中托管一个从集群。为了与主集群保持统一，我将其命名为global-ds-1-us-west1。

接下来，我在us-west-2区域内添加另一个次集群，命名为global-ds-1-uswest2：前往“Global Datastore”，点击“Add Region”，而后填写集群细节信息。

等待一会，三个集群全部正常启动，并与全局数据存储顺利关联起来。

在us-east-1区域上托管的Amazon Elastic Compute Cloud（EC2）实例上运行redis-cli客户端，我们可以快速接入集群端点并检查其是否开始正常运行。

[us-east-1-instance] $ redis-cli -h $US_EAST_1_CLUSTER_READWRITE
> ping
PONG
> set paris france
OK
> set berlin germany
OK
> set london uk
OK
> keys *
1) "london"
2) "berlin"
3) "paris"
> get paris
"france"

到目前为止，一切顺利。现在，我们使用托管在us-west-1区域上的EC2实例以检查存储在主集群内的数据是否被成功复制到us-west-1次集群当中。

[us-west-1-instance] $ redis-cli -h $US_WEST_1_CLUSTER_READONLY
> keys *
1) "london"
2) "berlin"
3) "paris"
> get paris
"france"

很好。现在，我们向主集群中添加更多数据……

> hset Parsifal composer "Richard Wagner" date 1882 acts 3 language "German"
> hset DonGiovanni composer "W.A. Mozart" date 1787 acts 2 language "Italian"
> hset Tosca composer "Giacomo Puccini" date 1900 acts 3 language "Italian"

……而后尽快检查次集群。

> keys *
1) "DonGiovanni"
2) "london"
3) "berlin"
4) "Parsifal"
5) "Tosca"
6) "paris"
> hget Parsifal composer
"Richard Wagner"

看起来同步速度很快：在切换至另一终端并运行命令时，可以看到新数据已经存在。其实这样的同步速度非常正常，跨区域流量的典型网络延迟一般在60毫秒至200毫秒之间（具体取决于所用区域）。

现在，如果位于us-east-1的主集群发生故障了怎么办？我们可以轻松地将其中一个从集群提升为主集群来提供完整的读写能力。

为了更好地进行检测，我还将us-east-1集群从全局数据存储中彻底删除。在删除完成后，全局数据存储如下所示。

现在，在us-west-1区域内使用我的EC2实例并接入至集群内的读取/写入端点，添加更多数据……

[us-west-1-instance] $ redis-cli -h $US_WEST_1_CLUSTER_READWRITE
> hset Lohengrin composer "Richard Wagner" date 1850 acts 3 language "German"

……而后检查，发现新数据已经被成功复制至us-west-2集群。

[us-west-2-instance] $ redis-cli -h $US_WEST_2_CLUSTER_READONLY
> hgetall Lohengrin
1) "composer"
2) "Richard Wagner"
3) "date"
4) "1850"
5) "acts"
6) "3"
7) "language"
8) "German"

到此结束，圆满成功！全局数据存储确实让Amazon ElastiCache数据的跨区域复制变得简便易行！

已经上线！

这项新的全局数据存储功能目前已经在美国东部（北弗吉尼亚州）、美国东部（俄亥俄州）、美国西部（北加利福尼亚州）、美国西部（俄勒冈州）、亚太（韩国首尔）、亚太（澳大利亚悉尼）、亚太（新加坡）、亚太（东京）、欧洲（德国法兰克福）、欧洲（爱尔兰）、欧洲（英国伦敦）等区域上线。感兴趣的朋友可以立即体验，或者通过AWS Amazon ElastiCache分论坛/AWS客户服务人员与我们沟通或提出反馈意见。

本篇作者