最佳实践 Databases for Redis
如果要使用 Databases for Redis,请花时间查看以下建议的最佳实践。
什么是 Databases for Redis?
Databases for Redis 是在 IBM Cloud上提供的受管 Redis OSS 服务。 它是内存中的 数据结构存储,用作数据库,高速缓存,消息代理和流式引擎。 与将数据存储在磁盘上的传统数据库不同,Redis 将数据存储在内存 (RAM) 中,从而实现低延迟。 数据为 ephemeral,这使 Databases for Redis 能够提供最高性能和高吞吐量。 您还可以将 Redis 配置为通过将性能与数据可用性进行交易来将数据持久存储在磁盘上,因为这是通过启用 AOF (仅追加文件) 与 RBD 快照同步来实现的。
为备份和高可用性启用了 RBD 快照,即使禁用了持久性也是如此。
实例容量规划的最佳实践
您必须根据应用程序和体系结构设计规划 Databases for Redis 实例容量,了解硬件需求,并为需求的增加或减少做好准备。 以下建议可帮助您优化实例大小。
- 了解数据
- 您应该知道数据的数据类型,大小和生存期。 这有助于您了解内存中可用数据在删除或移动之前的持续时间。
- 估算内存需求
- 计算内存需求很重要。 请记住,不仅要考虑数据,还要考虑复制所需的内存,客户机连接,最大内存缓冲区和 Redis 元数据。
- 了解读/写装入
- 识别读/写负载可帮助您准备自动缩放需求,缩短应用程序请求时间以及保持主跟随者同步。
- 了解您的 IOPS 需求
- 每秒输入/输出操作数是实例容量规划中应考虑的关键因素。Databases for Redis 根据缺省 Redis 配置定期生成 RDB 快照,这将与磁盘相关,即使为高速缓存设置了实例也是如此。 非常忙碌的数据库可能会超过磁盘大小的 IOPS,增加磁盘大小可以缓解性能瓶颈。
- 规划冗余和重新连接
- 云计算中涉及多个组件,这可能会导致一时的故障。 但是,在 IBM® Cloud Databases上,我们提供 99.99% 的高可用性,并鼓励您使用重试和重新连接逻辑来规划应用程序设计中的连接 blips。
- 考虑网络带宽
- 网络带宽可能会严重影响 Databases for Redis 性能。 确保您有足够的网络带宽来处理数据库负载。
- 监测和调整
- 我们建议您使用 IBM Cloud® Monitoring 监控您的 Databases for Redis 实例性能和用量,以确定数据库实例不断变化的使用模式,并根据需要调整大小。
性能最佳实践
- 禁用持久性
- 缺省情况下,Databases for Redis 已启用持久存储。 这将写入 AOF 同步并增加 IOPS 负载。 如果应用程序不需要持久存储数据,请使用命令
Set appendonly = no
来禁用此操作。 有关更多信息,请参阅
树立缓存榜样。 - RAM 与核心数
- Redis 是单线程内存中数据库。 与其他持久数据库不同,它本质上需要比 CORES 更多的 RAM。 即使它是单线程的,它也使用“多路复用”来处理请求,但所有请求都由一个线程处理。 但是,需要其他核心来维护其内部进程的数据库完整性和稳定性。 建议您更多地关注 Databases for Redis的 RAM 和磁盘 (对于 IOPS)。 有关更多信息,请参阅 实例容量规划的最佳实践。
- 缩小内存
- 建议您在减少 Databases for Redis 实例的内存时务必小心。 由于 Redis 是内存中数据库,因此其内存会保存数据以用于存储,处理和检索目的。 大幅减少内存可能会暂时停止实例返回错误,因为没有足够的可用空间来完成操作。 例如,考虑 20 GB 的数据尝试在 15 GB 内存中装入,这种情况势必会返回错误。
- 避免使用昂贵的命令
- Redis 中的某些命令运行成本高昂。 例如,频繁使用但应该避免的 KEYS 命令。 而是使用 SCAN 命令,该命令会将迭代传播到许多调用上,并且不会同时绑定整个服务器。
- 选择逐出策略
- 您应该选择适用于应用程序的逐出策略。 缺省情况下,使用
noeviction
策略配置部署。 Use eviction policies likeallkeys-lru
,volatile-lru
,allkeys-random
,volatile-random
,volatile-ttl
. For more information, see 记忆政策. - 设置 maxmemory 值
- 您可以调整
maxmemory
值。 但是,请设置合理的限制,否则您的数据会消耗所有可用内存,并且您的部署可能会耗尽资源。 缺省情况下,我们将其设置为数据节点可用内存的 80%。 - 设置 TTL (生存时间) 策略
- TTL 是一项重要功能,在此功能中,在定义的时间之后将从数据库中删除密钥。 如果使用 Redis 高速缓存,那么这非常有用。 但是,请注意设置非常短的值或非常长的值,因为非常短的值可以创建值的重新计算,而非常长的值可以创建不必要的内存使用。 更多信息,请参阅 TTL 命令。
高可用性的最佳实践
- 重试并重新连接逻辑
- 系统容易发生中断。 强烈建议您实施重试并将逻辑重新连接到应用程序体系结构中,以避免中断。 使用 IOREDIS,NODEREDIS 或您选择的任何其他软件包来确保应用程序的连续性。
更多信息,请参阅 Redis的错误检测和处理博文。
监测最佳做法
您必须监视 LogDNA 中是否存在以下常见错误,并采取纠正措施:
- AOF 同步
- 只读可用
- 与主节点的连接丢失
- 有关防止错误的指导信息,请参阅 如何避免常见的 Databases for Redis 错误?。
一般最佳做法
- 连接池 (connection pooling)
- 创建或关闭连接成本高昂。 高效管理连接很重要,连接池有助于最大程度地减少与打开和关闭连接相关联的开销。 更多信息,请参阅 连接池。
- 连接限制
- 高效利用连接。 如果 Databases for Redis 连接过多,将返回错误,应用程序也会中断。 保留一些可用连接,因为许多连接是在内部保留的,以维护数据库的状态和完整性。 建议您使用连接池。 更多信息,请参阅 连接限制。
- 连接超时数
- 为连接设置适当的超时值对于防止资源无限绑定也很重要。 但是,请小心设置短时间超时,因为这可能会导致连接流失率和等待时间增加。 使超时与应用程序的操作期望保持一致。
- 使用 Redis 管道功能
- Redis 管道传送是一种通过一次发出多个命令而无需等待对每个单独命令的响应来提高性能的技术。 有关更多信息,请参阅 Redis 管道。
- 使用 Redis Streams 功能
- Redis Streams 是一种数据类型,用于提供超快的仅追加日志的内存抽象。
- 拆分大数据
- 建议将大型数据集拆分为具有更多键的较小块,即,将数据拆分为多个键。
- 批处理调度
- Databases for Redis 已调度为每天在调度的时间创建自动备份。 在此期间,将利用数据库 IOPS。 建议您此时不要运行自己的批处理作业。
- 设置通知通道
- 建议 Databases for Redis 在 IBM 帐户中设置电子邮件标识,以接收有关版本更改,寿命结束或维护调度的定期更新。 您还可以监视 IBM 帐户通知图标以接收这些更新。
有关更多信息,请参阅 IBM Cloud上Redis的最佳实践博文。