Amazon在2021年9月从部分地区推出了Amazon MemoryDB for Redis。

使用费用

我已经与AWS Elastic Cache for Redis进行了比较，并从公式文档中得知，在MemoryDB中，东京地区的使用费用也已公开。

亚马逊云缓存（Amazon ElastiCache）的价格
https://aws.amazon.com/zh/elasticache/pricing/

Amazon MemoryDB for Redis 定价
https://aws.amazon.com/cn_jp/memorydb/pricing/

ノード

当比较具有相同规格的单节点的价格时，可以看出MemoryDB每小时比ElastiCache高约$0.124 。此外，只有ElastiCache支持预留节点，而MemoryDB仅支持按需节点。

スナップショット

MemoryDB的快照是指整个集群的副本。
在MemoryDB集群所在的区域内，只有当存储总量达到100％时才会产生快照的额外费用。如果存储持续时间为1天，则不会产生快照的额外费用。
额外的快照存储将按照每GB每月$0.023的存储费用计费。

在这方面，ElastiCache可以为每个集群提供免费的自动和手动快照存储空间，但额外的备份存储可能需要约0.085美元/GB-月。根据情况来看，似乎ElastiCache的费用较高。

Redis的ElastiCache

在进入MemoryDB之前，我们需要考虑ElastiCache for Redis的配置。ElastiCache for Redis将节点作为缓存服务器，并采用多种不同的配置。

碎片

• 複数ノードをもつ集合体を一つのグループとして定義します。

このグループには、読み書き可能な Primaryノードと 読み取り専用の Replica ノード(0~5ノードまで)が属します。

集群

• シャードをまとめたグループです。

• クラスターモードと呼ばれ、無効化する事も可能です。クラスタモードが無効な場合、Redis は１つのシャードで構成されます。

クラスターが有効な場合、シャードを最大で500個まで増やす事が可能で、シャードの数が多いほどデータの分散化が可能です。クラスタは2つのサブネット(AZ)が必要となり、クラスターモードが無効でもシャードを介したレプリケーション自体はサポートされます。

Redis 复制组

复制组是按照前面所提到的以下结构进行复制的组单位。

クラスタが無効化の状態ですべてのデータが単一シャードに含まれているケースでは、1 つの Primary ノードと、最大5個のReplicaノードで構成され、Replicaノードは、クラスターのプライマリノードにあるデータのコピーを非同期レプリケーション機能により保持します。

当出现障碍时的流程

这是当主要节点发生故障时的处理过程。

クラスタが無効な場合

① ElastiCache会在主节点上检测到故障。
② ElastiCache会将主节点设置为离线状态。
③ ElastiCache会创建并配置一个新的主节点，以替换失败的主节点。
④ ElastiCache会将新的主节点与现有的备份节点之一进行同步。
⑤ 同步完成后，新节点将成为集群的主节点。

在这个过程的步骤完成之前，应用程序无法将数据写入主节点。然而，应用程序可以继续从副本节点读取数据。

クラスタ有効化の場合

①ElastiCache检测到Primary Node的故障。
②将延迟最小的Replica Node提升为Primary Node。
③将其他副本与新的Primary Node进行同步。
④启动故障发生的Primary Node的AZ中的Replica Node。
⑤新节点与新晋升的Primary Node同步。

故障转移到复制节点通常比创建和供应新的主节点更快。这意味着，相比不启用多可用区，应用程序可以更快地恢复对主节点的写入。

亚马逊MemoryDB for Redis

对比ElastiCache for Redis。

在MemoryDB中，Redis集群是必需的配置。

除此之外，配置方面没有很大的区别。

在考虑节点布置时，需要选择每个集群的分片数量和副本数量。

障碍时的过程

当MemoryDB节点发生故障时的处理过程。与ElastiCache的行为有些不同。

リードレプリカ

①MemoryDBがreplica Nodeの障害を検出します。
②MemoryDBは対象Replica NodeのをOFFLINEにします。
③MemoryDBは、同じAZで代替ノードを起動してプロビジョニングします。
④新しいノードは、トランザクションログと同期します。

この間、アプリケーションは他のノードを使用して読み取りと書き込みを継続できます。

プライマリー

①MemoryDB がPrimay Nodeの障害を検出します。
②MemoryDB は、障害が発生したプライマリとの整合性を確認した後、レプリカにフェイルオーバーします。
③MemoryDBが故障したプライマリのAZにレプリカをスピンアップする。
④新しいノードは、トランザクションログと同期します。

レプリカノードへのフェイルオーバーは、通常、新しいプライマリノードを作成してプロビジョニングするよりも高速です。つまり、アプリケーションはより早くプライマリノードへの書き込みを再開することができます。

我们来使用它

$ sudo yum -y install openssl-devel gcc
$ wget http://download.redis.io/redis-stable.tar.gz
$ tar xvzf redis-stable.tar.gz
$ cd redis-stable
$ make distclean
$ make redis-cli BUILD_TLS=yes
$ sudo install -m 755 src/redis-cli /usr/local/bin/

连接到Redis时，请使用以下命令。

redis-cli -h <Cluster Endpoint> --tls -p 6379　-c

数据已经成功添加。

set test2 2
-> Redirected to slot [8899] located at memorydb-redis-cluster-0002-001.memorydb-redis-cluster.xxxx.us-east1.amazonaws.com:6379
OK

似乎无法确认设置文件（config）的存在。

> config *
(error) ERR unknown command `config` 

似乎不能使用bgsave或AOF。

> bgsave
(error) ERR unknown command `bgsave`

> bgrewriteaof
(error) ERR unknown command `bgrewriteaof`, with args beginning with: 

暂时放弃了，因为我找不到方法来故意使正在写入的主要节点发生故障，并确认故障转移后的事务没有差异。

易用性

从文档中可以看到，为了确保所有节点的一致性，在发生故障时不会丢失数据。但是，关键的事务日志无法从MemoryDB的界面中查看，而且在S3或Cloudwatch中也没有找到，因此无法具体可视化其存储位置。

根据任意时间点的快照恢复似乎是可行的，但似乎无法使用PITR（点时间恢复）。

考虑

让我们考虑选择MemoryDB for Redis的好处。

MmoryDBは処理をMulti-AZ トランザクションログ で管理し、データの書き込み操作が成功すると、クライアントに戻る前に分散したMulti-AZトランザクションログに永続的に保存されます。

• Primaryノードに対する読み込み操作は、それ以前に成功したすべての書き込み操作の影響を反映して、常に最新のデータを返すプロセスとなっているようです。

この観点からトランザクションログが先行してデータの整合性を保持しているため、ノードダウンによる、データロストが無い、あるいは一貫性が保たれるという事が考えられます。

在Redis中，ElastiCache必须采取多个不同的配置来最小化数据丢失，并通过减少故障来保持稳定。这一点在文档中有所描述。

考虑到ElastiCache无法确保事务的一致性，存在数据丢失的可能性，为了最小化这种风险，我认为需要进行一种配置，即会对成本和性能产生影响。

我认为，从数据丢失和故障风险的角度来看，MemoryDB for Redis可能会比ElastiCache for Redis略有延迟并且运营成本较高，但仍然存在选择这个方案的条件。

然而，由于验证不足且发布时间还很短而且信息也很少，因此我们希望在接下来的过程中进行信息收集以做出选择。

附录

根据从ElastiCache for Redis获取的快照（.rdb文件），可以将其作为MemoryDB进行恢复。经过比较后发现，迁移也是可行的。

文献引用

Amazon MemoryDB for Redis Developer Guide