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

分布式
Redis
缓存
Amazon ElastiCache
0
0
# 一、前言 Amazon ElastiCache 是一种 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 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 默认关闭)。 ![1.png](https://dev-media.amazoncloud.cn/ce490a0c30604f6984a77c0ac8298583_1.png "1.png") #### ▌使用 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个。 ![2.png](https://dev-media.amazoncloud.cn/302435bd6c9e4df68d10d05ab4cff132_2.png "2.png") 调整测试代码,增大查询压力,观察 GetTypeCmds 监控指标,可以看到只有 master 节点上是所有的读请求,判断所有的读压力都是分布在所有的 master 节点上。 ![3.png](https://dev-media.amazoncloud.cn/05ae1e29161d4f33882bca6b64c11c4d_3.png "3.png") #### ▌打开 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 观察对应的连接数,连接数仍然保持,没有变化,和客户端连接数统计一致。 ![4.png](https://dev-media.amazoncloud.cn/cac4fc7aaa504e3e86d5ea91a4b9177e_4.png "4.png") 如果 ReadOnly 打开,在适当压力情况下,观察 GetTypeCmds 监控,可以看到 Master 和 Slave 节点都均匀分布读请求,可以判断读的压力是均匀分配到 Master+Slave 节点上。 ![5.png](https://dev-media.amazoncloud.cn/182fdc0d65c04f5e98bd73e2925053ea_5.png "5.png") # 四、多值查询测试 #### ▌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 连接数。 ![6.png](https://dev-media.amazoncloud.cn/77e742c5085d43eebbb1c7b80e0838fe_6.png "6.png") 在 go test 执行开始,3个 master 和3个 slave 都新增了10个 conn。 ![7.png](https://dev-media.amazoncloud.cn/61882051efa04bb6b463baba4d6e9c45_7.png "7.png") #### ▌测试对 redis cluster 的第一个 shard 做主动的 failover ![8.png](https://dev-media.amazoncloud.cn/976b55f6ba434b5f82d2a7a58e516046_8.png "8.png") #### ▌在命令行输出观察到压测代码发生中断 ![9.png](https://dev-media.amazoncloud.cn/9926209d27dd4672aa38efa6505329e2_9.png "9.png") #### ▌在 ElastiCache Dashboard Events 观察 Failover 过程 ![10.png](https://dev-media.amazoncloud.cn/ebb9946de1544629a7c90ea11525722d_10.png "10.png") 可以观察到 8:54:13 PM\~8:54:36 PM UTC+8 经过 23s 完成 Failover,测试代码的时间戳是12:54:16 \~ 12:54:26 UTC,实际服务中断只有 10s 时间。 在 12:53 UTC 时刻,连接正常。 ![11.png](https://dev-media.amazoncloud.cn/f068256a053b4872a9024a4194040bea_11.png "11.png") 在 12:54 UTC 时刻,故障节点断开连接。 ![12.png](https://dev-media.amazoncloud.cn/dc5855f51fe043e5964a5ff080ff7465_12.png "12.png") 在 13:00 UTC 时刻,故障节点开始恢复连接,但是所有服务请求未受到影响。 ![13.png](https://dev-media.amazoncloud.cn/3d1425e1183844a9a21a99923c8060a6_13.png "13.png") 在 13:02 UTC 时刻,所有连接完全恢复。 ![14.png](https://dev-media.amazoncloud.cn/f11289db8f9840d1a0713b60c2fce2c9_14.png "14.png") #### ▌在 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 时,中断时间。 ![15.png](https://dev-media.amazoncloud.cn/31d624ca5f42471a961403fd1e8cab54_15.png "15.png") 可以观察到 11:04:28 PM\~11:05:03 PM UTC+8 经过 35s 完成 Failover,测试代码的时间戳是 15:04:27 \~ 15:04:51 UTC,实际服务中断为 24s 时间。 ![16.png](https://dev-media.amazoncloud.cn/649a4315db1544f4ab1f4e3f72bdfccc_16.png "16.png") 在 15:03 UTC 连接正常。 ![17.png](https://dev-media.amazoncloud.cn/67bb0816de3c40379f9c1609116cbd9c_17.png "17.png") 在 15:04 UTC Failover 开始断开一个节点。 ![18.png](https://dev-media.amazoncloud.cn/1aed147dd1c04f8a8072ecbd4dfd1b87_18.png "18.png") 在 15:11 UTC 开始恢复一个节点。 ![19.png](https://dev-media.amazoncloud.cn/21796e953b8548c1b860bcb00fa36728_19.png "19.png") 在 15:13 UTC 完全恢复。 ![20.png](https://dev-media.amazoncloud.cn/8b4e78be713941589494b1980edd0c56_20.png "20.png") <!--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)
目录
亚马逊云科技解决方案 基于行业客户应用场景及技术领域的解决方案
联系亚马逊云科技专家
亚马逊云科技解决方案
基于行业客户应用场景及技术领域的解决方案
联系专家
0
目录
关闭
contact-us