如果Redis可以用到极致

相对于memcache,redis拥有的持久化和多数据类型,非常适合应用于互联网社交、电商等业务较为复杂的系统中.

新浪微博是国内最早(2010年)大规模线上Redis的实践者,到目前已经趋于极致.

可以看这篇干货《用最少的机器支撑万亿级拜访,微博6年Redis优化历程》,我们能借鉴到如何避免大规模应用redis时,会碰到的问题,如：

1、持久化内存消耗导致服务崩溃.

2、主从同步全量加载问题

3、版本升级的问题

当然,文中还提到了特定业务场景下的定制化应用.

微博是从 2010 年开始引入 Redis ,现在 Redis 已经广泛应用于微博的多个业务场景,如关系、计数、通知提醒等,目前 Redis 集群存储超过百亿记录,每天上万亿的读取拜访.

持久化问题

在我们大多数业务场景中 Redis 是当做存储来使用,会开启持久化机制.线上采用单机多实例的部署结构,服务器的内存使用率也会比较高.

由于官方版本触发 bgsave 和 bgrewriteaof 操作的时间点是不可控的,依赖于相关的配置项和业务的写入模型,因此可能会出现单机部署的多个 Redis 实例同时触发 bgsave 或 bgrewriteaof 操作,这两个操作都是通过 fork 出一个子进程来完成的,由于 copy-on-write 机制,可能会导致服务器内存很快耗尽, Redis 服务崩溃.

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

主从同步问题

官方版本的主从同步机制,在网络出现问题时(如瞬断),会导致主从重新进行一次全量复制.

当然官方 2.8 版本支持了 psync 增量复制的机制,一定程度上解决了主从连接断开会引发全量复制的问题

版本升级及管理问题

官方版本在执行升级操作时,需要服务重启,我们大多数线上业务都开启了持久化机制,重启操作耗时较长,加上使用 Redis 业务线比较多,版本升级操作的复杂度很高.

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

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

2. 对于主从同步机制,借鉴 MySQL 的复制机制并做了简化.使用 rdb + aof 的方式,支持基于 aofpositon 的增量复制

================================

老杨有话说：

1、真的是业务需求推动技术变革,技术只有持续优化、改进,才能满足业务发展需要,才能体现其价值.

2、即使是再优秀的开源产品,要拿来适配公司业务,还是要深度探究和改进才行.

3、官方提供的redis解决方案,足够满足中小型企业的技术要求,但是如何用到极致,还是需要优秀的人才来打磨.

4、要持久话的数据,能放到mysql就不要扔到redis,当然,除非你对redis的持久化可以像上面他们做的一样靠谱才行.

5、个人还是更倾向于redis的缓存模式和它的多数据结构.

封面人物介绍：

拉斯姆斯·勒多夫(Rasmus Lerdorf,1968年11月22日－)是一个丹麦程序员,他拥有加拿大国籍.他就是PHP他爹,PHP的创始人,其中PHP的头两个版本是由他编写的,后来他也参与PHP后续版本的开发.

谁会想到一个原本只是用来网页拜访跟踪的工具,会发展成为世界上最好的语言,所以,没事干了多写写代码,万一被成功了呢?