前言

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盘及分布式的存储也在我们未来计划之中。

via: http://www.xdata.me/?p=301

最大的Redis集群:新浪Redis集群揭秘的更多相关文章

  1. NoSQL初探之人人都爱Redis:(4)Redis主从复制架构初步探索

    一.主从复制架构简介 通过前面几篇的介绍中,我们都是在单机上使用Redis进行相关的实践操作,从本篇起,我们将初步探索一下Redis的集群,而集群中最经典的架构便是主从复制架构.那么,我们首先来了解一 ...

  2. 【转】 NoSQL初探之人人都爱Redis:(4)Redis主从复制架构初步探索

    一.主从复制架构简介 通过前面几篇的介绍中,我们都是在单机上使用Redis进行相关的实践操作,从本篇起,我们将初步探索一下Redis的集群,而集群中最经典的架构便是主从复制架构.那么,我们首先来了解一 ...

  3. 新浪计数业务之Redis

    今天听一个同事说新浪使用的是Redis,于是自己将研究的过程整理出来以备后用. 我们都知道微博这玩意儿现在很火,新浪作为国内最早使用redis,并且是国内最大的redis使用者,当然备受人们关注.新浪 ...

  4. 实现Redis Cluster并实现Python链接集群

    目录 一.Redis Cluster简单介绍 二.背景 三.环境准备 3.1 主机环境 3.2 主机规划 四.部署Redis 4.1 安装Redis软件 4.2 编辑Redis配置文件 4.3 启动R ...

  5. Nginx集群配置与redis的session共享策略

    一.什么是Nginx? Nginx (engine x) 是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP服务器.Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Ramb ...

  6. Linux--6 redis订阅发布、持久化、集群cluster、nginx入门

    一.redis发布订阅 Redis 通过 PUBLISH .SUBSCRIBE 等命令实现了订阅与发布模式. 其实从Pub/Sub的机制来看,它更像是一个广播系统,多个Subscriber可以订阅多个 ...

  7. Redis集群(九):Redis Sharding集群Redis节点主从切换后客户端自动重新连接

    上文介绍了Redis Sharding集群的使用,点击阅读 本文介绍当某个Redis节点的Master节点发生问题,发生主从切换时,Jedis怎样自动重连新的Master节点 ​一.步骤如下: 1.配 ...

  8. Redis集群(八):Redis Sharding集群

    一.Redis目前的集群方案主要有两种:Redis Sharding和Redis Cluster 1.Redis Sharding:3.0以前基本上使用分片实现集群,目前主流方案,客户端实现 2.Re ...

  9. 分布式缓存技术redis学习系列(四)——redis高级应用(集群搭建、集群分区原理、集群操作)

    本文是redis学习系列的第四篇,前面我们学习了redis的数据结构和一些高级特性,点击下面链接可回看 <详细讲解redis数据结构(内存模型)以及常用命令> <redis高级应用( ...

随机推荐

  1. find tar排除指定文件或目录操作及查找文件内容关键字

    1.find查找排除单个目录 查找当前目录或者子目录下所有.txt文件,但是跳过子目录sk find . -path "./sk" -prune -o -name "*. ...

  2. Delphi idHttpServer接收Http Get请求解码问题

    引用 Httpapp单元,使用Httpdecode函数进行解码 procedure TFrmMain.HTTPServerCommandGet(AThread: TIdPeerThread; AReq ...

  3. Python的hasattr() getattr() setattr() 函数使用方法(简介)

    hasattr(object, name)判断一个对象里面是否有name属性或者name方法,返回BOOL值,有name特性返回True, 否则返回False.需要注意的是name要用括号括起来 1 ...

  4. Linux内核编译安装

    1. .config 复制一份当前系统编译时的配置,在/usr/src目录下 $ ls /usr/src/ linux-headers-4.10.0-35 linux-headers-4.8.0-36 ...

  5. 如何使用Bootstrap4显示和隐藏元素

    如何使用Bootstrap4显示和隐藏元素 为了更快地进行移动设备开发,请使用响应式显示类来按设备显示和隐藏元素.避免创建相同站点的完全不同版本,而是相应地为每个屏幕大小隐藏元素. 要隐藏元素,只需使 ...

  6. 基于ZooKeeper实现——分布式锁与实现

    引言 ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件.它是一个为分布式应用提供一致性服务的软件,提 ...

  7. 洛谷P2243 电路维修 [最短路]

    题目传送门 电路维修 题目背景 Elf 是来自Gliese 星球的少女,由于偶然的原因漂流到了地球上.在她无依无靠的时候,善良的运输队员Mark 和James 收留了她.Elf 很感谢Mark和Jam ...

  8. Sublime 编译运行JavaScript

    Tools > Build System > New Build System... { "cmd": ["node", "$file&q ...

  9. Linux-I/O五种模型

    一. 概念说明 在进行解释之前,首先要说明几个概念: 用户空间和内核空间 进程切换 进程的阻塞 文件描述符 缓存 I/O 同步(Sync)/异步(Async) 阻塞(Block)/非阻塞(Unbloc ...

  10. Linux下解压缩 - 中文解决方案

    命令行工具 Unar 以及 Lsar 安装:sudo apt-get install unar: 预览压缩包:lsar example.zip 解压缩:unar example.zip 指定位置解压: ...