新浪微博 redis mysql_新浪微博:史上最大的Redis集群
随着应用对高性能需求的增加,NoSQL逐渐在各大名企的系统架构中生根发芽。这里我们将为大家分享社交巨头新浪微博带来的Redis实践,首先我们看新浪微博 @启盼cobain的Redis实战经验分享:
Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King. — Jim Gray
Redis不是比较成熟的memcache或者Mysql的替代品,是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况:
2200+亿 commands/day 5000亿Read/day 500亿Write/day
18TB+ Memory
500+ Servers in 6 IDC 2000+instances
应该是国内外比较大的Redis使用平台,今天主要从应用角度谈谈Redis服务平台。
Redis使用场景
1.Counting(计数)
计数的应用在另外一篇文章里较详细的描述,计数场景的优化 http://www.xdata.me/?p=262这里就不多加描述了。
可以预见的是,有很多同学认为把计数全部存在内存中成本非常高,我在这里用个图表来表达下我的观点:
很多情况大家都会设想纯使用内存的方案会很有很高成本,但实际情况往往会有一些不一样:
COST,对于有一定吞吐需求的应用来说,肯定会单独申请DB、Cache资源,很多担心DB写入性能的同学还会主动将DB更新记入异步队列,而这三块的资源的利用率一般都不会太高。资源算下来,你惊异的发现:反而纯内存的方案会更精简!
KISS原则,这对于开发是非常友好的,我只需要建立一套连接池,不用担心数据一致性的维护,不用维护异步队列。
Cache穿透风险,如果后端使用DB,肯定不会提供很高的吞吐能力,cache宕机如果没有妥善处理,那就悲剧了。
大多数的起始存储需求,容量较小。
2.Reverse cache(反向cache)
面对微博常常出现的热点,如最近出现了较为火爆的短链,短时间有数以万计的人点击、跳转,而这里会常常涌现一些需求,比如我们向快速在跳转时判定用户等级,是否有一些账号绑定,性别爱好什么的,已给其展示不同的内容或者信息。
普通采用memcache+Mysql的解决方案,当调用id合法的情况下,可支撑较大的吞吐。但当调用id不可控,有较多垃圾用户调用时,由于memcache未有命中,会大量的穿透至Mysql服务器,瞬间造成连接数疯长,整体吞吐量降低,响应时间变慢。
这里我们可以用redis记录全量的用户判定信息,如string key:uid int:type,做一次反向的cache,当用户在redis快速获取自己等级等信息后,再去Mc+Mysql层去获取全量信息。如图:
当然这也不是最优化的场景,如用Redis做bloomfilter,可能更加省用内存。
3.Top 10 list
产品运营总会让你展示最近、最热、点击率最高、活跃度最高等等条件的top list。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大,鉴于占用内存较小的情况,使用Redis做存储也是相当不错的。
4.Last Index
用户最近访问记录也是redis list的很好应用场景,lpush lpop自动过期老的登陆记录,对于开发来说还是非常友好的。
5.Relation List/Message Queue
这里把两个功能放在最后,因为这两个功能在现实问题当中遇到了一些困难,但在一定阶段也确实解决了我们很多的问题,故在这里只做说明。
Message Queue就是通过list的lpop及lpush接口进行队列的写入和消费,由于本身性能较好也能解决大部分问题。
6.Fast transaction with Lua
Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景,你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑,如:在收到message推送时,同时1.给自己的增加一个未读的对话 2.给自己的私信增加一个未读消息 3.最后给发送人回执一个完成推送消息,这一层逻辑完全可以在Redis Server端实现。
但是,需要注意的是Redis会将lua script的全部内容记录在aof和传送给slave,这也将是对磁盘,网卡一个不小的开销。
7.Instead of Memcache
很多测试和应用均已证明,
在性能方面Redis并没有落后memcache多少,而单线程的模型给Redis反而带来了很强的扩展性。
在很多场景下,Redis对同一份数据的内存开销是小于memcache的slab分配的。
Redis提供的数据同步功能,其实是对cache的一个强有力功能扩展。
Redis使用的重要点
1.rdb/aof Backup!
我们线上的Redis 95%以上是承担后端存储功能的,我们不仅用作cache,而更为一种k-v存储,他完全替代了后端的存储服务(MySQL),故其数据是非常重要的,如果出现数据污染和丢失,误操作等情况,将是难以恢复的。所以备份是非常必要的!为此,我们有共享的hdfs资源作为我们的备份池,希望能随时可以还原业务所需数据。
2.Small item & Small instance!
由于Redis单线程(严格意义上不是单线程,但认为对request的处理是单线程的)的模型,大的数据结构list,sorted set,hash set的批量处理就意味着其他请求的等待,故使用Redis的复杂数据结构一定要控制其单key-struct的大小。
另外,Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后,直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长,而更糟糕的是,Redis rewrite aof和save rdb时,将会带来非常大且长的系统压力,并占用额外内存,很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。
3.Been Available!
业界资料和使用比较多的是Redis sentinel(哨兵)
http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html
http://qiita.com/wellflat/items/8935016fdee25d4866d9
2000行C实现了服务器状态检测,自动故障转移等功能。
但由于自身实际架构往往会复杂,或者考虑的角度比较多,为此 @许琦eryk和我一同做了hypnos项目。
hypnos是神话中的睡神,字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)
其工作原理示意如下:
Talk is cheap, show me your code! 稍后将单独写篇博客细致讲下Hypnos的实现。
4.In Memory or not?
发现一种情况,开发在沟通后端资源设计的时候,常常因为习惯使用和错误了解产品定位等原因,而忽视了对真实使用用户的评估。也许这是一份历史数据,只有最近一天的数据才有人进行访问,而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。
所以当你在究竟使用什么样的数据结构存储的时候,请务必先进行成本衡量,有多少数据是需要存储在内存中的?有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的,1G的数据容量和1T的数据容量对于设计思路是完全不一样的
Plans in future?
1.slave sync改造
全部改造线上master-slave数据同步机制,这一点我们借鉴了MySQL Replication的思路,使用rdb+aof+pos作为数据同步的依据,这里简要说明为什么官方提供的psync没有很好的满足我们的需求:
假设A有两个从库B及C,及 A `— B&C,这时我们发现master A服务器有宕机隐患需要重启或者A节点直接宕机,需要切换B为新的主库,如果A、B、C不共享rdb及aof信息,C在作为B的从库时,仍会清除自身数据,因为C节点只记录了和A节点的同步状况。
故我们需要有一种将A`–B&C 结构切换切换为A`–B`–C结构的同步机制,psync虽然支持断点续传,但仍无法支持master故障的平滑切换。
实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步,效果非常好,解决了运维负担,但仍需向所有Redis服务推广,如果可能我们也会向官方Redis提出相关sync slave的改进。
2.更适合redis的name-system Or proxy
细心的同学发现我们除了使用DNS作为命名系统,也在zookeeper中有一份记录,为什么不让用户直接访问一个系统,zk或者DNS选择其一呢?
其实还是很简单,命名系统是个非常重要的组件,而dns是一套比较完善的命名系统,我们为此做了很多改进和试错,zk的实现还是相对复杂,我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。
3.后端数据存储
大内存的使用肯定是一个重要的成本优化方向,flash盘及分布式的存储也在我们未来计划之中。(原文链接: Largest Redis Clusters Ever)
新浪微博 redis mysql_新浪微博:史上最大的Redis集群相关推荐
- Redis史上最强【集群】入门实践教程
来自:我没有三颗心脏 一.Redis 集群概述 Redis 主从复制 到 目前 为止,我们所学习的 Redis 都是 单机版 的,这也就意味着一旦我们所依赖的 Redis 服务宕机了,我们的主流程也会 ...
- springboot redis 断线重连_Redis(9)——史上最强【集群】入门实践教程
一.Redis 集群概述 Redis 主从复制 到 目前 为止,我们所学习的 Redis 都是 单机版 的,这也就意味着一旦我们所依赖的 Redis 服务宕机了,我们的主流程也会受到一定的影响,这当然 ...
- Redis——史上最强【集群】入门实践教程
一.Redis 集群概述 Redis 主从复制 到 目前 为止,我们所学习的 Redis 都是 单机版 的,这也就意味着一旦我们所依赖的 Redis 服务宕机了,我们的主流程也会受到一定的影响,这当然 ...
- Redis:史上最强【集群】入门实践教程
来源:我没有三颗心脏 一.Redis 集群概述 Redis 主从复制 到 目前 为止,我们所学习的 Redis 都是 单机版 的,这也就意味着一旦我们所依赖的 Redis 服务宕机了,我们的主流程也会 ...
- Redis(9)——史上最强【集群】入门实践教程
一.Redis 集群概述 Redis 主从复制 到 目前 为止,我们所学习的 Redis 都是 单机版 的,这也就意味着一旦我们所依赖的 Redis 服务宕机了,我们的主流程也会受到一定的影响,这当然 ...
- 这可能是史上最全 Redis 高可用解决方案总结
转载自 这可能是史上最全 Redis 高可用解决方案总结 本文主要针对 Redis 常见的几种使用方式及其优缺点展开分析. 一.常见使用方式 Redis 的几种常见使用方式包括: Redis 单副本 ...
- 史上最全Redis面试题
转载自 史上最全Redis面试题及答案. 1.什么是Redis? 2.Redis相比memcached有哪些优势? 3.Redis支持哪几种数据类型? 4.Redis主要消耗什么物理资源? 5.Red ...
- 史上最全Redis面试题(2020最新版)
导读:2020 年最新版 68 道Redis面试题,两万字干货,整理分享至此,希望对大家有帮助!文末有PDF文档下载方式,可按需下载. 概述 1. 什么是Redis? Redis(Remote Dic ...
- redis的三大模式主从,哨兵和集群
一.前言 二.redis主从复制 1.主从复制的作用: 2.主从复制的流程 3.搭建主从复制 3.1.搭建环境 3.2.安装redis 3.3.主服务器配置查看以下行 3.4.从服务器配置查看以下行 ...
- Redis高可用——主从复制、哨兵模式、集群
文章目录 一.Redis高可用 1.什么是高可用 2.Redis的高可用技术 二.Redis主从复制 1.Redis主从复制的作用 2.主从复制的流程 三.主从复制的搭建 实验准备 1.所有主机安装R ...
最新文章
- 权限组件(4):给动态菜单增加面包屑导航
- 【WebPPTtoPDF】在线将PPT转化为PDF,支持自定义排列方式
- 【计蒜客信息学模拟赛1月月赛 - B】蒜头套圈圈(贪心,前缀最大值)
- 用C语言设置程序开机自启动
- [Hibernate]关于ID的一个容易混淆的地方
- [河南省ACM省赛-第四届] 表达式求值(nyoj 305)
- 超清晰的 DNS 原理入门指南 (资源)
- easyui菜单 java_EasyUI:主界面以及菜单功能
- [原创]桓泽学音频编解码(14):AC3 时频转换模块算法分析
- 利用ExcelJS读取Excel文件
- 根据设计稿,用JS计算rem的值
- 在Maxthon中使用Google网站加速器(转)
- 百度APP视频播放中的解码优化
- mysql修行练级之mysql新手入门常用命令
- 1.荔枝派 zero(全志V3S)-编译及SD烧录
- xlrd python读取excel 编码错误_python读取excel数据报xlrd.biffh.XLRDError错误原因
- Visual Studio 2017 激活密钥
- MySql Sharding:分表、分库、分片和分区
- zero 免焊 树莓派_给树莓派 Zero 添加一个RCA视频输出插头
- Jmeter 断言的使用(响应断言,json断言,断言响应时间)