在前端云计算中实现无服务器

Redis 2.0 时代(2010 - 2011)

实现机制高可用优化

微博最早使用的是 Redis 2.0 版本，在初期业务规模不大的时候， Redis 服务运行比较稳定。但是随着业务数据量和访问量的增加，一些问题逐渐暴露出来：

持久化问题

在我们大多数业务场景中 Redis 是当做存储来使用，会开启持久化机制。线上采用单机多实例的部署结构，服务器的内存使用率也会比较高。由于官方版本触发 bgsave和 bgrewriteaof 操作的时间点是不可控的，依赖于相关的配置项和业务的写入模型，因此可能会出现单机部署的多个 Redis 实例同时触发 bgsave 或 bgrewriteaof 操作，这两个操作都是通过 fork 出一个子进程来完成的，由于 copy-on-write 机制，可能会导致服务器内存很快耗尽， Redis 服务崩溃。

此外在磁盘压力较大时(生成 rdb、aof 重写)，对 aof 的写入及 fsync 操作可能会出现阻塞，虽然从 2.4 版本开始 fsync 操作调整到 bio 线程来做，主线程 aof 的写入阻塞仍会导致服务阻塞。

主从同步问题

为了提高服务可用性，避免单点问题，我们线上业务 Redis 大多采用主从结构部署。官方版本的主从同步机制，在网络出现问题时(如瞬断)，会导致主从重新进行一次全量复制。对单个端口来说，如果数据量小，那么这个影响不大，而如果数据量比较大的话，就会导致网络流量暴增，同时 slave 在加载 rdb 时无法响应任何请求。当然官方 2.8 版本支持了 psync 增量复制的机制，一定程度上解决了主从连接断开会引发全量复制的问题，但是这种机制受限于复制积压缓冲区大小，同时在主库故障需要执行切主操作场景下，主从仍然需要进行全量复制。

版本升级及管理问题



早期 Redis 版本运行不够稳定，经常需要修复 bug、支持新的运维需求及版本优化，导致版本迭代很频繁。官方版本在执行升级操作时，需要服务重启，我们大多数线上业务都开启了持久化机制，重启操作耗时较长，加上使用 Redis 业务线比较多，版本升级操作的复杂度很高。由于统一版本带来的运维工作量实在太高，线上 Redis 版本曾经一度增加到十几个，给版本管理也带来很大的困难。

为了解决以上问题我们对 Redis 原生实现机制做了以下优化：

1. 对于持久化机制，采用 rdb + aof 的持久化方式。

aof 文件按固定大小滚动，生成 rdb 文件时记录当前 aof 的 position，全量的数据包含在 rdb 和所记录位置点之后的 aof 文件，废弃 aof 重写机制，生成 rdb 后删除无效的 aof 文件;增加了定时持久化操作的配置项 cronsave，将单机部署的多个 Redis 实例的持久化操作分散在不同的时间点进行，并且错开业务高峰;将对 aof 的写入操作也放到 bio 线程来做，解决磁盘压力较大时 Redis 阻塞的问题。

2. 对于主从同步机制，借鉴 MySQL 的复制机制并做了简化。

使用 rdb + aof 的方式，支持基于 aofpositon 的增量复制。从库只需与主库进行一次全量同步同步，后续主从连接断开或切主操作，从库都是与主库进行增量复制。

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!