条条大路通罗马 —— 使用 Go-Redis 连接 Amazon ElastiCache for Redis 集群

# 一、前言 [Amazon ElastiCache](https://aws.amazon.com/cn/elasticache/?trk=cndc-detail) 是一种 Web 服务，可让用户在云中轻松设置、管理和扩展分布式内存数据存储或缓存环境。它可以提供高性能、可扩展且具有成本效益的缓存解决方案。同时，它可以帮助消除与部署和管理分布式缓存环境相关的复杂性。 Amaozn ElastiCache for Redis 集群是一个或多个缓存节点的集合，其中所有节点都运行 Redis 缓存引擎软件的实例。ElastiCache for Redis 启用集群模式比之禁用集群模式拥有更好的可扩展性，尤其是写入可扩展性，更强的高可用性以及更高的资源上限，因而现在越来越多的客户选择 ElastiCache for Redis 启用集群模式。要使用 ElastiCache for Redis 集群（启用集群模式），您需要使用可以支持 Redis 集群模式的客户端。 当您使用 Go 程序连接 ElastiCache 集群时，目前目前主流的 SDK 是 Go-Redis 项目，本篇 Blog 将为您介绍如何使用 Go-Redis 连接和使用 ElastiCache for Redis 集群。  除此以外，我们还推出了一系列博客，展示了如何在不同语言中，使用不同的支持 ElastiCache 集群模式的客户端对 ElastiCache 集群进行连接和操作，欢迎大家阅读。 # 二、Go-Redis 测试环境搭建 **Go-Redis** 是目前排名最高的 Go 语言版本的 Redis client，支持连接哨兵和集群模式的 Redis，并且提供了高级的 API 封装，区别于另一个比较常用的 Go 语言 Redis client 库：Redigo，在服务集成过程中提供更多的功能支持，并且保障 Redis 数据类型安全支持。可以参考 **Go-Redis 和 Redigo 对比** 去了解更多的差异。 [Go-Redis](https\\://redis.uptrace.dev/?trk=cndc-detail) [Go-Redis 和 Redigo 对比](https\\://redis.uptrace.dev/guide/Go-Redis-vs-redigo.html?trk=cndc-detail) #### ▌ElastiCache for Redis 集群搭建 在亚马逊云科技上搭建 ElastiCache for Redis 集群，可以参考本篇的系列 Blog，**条条大路通罗马 —— 使用 Redisson 连接 [Amazon ElastiCache](https://aws.amazon.com/cn/elasticache/?trk=cndc-detail) for Redis 集群** 的2.1章节，这里就不再赘述。（Redis Cluster，打开 Auth+TLS 模式）。 条条大路通罗马 —— [使用 Redisson 连接 Amazon ElastiCache for Redis 集群](https\\://aws.amazon.com/cn/blogs/china/connecting-amazon-elasticache-for-redis-cluster-using-redisson/?trk=cndc-detail) #### ▌构建 Golang SDK 测试代码工程的目录结构 ```[ec2-user src]\$ tree test-redis-sdk/ test-redis-sdk/ |-- cmd | `-- test-redis | `-- redis_test.go |-- go.mod `-- go.sum ``` 使用 Go-Redis 最新的版本分支 v8 版本 ，下图总结了初始化 cluster client 常用参数，PoolSize 和 MinIdleConns 控制请求的连接池。Go-Redis 支持 TLS 连接，本示例主要演示打开 TLS+Password 的 ElastiCache for Redis 集群如何接入，如下图所示，参数 Password 已设置，参数 TLSConfig 控制 TLS 开关已打开。如果您连接的 ElastiCache for Redis 集群没有开启 TLS 接入，只需要把 Password 参数置为空字符串，去除 TLSConfig 配置即可（TLSConfig 默认关闭）。  #### ▌使用 Go-Redis SDK 初始化 cluster client，包括读请求的测试逻辑（源代码） ```[ec2-user test-redis]\$ cat redis_test.go package main import ( "context" "crypto/tls" "fmt" goredis "github.com/Go-Redis/redis/v8" "strconv" "sync" "testing" "time" ) func TestGoRedisCluster(t *testing.T) { var ctx = context.Background() rdb := goredis.NewClusterClient(&goredis.ClusterOptions{ Addrs: []string{"cluster-configuration-endpoint:6379"}, Password: "password", //密码 //连接池容量及闲置连接数量 PoolSize: 10, // 连接池最大socket连接数，默认为4倍CPU数， 4 * runtime.NumCPU MinIdleConns: 10, //在启动阶段创建指定数量的Idle连接，并长期维持idle状态的连接数不少于指定数量；。 //超时 DialTimeout: 5 * time.Second, //连接建立超时时间，默认5秒。 ReadTimeout: 3 * time.Second, //读超时，默认3秒， -1表示取消读超时 WriteTimeout: 3 * time.Second, //写超时，默认等于读超时 PoolTimeout: 4 * time.Second, //当所有连接都处在繁忙状态时，客户端等待可用连接的最大等待时长，默认为读超时+1秒。 //闲置连接检查包括IdleTimeout，MaxConnAge IdleCheckFrequency: 60 * time.Second, //闲置连接检查的周期，默认为1分钟，-1表示不做周期性检查，只在客户端获取连接时对闲置连接进行处理。 IdleTimeout: 5 * time.Minute, //闲置超时，默认5分钟，-1表示取消闲置超时检查 MaxConnAge: 0 * time.Second, //连接存活时长，从创建开始计时，超过指定时长则关闭连接，默认为0，即不关闭存活时长较长的连接 //命令执行失败时的重试策略 MaxRetries: 10, // 命令执行失败时，最多重试多少次，默认为0即不重试 MinRetryBackoff: 8 * time.Millisecond, //每次计算重试间隔时间的下限，默认8毫秒，-1表示取消间隔 MaxRetryBackoff: 512 * time.Millisecond, //每次计算重试间隔时间的上限，默认512毫秒，-1表示取消间隔 TLSConfig: &tls.Config{ InsecureSkipVerify: true, }, // ReadOnly = true，只择 Slave Node // ReadOnly = true 且 RouteByLatency = true 将从 slot 对应的 Master Node 和 Slave Node， 择策略为: 选择PING延迟最低的点 // ReadOnly = true 且 RouteRandomly = true 将从 slot 对应的 Master Node 和 Slave Node 选择，选择策略为: 随机选择 ReadOnly: true, RouteRandomly: true, RouteByLatency: true, }) defer rdb.Close() rdb.Set(ctx, "test-0", "value-0", 0) rdb.Set(ctx, "test-1", "value-1", 0) rdb.Set(ctx, "test-2", "value-2", 0) AllMaxRun := 6 wg := sync.WaitGroup{} wg.Add(AllMaxRun) for i := 0; i < AllMaxRun; i ++ { go func(wg *sync.WaitGroup, idx int) { defer wg.Done() for i := 0; i < 50000; i++ { key := "test-" + strconv.Itoa(i % 3) val, err := rdb.Get(ctx, key).Result() if err == goredis.Nil { fmt.Println("job-" + strconv.Itoa(idx) + " " + key + " does not exist") } else if err != nil { fmt.Printf("err : %s", err.Error()) } else { fmt.Printf("%s Job-%d %s = %s-%d \\n", time.Now().Format("2006-01-02 15:04:05"), idx, key, val, i) } time.Sleep(500 * time.Millisecond) } }(&wg, i) } wg.Wait() stats := rdb.PoolStats() fmt.Printf("Hits=%d Misses=%d Timeouts=%d TotalConns=%d IdleConns=%d StaleConns=%d\\n", stats.Hits, stats.Misses, stats.Timeouts, stats.TotalConns, stats.IdleConns, stats.StaleConns) } ``` <!--StartFragment--> ## 三、Go-Redis 读写分离控制测试 Redis cluster 是有 Master 和 Slave 节点，Go-Redis 支持对 Slave 节点的访问，通过配置 ReadOnly 参数，控制 Master 和 Slave 节点的读写管理。下面我们通过不同的配置去做测试验证。 #### ▌ReadOnly 配置规则说明 ```// 默认false，即只能在主节点上执行读写操作，如果置为true则允许在从节点上执行只含读操作的命令 ReadOnly: false, // 默认false。 置为true则ReadOnly自动置为true,表示在处理只读命令时，可以在一个slot对应的主节点和所有从节点中选取Ping()的响应时长最短的一个节点来读数据 RouteByLatency: false, // 默认false。置为true则ReadOnly自动置为true,表示在处理只读命令时，可以在一个slot对应的主节点和所有从节点中随机挑选一个节点来读数据 RouteRandomly: false, ``` #### ▌关闭 ReadOnly 配置测试 修改测试代码，关闭 ReadOnly 配置（三个 ReadOnly 参数配置都置为 false），观察监控仍然是维持10个  conn，但是按照配置说明，服务不会从读节点读取数据。 ```[ec2-user ~]\$ netstat -a | grep 6379 | grep ESTABLISHED | awk '{print \$5}' | sort | uniq -c | sort -rn 10 ip-172-31-18-215.a:6379 10 ip-172-31-46-118.a:6379 10 ip-172-31-34-217.a:6379 10 ip-172-31-31-193.a:6379 10 ip-172-31-15-157.a:6379 10 ip-172-31-10-163.a:6379 ``` 观察对应的连接数，连接数仍然保持在10个。  调整测试代码，增大查询压力，观察 GetTypeCmds 监控指标，可以看到只有 master 节点上是所有的读请求，判断所有的读压力都是分布在所有的 master 节点上。  #### ▌打开 ReadOnly 配置测试 修改测试代码，打开 ReadOnly 配置（或者 RouteByLatency 和 RouteRandomly 任意一个），观察监控仍然是维持10个 conn，但是按照配置说明，服务是会从读节点读取数据，可以判断 Go-Redis 默认和所有的 Master/Slave 节点都有长连接。 ```[ec2-user ~]\$ netstat -a | grep 6379 | grep ESTABLISHED | awk '{print \$5}' | sort | uniq -c | sort -rn 10 ip-172-31-18-215.a:6379 10 ip-172-31-46-118.a:6379 10 ip-172-31-34-217.a:6379 10 ip-172-31-31-193.a:6379 10 ip-172-31-15-157.a:6379 10 ip-172-31-10-163.a:6379 ``` 参考 CloudWatch Metrics 观察对应的连接数，连接数仍然保持，没有变化，和客户端连接数统计一致。  如果 ReadOnly 打开，在适当压力情况下，观察 GetTypeCmds 监控，可以看到 Master 和 Slave 节点都均匀分布读请求，可以判断读的压力是均匀分配到 Master+Slave 节点上。  # 四、多值查询测试 #### ▌Go-Redis 可以支持在 Redis 非集群和集群模式下 Pipeline 命令正确执行，以下给出 Pipeline 的代码示例： ```func TestRedisClusterPipline(t *testing.T) { var ctx = context.Background() rdb := goredis.NewClusterClient(&goredis.ClusterOptions{ Addrs: []string{"cluster-configuration-endpoint:6379"}, Password: "password", //密码 //连接池容量及闲置连接数量 PoolSize: 10, // 连接池最大socket连接数，默认为4倍CPU数， 4 * runtime.NumCPU MinIdleConns: 10, //在启动阶段创建指定数量的Idle连接，并长期维持idle状态的连接数不少于指定数量；。 //超时 DialTimeout: 5 * time.Second, //连接建立超时时间，默认5秒。 ReadTimeout: 3 * time.Second, //读超时，默认3秒， -1表示取消读超时 WriteTimeout: 3 * time.Second, //写超时，默认等于读超时 PoolTimeout: 4 * time.Second, //当所有连接都处在繁忙状态时，客户端等待可用连接的最大等待时长，默认为读超时+1秒。 //闲置连接检查包括IdleTimeout，MaxConnAge IdleCheckFrequency: 60 * time.Second, //闲置连接检查的周期，默认为1分钟，-1表示不做周期性检查，只在客户端获取连接时对闲置连接进行处理。 IdleTimeout: 5 * time.Minute, //闲置超时，默认5分钟，-1表示取消闲置超时检查 MaxConnAge: 0 * time.Second, //连接存活时长，从创建开始计时，超过指定时长则关闭连接，默认为0，即不关闭存活时长较长的连接 //命令执行失败时的重试策略 MaxRetries: 10, // 命令执行失败时，最多重试多少次，默认为0即不重试 MinRetryBackoff: 8 * time.Millisecond, //每次计算重试间隔时间的下限，默认8毫秒，-1表示取消间隔 MaxRetryBackoff: 512 * time.Millisecond, //每次计算重试间隔时间的上限，默认512毫秒，-1表示取消间隔 TLSConfig: &tls.Config{ InsecureSkipVerify: true, }, ReadOnly: true, }) rdb.Set(ctx, "test-0", "value-0", 0) rdb.Set(ctx, "test-1", "value-1", 0) rdb.Set(ctx, "test-2", "value-2", 0) pipe := rdb.Pipeline() pipe.Get(ctx, "test-0").Result() pipe.Get(ctx, "test-1").Result() pipe.Get(ctx, "test-2").Result() cmders, err := pipe.Exec(ctx) if err != nil { fmt.Println("err", err) } for idx, cmder := range cmders { cmd := cmder.(*goredis.StringCmd) strVal, err := cmd.Result() if err != nil { fmt.Println("err", err) } fmt.Println("strVal_" + strconv.Itoa(idx) + ":", strVal) } } ``` #### ▌Go-Redis 不支持 Redis 集群模式下，对不在一个 Shard 的多个 Key 执行 MGet / MSet  操作，如果有类似的使用场景，建议使用 Redis-Go-Cluster 开源项目，源码链接：Redis-Go-Cluster，以下为相应的代码示例。 ```func TestRedisClusterMGetMSet(t *testing.T) { cluster, err := rediscluster.NewCluster( &rediscluster.Options{ StartNodes: []string{"cluster-configuration-endpoint:6379"}, ConnTimeout: 100 * time.Millisecond, ReadTimeout: 100 * time.Millisecond, WriteTimeout: 100 * time.Millisecond, KeepAlive: 16, AliveTime: 60 * time.Second, }) if err != nil { fmt.Println(err.Error()) return } _, err = cluster.Do("MSET", "test-0", "value-0", "test-1", "value-1", "test-2", "value-2") if err != nil { fmt.Println("MSET" + err.Error()) return } replys, err := rediscluster.Values(cluster.Do("MGET", "test-0", "test-1", "test-2")) if err != nil { fmt.Println("MGET" + err.Error()) return } for i := 0; i < 3; i++ { fmt.Println(rediscluster.String(replys[i], nil)) } } ``` # 五、Failover 测试 #### ▌执行 go test 做测试，持续的做读请求 ``` [ec2-user test-redis]\$ go test -v redis_test.go -run TestGoRedisCluster -timeout 100m === RUN TestGoRedisCluster 2022-04-18 12:27:37 Job-4 test-0 = value-0-0 2022-04-18 12:27:37 Job-1 test-0 = value-0-0 2022-04-18 12:27:37 Job-0 test-0 = value-0-0 2022-04-18 12:27:37 Job-5 test-0 = value-0-0 2022-04-18 12:27:37 Job-2 test-0 = value-0-0 2022-04-18 12:27:37 Job-3 test-0 = value-0-0 ``` 在 Idle 和 PoolSize 相等的配置下，可以观察到 Redis 客户端服务和 Master 和 Slave 都是建立10个连接。 ```[ec2-user ~]\$ netstat -a | grep 6379 | grep ESTABLISHED | awk '{print \$5}' | sort | uniq -c | sort -rn 10 ip-172-31-18-215.a:6379 10 ip-172-31-46-118.a:6379 10 ip-172-31-34-217.a:6379 10 ip-172-31-31-193.a:6379 10 ip-172-31-15-157.a:6379 10 ip-172-31-10-163.a:6379 ``` 在go test 开始之前，cluster 的 avg 连接数。  在 go test 执行开始，3个 master 和3个 slave 都新增了10个 conn。  #### ▌测试对 redis cluster 的第一个 shard 做主动的 failover  #### ▌在命令行输出观察到压测代码发生中断  #### ▌在 ElastiCache Dashboard Events 观察 Failover 过程  可以观察到 8:54:13 PM\~8:54:36 PM UTC+8 经过 23s 完成 Failover，测试代码的时间戳是12:54:16 \~ 12:54:26 UTC，实际服务中断只有 10s 时间。 在 12:53 UTC 时刻，连接正常。  在 12:54 UTC 时刻，故障节点断开连接。  在 13:00 UTC 时刻，故障节点开始恢复连接，但是所有服务请求未受到影响。  在 13:02 UTC 时刻，所有连接完全恢复。  #### ▌在 ReadOnly = False 时，做 Failover 时 ```2022-04-18 15:04:27 Job-5 test-1 = value-1-601 2022-04-18 15:04:27 Job-0 test-1 = value-1-601 2022-04-18 15:04:27 Job-1 test-1 = value-1-601 err : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeout2022-04-18 15:04:38 Job-3 test-0 = value-0-603 2022-04-18 15:04:38 Job-5 test-0 = value-0-603 2022-04-18 15:04:39 Job-0 test-0 = value-0-603 err : dial tcp 172.31.31.193:6379: i/o timeout2022-04-18 15:04:39 Job-2 test-0 = value-0-603 2022-04-18 15:04:39 Job-4 test-0 = value-0-603 2022-04-18 15:04:39 Job-3 test-1 = value-1-604 2022-04-18 15:04:39 Job-5 test-1 = value-1-604 2022-04-18 15:04:40 Job-0 test-1 = value-1-604 2022-04-18 15:04:40 Job-1 test-0 = value-0-603 2022-04-18 15:04:40 Job-2 test-1 = value-1-604 2022-04-18 15:04:40 Job-4 test-1 = value-1-604 2022-04-18 15:04:41 Job-1 test-1 = value-1-604 err : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeout2022-04-18 15:04:50 Job-3 test-0 = value-0-606 err : dial tcp 172.31.31.193:6379: i/o timeout2022-04-18 15:04:50 Job-2 test-0 = value-0-606 err : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeouterr : dial tcp 172.31.31.193:6379: i/o timeout2022-04-18 15:04:51 Job-3 test-1 = value-1-607 2022-04-18 15:04:51 Job-5 test-0 = value-0-606 2022-04-18 15:04:51 Job-2 test-1 = value-1-607 2022-04-18 15:04:52 Job-1 test-0 = value-0-606 2022-04-18 15:04:52 Job-4 test-0 = value-0-606 2022-04-18 15:04:52 Job-0 test-0 = value-0-606 ``` Failover 时，中断时间。  可以观察到 11:04:28 PM\~11:05:03 PM UTC+8 经过 35s 完成 Failover，测试代码的时间戳是 15:04:27 \~ 15:04:51 UTC，实际服务中断为 24s 时间。  在 15:03 UTC 连接正常。  在 15:04 UTC Failover 开始断开一个节点。  在 15:11 UTC 开始恢复一个节点。  在 15:13 UTC 完全恢复。  <!--StartFragment--> # 六、小结 本博客为大家展示了如何在 Golang 程序中通过 Go-Redis 连接和操作 ElastiCache 集群，从这个简单的 Demo 中我们可以看到 Go-Redis 能很好地支持 ElastiCache 集群开启 TLS 及 Auth 的功能，并自动完成读写分离，负载均衡，Failover 等工作。在第5小节的 Failover 的测试中观察到打开 ReadOnly 可以加速故障恢复，建议实际使用基于 ReadOnly 更好的提升服务读写 Redis Cluster 的性能。通过 Go-Redis，我们可以便捷，高效地使用 ElastiCache 集群。 除了本博客以外，我们还推出了一系列博客，展示了如何在不同语言中使用不同的客户端对 ElastiCache 集群进行连接和操作，欢迎大家阅读。 # 相关博客 [条条大路通罗马 —— 使用 redisson 连接 Amazon ElastiCache for Redis 集群](https\\://aws.amazon.com/cn/blogs/china/connecting-amazon-elasticache-for-redis-cluster-using-redisson/?trk=cndc-detail) [条条大路通罗马 —— 使用 redis-py 访问 Amazon ElastiCache for Redis 集群](https\\://aws.amazon.com/cn/blogs/china/use-redis-py-to-access-amazon-elasticache-for-redis-cluster/?trk=cndc-detail) [条条大路通罗马系列- 使用 Hiredis-cluster 连接 Amazon ElastiCache for Redis 集群](https\\://aws.amazon.com/cn/blogs/china/all-roads-to-rome-series-connect-amazon-elasticache-for-redis-cluster-with-hiredis-cluster/?trk=cndc-detail)