当 Redis 遇上 Serverless-编程知识

亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！

大家好，我是张晋涛。

前段时间看到了很多关于数据库要不要部署在 Kubernetes 之上的讨论，这些年，这种讨论时有发生。

这个事情并没有绝对的定论，因为每个人都是基于自己的认知，或基于自己过往的经验在进行分析、讨论，每个人的出发点不同，自然得到的结论也是不一样的。

2021 年的时候，我曾经做过一次线上分享： Redis 容器化技术选型，K8S 并非唯一 | MoeLove 在那次分享中，我主要是聊了一些容器化的技术手段，Redis 自身的一些特性，以及基于不同业务场景或者需求时，可以选用的技术方案。

今天这篇，我想再聊聊 Redis 在 Serverless 场景下的应用。

Redis 的特性及应用场景

Redis 是一个开源的，基于内存的数据存储引擎。它非常简洁，但功能全面实用、灵活多变，常被称之为数据库领域的 “瑞士军刀”，被数百万开发者用作数据库、缓存、流引擎和消息代理。

Redis 的主要特点

速度快：由于它是一个内存型数据库，数据的读取写入都直接通过内存完成，避免了读写硬盘而可能造成的延迟问题。即使在高频的读写场景下也可以有非常不错的表现；
适用场景丰富：Redis 有着丰富的数据类型，可以灵活的用于各类场景中（下文将详细介绍）；
上手成本低：Redis 的操作指令和使用是非常简单的，包括它的通信协议 RESP 也设计的非常简洁，感兴趣的小伙伴可以参考我之前的文章理解 Redis 的 RESP 协议 | MoeLove；
支持持久化：尽管 Redis 是内存型数据库，但是考虑到实际的应用场景，如果能对数据进行持久化，那么在遇到故障或者数据恢复时则会方便很多。Redis 支持通过 RDB（内存数据快照）和 AOF （记录 Server 端的命令到文件）的方式进行持久化；
生态丰富：Redis 有着 50+ 种语言的 Client library，覆盖了所有的主流编程语言。同时也有很多 CLI 和 GUI 的客户端工具可以使用；

Redis 支持的数据类型及适用场景

前面提到 Redis 有着非常丰富的数据类型，每种数据类型都有特定的应用场景。

字符串（string）：字符串是 Redis 最基本的数据类型，字符串类型支持的常用命令包括 SET、GET 等；
散列（hash）：散列表是一种 K-V 型的数据结构，散列类型可以存储多个键值对，并且支持嵌套数据结构。散列类型支持的常用命令包括 HSET、HGET 等；
列表（list）：列表在每个节点存储了一个字符串，可以在列表的两端进行元素的添加或删除操作。列表类型支持的常用命令包括 LPUSH、RPUSH、LPOP 和 RPOP 等；
集合（set）：集合是一个不允许有重复元素的无序数据结构，支持取交集、并集和差集等常用操作。集合类型支持的常用命令包括 SADD、SMEMBERS 等；
有序集合（zset）：有序集合是一个可以排序的集合，每个元素都有一个 score，支持根据 score 进行排序和范围查找。有序集合类型支持的常用命令包括 ZADD、ZRANGE、ZREVRANK 和 ZSCORE 等；
位图（bitmap）：位图不是个实际的数据类型，是一个由二进制位组成的数组结构，支持位运算操作。位图常用于统计、记录用户的在线状态等场景；
位域（bitfield）：位域也是一种用于操作二进制位的数据结构和命令集合。允许用户以比特位为单位对字符串进行操作，并且支持多种位操作，例如获取、设置、计数等。位域也可以用于存储和操作布尔值、整数等数据类型；
HyperLogLog：HyperLogLog 是一种基数算法，用于估算一个集合的基数。它采用的是随机化算法，并且空间复杂度很低。 HyperLogLog 可用于处理大量数据集的场景，例如网站的 UV 统计；

Redis 支持这么多的数据类型和用法，使得它常年稳居 K-V 型存储排行榜的榜首。以下是我新截图的排名：

Redis 集群的架构

Redis 除了支持 master-replica 这种简单的主从模式外，也提供了 Cluster 模式。

Redis Cluster 是 Redis 数据库的分布式解决方案。它可以将数据分布在多台服务器上，从而提高 Redis 的可用性和性能。

Redis Cluster 采用了分片的方式来存储数据，将数据分散在多个节点上。每个节点都存储一部分数据，并且每个节点都知道其他节点的信息。这样，当一个节点宕机时，其他节点可以接管它的数据，保证 Redis 集群的可用性。

同时，由于 Redis Cluster 的这种特性，也使得它可以通过增加节点的方式来对集群的容量进行扩展，这解决了单实例或者主从模式下，Redis 受限于所在机器内存容量限制的不足。

并且每个节点仍然可以采用主从的模式，提高其整体的可用性。

Serverless 化的 Redis 有何优势

前面简单的介绍了下 Redis 的主要特性和它的集群模式。我们会发现 Redis Cluster 有一个天然的优势 -- 它可以进行水平扩展，从而提升集群的整体容量。

在 Redis Cluster 出现之前，我们的大多数生产环境都是在使用 master-replica 这种主从模式。使用主从模式时候存在一些痛点，关于故障转移之类的我这篇文章中就不谈了，我主要谈下关于容量的部分。

在每次业务申请新上 Redis 主从集群的时候，第一件事情就是需要描述清楚业务场景，用途，以及预期的容量（或者预估的增长速度）。这样才能去找到合适的机器进行集群的部署。

在后续使用过程中，正常情况下会为数据设置 TTL 进行过期，但随着业务的发展，仍可能会导致集群容量逐步增加，当它快要达到容量的 80% 时候，就必须要扩容了。如果机器上尚有空余的内存，那么只需要修改 maxmemory 配置即可，但如果机器上内存容量不足，那只能进行集群的迁移了。到迁移时，同样涉及到了容量的规划，机器的采购等一系列繁琐的事情，苦不堪言。

那如果我们采用 Serverless 化的 Redis 能带来哪些优势呢？