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 这里就不坳述了。
可以预见的是,有很多同学认为把计数全部存在内存中成本非常高,我在这里用个图表来表示下我的观点:
很多情况大家都会设想纯使用内存的方案会很有很高成本,但实际情况往往会有一些不一样:
1.COST,对于有一定吞吐需求的应用来说,肯定会单独申请DB、Cache资源,很多担心DB写入性能的同学还会主动将DB更新记入异步队列,而这三块的资源的利用率一般都不会太高。资源算下来,你惊异的发现:反而纯内存的方案会更精简!
2.KISS原则,这对于开发是非常友好的,我只需要建立一套连接池,不用担心数据一致性的维护,不用维护异步队列。
3.Cache穿透风险,如果后端使用DB,肯定不会提供很高的吞吐能力,cache宕机如果没有妥善处理,那就悲剧了。
4.大多数的起始存储需求,容量较小。
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
这里把两个功能放在最后,因为这两个功能在现实问题当中遇到了一些困难,但在一定阶段也确实解决了我们很多的问题,故在这里只做说明。
Pinterest使用Redis存储社交graph信息:
http://blog.gopivotal.com/case-studies-2/using-redis-at-pinterest-for-billions-of-relationships
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
很多测试和应用均已证明,
1.在性能方面Redis并没有落后Memcache多少,而单线程的模型给Redis反而带来了很强的扩展性。
2.在很多场景下,Redis对同一份数据的内存开销是小于Memcache的slab分配的。
3.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盘及分布式的存储也在我们未来计划之中。
相关推荐
亿级流量新浪微博与微信Redis架构实战
### 新浪微博Redis优化历程详解 #### 一、业务场景及背景 新浪微博作为一个拥有庞大用户基数的社交平台,在发展过程中面临...这一历程不仅为新浪微博带来了巨大的技术进步,也为整个互联网行业提供了宝贵的经验参考。
本文将详细介绍新浪微博在使用Redis过程中的一些经验和技术改进,对于正在使用或计划使用Redis的技术人员来说,具有很高的参考价值。 #### 二、转发评论计数器技术演化 1. **挑战点**: - 每秒百万级请求量。 - ...
### 新浪微博开放平台Redis实践 #### Redis简介 Redis是一种开源的、高性能的键值对存储系统,它支持多种数据结构如字符串、哈希、列表、集合等,并且提供了丰富的命令来操作这些数据结构。由于其优秀的性能表现,...
redis使用用及优化建议 redis不是万能的:合理的业务选型 明确redis业务使用规范 按照业务线独立部署:避免混用 线上版本尽量统一 拥抱需求,持续优化
### 新浪微博开放平台Redis实践 #### Redis简介 Redis是一种高性能、开源的键值数据库,以其卓越的速度和灵活性而著称。它支持多种数据结构,如字符串、哈希、列表、集合以及有序集合等,这使得Redis在处理复杂的...
新浪微博开放平台中的Redis实践_大数据时代feed架构_微博消息系统架构演进_互联网公司技术架构资料.新浪微博.微博架构与平台安全_构建高性能的微博系统——再谈新浪微博架构 演讲视频,PPT,一些收集的博客地址等
**Redis实战.pdf** Redis,全称Remote Dictionary Server,是一款开源的、高性能的键值存储系统。它被设计为一个内存数据库,支持多种数据结构,如字符串、哈希、列表、集合和有序集合,同时提供了持久化功能,确保...
《Redis实战》作为一本由Redis创始人Josiah L. Carlson编著的书籍,深入浅出地介绍了Redis的核心概念、特性和实际应用,是初学者了解和掌握Redis的理想读物。 在书中,你可以了解到Redis的基本数据结构,包括字符串...
Redis实战 Redis实战 Redis实战 Redis实战 Redis实战 Redis实战
redis实战pdf
总的来说,《Redis实战》是一本全面而实用的Redis指南,无论你是初学者还是有经验的开发者,都能从中受益匪浅。通过阅读这本书,你将不仅理解Redis的基本操作,还能学会如何在各种场景下有效地利用它,提升系统的...
【新浪Redis运维实战】是新浪高级DBA赵景波分享的关于新浪数据库平台在Redis运维方面的实践经验。这个分享主要涵盖了三个核心部分:新浪数据库平台概览、精细化运维和Redis Cluster Proxy。 新浪数据库平台是一个...
根据提供的文件内容,我们可以了解到新浪微博开放平台的Redis实践,具体包括在好友关系、计数器等场景的应用,以及使用Redis的一些经验教训。 首先,Redis简介。Redis(Remote Dictionary Server)是一个开源的使用...
总之,《Redis实战中文高清》是一本全面且实用的Redis学习资料,无论是初学者还是有经验的开发者,都能从中受益匪浅。通过深入学习和实践,你将能够充分利用Redis的潜力,解决各类数据处理难题,提升系统的性能和...
新浪微博爬虫(Scrapy、Redis)Sina_Spider1《新浪微博爬虫分享(一天可抓取1300万条数据)》Sina_Spider2《新浪微博多个爬虫分享》Sina_Spider3《新浪微博爬虫分享(2016年12月01日更新)》Sina_Spider1为单机版本...
redis实战完整版!redis实战完整版!redis实战完整版!redis实战完整版!redis实战完整版!redis实战完整版!redis实战完整版!