如果Redis可以用到极致
《如果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后续版本的开发. 谁会想到一个原本只是用来网页拜访跟踪的工具,会发展成为世界上最好的语言,所以,没事干了多写写代码,万一被成功了呢? 《如果Redis可以用到极致》是否对您有启发,欢迎查看更多与《如果Redis可以用到极致》相关教程,学精学透。编程之家 52php.cn为您提供精彩教程。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |