随着对APP应用的高性能需求的增加，NoSQL逐渐成为各大公司的系统架构。 这里我将展示社交巨头新浪微博带来的Redis实践。 首先来看看新浪微博@启望cobain的Redis实战经验吧。
Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King. — Jim Gray
Redis并不是比较成熟的memcache和Mysql的替代品，而是大规模互联网类APP应用在体系结构上的很好补充。 目前，越来越多的APP应用基于Redis进行体系结构改造。 首先，简单公布Redis平台的实际情况。
200亿commands/day 5000亿Read/day 500亿write/day 18tb memory 500 servers in 6id c2000 instances应该是国内外比较大的Redis使用平台，今天主要是APP案例
http://www.Sina.com/http://www.Sina.com /
计数的应用将在另一篇文章中详细介绍，进行计数场景的优化
http://www.xdata.me/？ p=262
这里不多做说明。
可以预见的是，很多同学认为把计数全部存在内存中是非常昂贵的。 在这里用图表表达我的想法：
大多数情况下，假设只使用内存的方案成本较高，但实际上存在一些差异。
对于有一定吞吐量要求的APP应用，COST将分别申请数据库、Cache资源。 许多担心DB写入性能的同学会主动在异步队列中填写DB更新，但这三种资源的利用率一般都不高。 计算一下资源，令人惊讶的是，纯存储器的方案会更加简化！ KISS原则，这对开发非常友好，我只需要设置连接池，不用担心维护数据完整性，异步队列。 如果在后端使用DB，则Cache透明风险不会提供高吞吐量。 如果Cache停机没有得到妥善处理，那将是悲剧的。 大多数初始存储要求的容量都很小。Redis使用场景
就像最近出现了爆发性的短链一样，在微博上常见的热点中，短时间内就有数以万计的人点击和跳跃。 在这里，我们展示了快速跳转时判断用户等级、是否有账号关联、性别爱好等各种内容和信息。
常规的使用memcache Mysql的解决方案在id调用合法时支持大吞吐量。 但是，如果调用id无法控制，且有很多垃圾用户进行调用，memcache将无法命中，导致大量进入Mysql服务器，连接数量瞬间呈爆炸式增长，降低了整体吞吐量，降低了响应时间。
在此，用redis记录string key:uid int:type等全量的用户判定信息，生成反向的cache，用户在redis中快速取得自己的等级等信息后，到Mc Mysql层取得全量的信息图：
当然，这也不是优化的场景。 用Redis做bloom过滤器可能会节约内存。
1.Counting（计数）
在产品运营中，将展示最近最热、点击率最高、活跃度最高等条件的top list。 许多经常更新的列表在使用MC MySQL进行维护时很可能会禁用缓存。 考虑到内存消耗较少，使用Redis作为存储器也是不错的选择。
2.Reverse cache（反向cache）
用户最近的访问记录也是redis list的一个很好的应用场景，lpush lpop是自动过期的旧登录记录，对开发非常友好。
3.Top 10 list
这里把两个功能放在最后。 这两个功能在现实问题中遇到了一些困难，但在一定阶段确实解决了我们的很多问题，在此予以说明。
消息队列通过list的lpop以及lpush接口进行队列的写入和消耗，由于自身性能良好，可以解决大部分的问题。
4.Last Index
Redis的Lua功能扩展实际上给Redis带来了更多的应用场景。 例如，在收到消息推送时，同时1 .为自己添加未读的对话2 .为自己的私信添加未读的消息3 .最后向发件人添加完整的推送消息3 .这一层逻辑是完全的
但是，需要注意的是，Redis将lua script的所有内容记录在aof中，并将其传输到slave。 这也需要磁盘、网卡不少费用。
5.Relation List/Message Queue
许多测试和APP应用都证明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实现了服务器状态检测，自动故障转移等功能。
但由于自身实际架构往往会复杂，或者考虑的角度比较多，为此 @zqdxlberyk和我一同做了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）
2.Pinterest：Reids维护上百亿的相关性Pinterest已经成为硅谷最疯故事之一，在2012年，他们基于PC的业务增加1047%，移动端采用增加1698%， 该年3月其独立访问数量更飙升至533亿。在Pinterest，人们关注的事物以百亿记——每个用户界面都会查询某个board或者是用户是否关注的行为促成了异常复杂的工程问题。这也让Redis获得了用武之地。经过数年的发展，Pinterest已经成为媒体、社交等多个领域的佼佼者，其辉煌战绩如下：
获得的推荐流量高于Google+、YouTube及LinkedIn三者的总和与Facebook及Twitter一起成为最流行的三大社交网络参考Pinterest进行购买的用户比其它网站更高如您所想，基于其独立访问数，Pinterest的高规模促成了一个非常高的IT基础设施需求。
通过缓存来优化用户体验
近日，Pinterest工程经理Abhi Khune对其公司的用户体验需求及Redis的使用经验 进行了分享。即使是滋生的应用程序打造者，在分析网站的细节之前也不会理解这些特性，因此先大致的理解一下使用场景：首先，为每个粉丝进行提及到的预检查；其次，UI将准确的显示用户的粉丝及关注列表分页。高效的执行这些操作，每次点击都需要非常高的性能架构。
不能免俗，Pinterest的软件工程师及架构师已经使用了MySQL及memcache，但是缓存解决方案仍然达到了他们的瓶颈；因此为了拥有更好的用户体验，缓存必须被扩充。而在实际操作过程中，工程团队已然发现缓存只有当用户sub-graph已经在缓存中时才会起到作用。因此。任何使用这个系统的人都需要被缓存，这就导致了整个图的缓存。同时，最常见的查询“用户A是否关注了用户B”的da案经常是否定的，然而这却被作为了缓存丢失，从而促成一个数据库查询，因此他们需要一个新的方法来扩展缓存。最终，他们团队决定使用Redis来存储整个图，用以服务众多的列表。
使用Redis存储大量的Pinterest列表
Pinterest使用了Redis作为解决方案，并将性能推至了内存数据库等级，为用户保存多种类型列表：
关注者列表你所关注的board列表粉丝列表关注你board的用户列表某个用户中board中你没有关注的列表每个board的关注者及非关注者Redis为其7000万用户存储了以上的所有列表，本质上讲可以说是储存了所有粉丝图，通过用户ID分片。鉴于你可以通过类型来查看以上列表的数据，分析概要信息被用看起来更像事务的系统储存及访问。Pinterest当下的用户like被限制为10万，初略进行统计：如果每个用户关注25个board，将会在用户及board间产生17.5亿的关系。同时更加重要的是，这些关系随着系统的使用每天都会增加。
Pinterest的Reids架构及运营通过Pinterest的一个创始人了解到，Pinterest开始使用Python及订制的Django编写应用程序，并一直持续到其拥有1800万用户级日410TB用户数据的时候。虽然使用了多个存储对数据进行储存，工程师根据用户id使用了8192个虚拟分片，每个分片都运行在一个Redis DB之上，同时1个Redis实例将运行多个Redis DB。为了对CPU核心的充分使用，同一台主机上同时使用多线程和单线程Redis实例。
鉴于整个数据集运行在内存当中，Redis在Amazon EBS上对每秒传输进来的写入都会进行持久化。扩展主要通过两个方面进行：第一，保持50%的利用率，通过主从转换，机器上运行的Redis实例一半会转译到一个新机器上；第二，扩展节点和分片。整个Redis集群都会使用一个主从配置，从部分将被当做一个热备份。一旦主节点失败，从部分会立刻完成主的转换，同时一个新的从部分将会被添加，ZooKeeper将完成整个过程。同时他们每个小时都会在Amazon S3上运行BGsave做更持久的储存——这项Reids操作会在后端进行，之后Pinterest会使用这些数据做MapReduce和分析作业。
原文链接： http://www.cnblogs.com/tuyile006/p/14125030.html
如果觉得本文对你有帮助，可以关注一下我公众号，回复关键字【面试】即可得到一份Java核心知识点整理与一份面试大礼包！另有更多技术干货文章以及相关资料共享，大家一起学习进步！