国内外三个不同领域巨头分享的Redis实战经验及使用场景
发表于 09:03|
摘要：随着数据体积的激增，MySQL+memcache已经满足不了大型互联网类应用的需求，许多机构也纷纷选择Redis作为其架构上的补充，下面就一览新浪微博、Pinterest及Viacom的实践分享。
随着应用对高性能需求的增加，NoSQL逐渐在各大名企的系统架构中生根发芽。这里我们将为大家分享社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest带来的Redis实践，首先我们看新浪微博
的Redis实战经验分享：
新浪微博：史上最大的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（计数）
计数的应用在另外一篇文章里较详细的描述，计数场景的优化
这里就不多加描述了。
可以预见的是，有很多同学认为把计数全部存在内存中成本非常高，我在这里用个图表来表达下我的观点：
很多情况大家都会设想纯使用内存的方案会很有很高成本，但实际情况往往会有一些不一样：
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（哨兵）
2000行C实现了服务器状态检测，自动故障转移等功能。
但由于自身实际架构往往会复杂，或者考虑的角度比较多，为此
和我一同做了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盘及分布式的存储也在我们未来计划之中。（原文链接：
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章redis集群在腾讯游戏的应用及演进 - 下载频道
- CSDN.NET
&&&&redis集群在腾讯游戏的应用及演进
redis集群在腾讯游戏的应用及演进
redis集群在腾讯游戏的应用及演进,你值得拥有。
嵌到我的页面
<input type="text" readonly="true" value="">
若举报审核通过，可奖励20下载分
被举报人：
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：
您可能还需要
服务器应用下载排行腾讯互娱高级DBA康中良《Redis集群在腾讯游戏的应用及演变》_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
51CTO传媒集团旗下会议品牌
评价文档：
腾讯互娱高级DBA康中良《Redis集群在腾讯游戏的应用及演变》
阅读已结束，如果下载本文需要使用
想免费下载本文？
你可能喜欢游戏服务器使用MongoDB作为数据库，还有必要使用Redis缓存吗？
MongoDB本身就是内存数据库，在他和程序之间再加一道Redis缓存，是不是有点重复了？有没有好处？
按投票排序
看你做多大规模，比如，热数据（比如1天内频繁访问的）放 redis，冷数据（超过一天的）放 mongo。
用 id 取数据的时间复杂度，mongodb 加了索引是 O（log n），redis 是 O（1），你自己看着办吧。
把MongoDB当成MySQL, 把Redis当成内存跨服数据交换用Redis.
数据持久化用MongoDBRedis持久化别沾, 系统的未必适合游戏, 而自己做未必靠谱. 用专业的持久化DB才是正道
MongoDB不是内存型数据库，他只不过把所有文件索引存到内存里而已。同样的机型，用MongoDB会比Redis存更多，但Redis响应更快。关键的是看量有多大。
没必要，这两个都是kv型数据库。如果是要纯内存缓存的，建议用memcached效率更高。
没必要吧。按我的经验来看，一般游戏服务器往往会内置一个简单的缓存来保存热数据，没必要再加一个redis。当然，如果你们是php开发的，那就当我没说。
操作的数据用途不一样 Redis可做缓存 比如玩家数据 可以序列化进去 读取再反序列化 到程序，这样避免加载热点玩家数据读取数据库；monogdb嘛
现在项目也在用，但没觉得比mysql有什么好，别问我为什么要用，因为这是遗留问题。
题主需要储存的数据有哪些？不同的数据，对于存取效率的需求是否相同？是否存在需要反复修改的数据？是否有些数据量特别大，有些数据比较小？是否有数据需要分开处理？从我的经验来讲，我做的爬虫，一般是把url放在redis里面，而爬取到的数据放在MongoDB里面。这样做的好处是，对于MongoDB，只用来保存数据。爬到的数据存到里面就不管了。而对于Redis，它更像是一个队列，有源源不断的URL进去，有源源不断的URL出来，并且URL用过一次以后就就不需要了，再随着爬取到的数据一起存入MongoDB里面。我没有做过游戏服务器，对你的需求不清楚。但是我觉得，里面肯定有些数据对存取效率的需求会比其他的高吧，这个时候，把他们放在redis里面，其他的放在MongoDB里面。
这个主要还是看游戏的运营计划，如果是打算滚服的，那其实单服一般活跃用户最多也就一两千的量级（七日留存还有三五百的都算能活下来的了），单台物理机轻松搞定（甚至一台物理机开好几个区），那直接游戏服内做个简单的缓存系统，数据库mysql或者别的啥都可以，因为单服确实没多大数据量，还可以考虑定期将流失了的玩家数据序列化在磁盘上，万一哪天他回归了通过“找回老帐号”功能再反序列化出来写到库里就是了。但如果目标是搞个上万甚至数万人同时同服在线的话，那就得考虑做分布式的游戏服了。做个接入服务器来给游戏服集群做负载均衡，缓存系统上redis（或集群），单纯的作为缓存，不持久化。数据库嘛其实我觉得mysql或mongodb都可以，目前我用的mysql是可以搞定的。
两样都用的话，mong可以用来当数据库（非内存）redis用来当缓存系统！
Design case, and do performance test comparation
MongoDB是nosql数据库，它支持把一部分热数据放到内存中，方便用户更快的去处理它。Redis是内存型数据库，是完全的内存数据库！所有的数据都在内存，不存在硬盘一部分，内存一部分的情况。当然可以用save去存数据到硬盘，但这是为了备份安全性考虑而不是使用。
有必要,自己写个试试,吧,有必要的.}