国内外三个不一样领域巨头分享的Redis实战经验及使用场景(二)

摘要：随着数据体积的激增，MySQL+memcache已经知足不了大型互联网类应用的需求，许多机构也纷纷选择Redis做为其架构上的补充，下面就一览新浪微博、Pinterest及Viacom的实践分享。

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和分析做业。（更多内容见原文）

Viacom：Redis在系统中的用例盘点

Viacom是全球最大的传媒集体之一，同时也遭遇了当下最大的数据难题之一：如何处理日益剧增的动态视频内容。

着眼这一挑战的上升趋势，咱们会发现：2010年世界上全部数据体积达到ZB级，而单单2012这一年，互联网产生的数据就增长了2.8个ZB，其中大部分的数据都是非结构化的，包括了视频和图片。

覆盖MVN（之前称为MTV Networks、Paramount及BET），Viacom是个名副其实的传媒巨头，支持众多人气站点，其中包括The Daily Show、osh.0、South Park Studios、GameTrailers.com等。做为媒体公司，这些网站上的文档、图片、视频短片都在无时无刻的更新。长话短说，下面就进入Viacom高级架构师Michael Venezia 分享的Redis实践：

Viacom的网站架构背景

对于Viacom，横跨多个站点传播内容让必须专一于规模的需求，同时为了将内容竟可能快的传播到相应用户，他们还必须聚焦内容之间的关系。然而即便The Daily Show、Nickelodeon、Spike或者是VH1 这些单独的网站上，日平均PV均可以达到千万，峰值时流量更会达到平均值的20-30倍。同时基于对实时的需求，动态的规模及速度已成为架构的基础之一。

除去动态规模以外，服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜爱。好比说，某个页面可能会将一个独立的视频片断与本地的促销，视频系列的额外部分，甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间，他们创建了一个能基于详细元数据自动创建页面的软件引擎，这个引擎能够根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变，数据的类型很是普遍——相似graph-like，实际上作的是大量的join。

这样作有利于减小相似视频的大致积文件副本数，好比数据存储中一个独立的记录是Southpark片断“Cartman gets an Anal Probe”，这个片断可能也会出如今德语的网站上。虽然视频是同样的，可是英语用户搜索的可能就是另外一个不一样的词语。元数据的副本转换成搜索结果，并指向相同的视频。所以在美国用户搜索真实标题的状况下，德国浏览者可能会使用转译的标题——德国网站上的“Cartman und die Analsonde”。

这些元数据覆盖了其它记录或者是对象，同时还能够根据使用环境来改变内容，经过不一样的规则集来限制不一样地理位置或者是设备请求的内容。

Viacom的实现方法

尽管许多机构经过使用ORM及传统关系型数据库来解决这个问题，Viacom却使用了一个迥然不一样的方法。

本质上，他们彻底承担不了对数据库的直接访问。首先，他们处理的大部分都是流数据，他们偏向于使用Akamai从地理上来分配内容。其次，基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能，所以JSON在1个数据服务中投入了使用。固然，这些JSON对象的缓存将直接影响到网站性能。同时，当内容或者是内容之间的关系发生改变时，缓存还须要动态的进行更新。

Viacom依靠对象基元和超类解决这个问题，继续以South Park为例：一个私有的“episode”类包含了全部该片断相关信息，一个“super object”将有助于发现实际的视频对象。超类这个思想确实很是有益于建设低延迟页面的自动建设，这些超类能够帮助到基元对象到缓存的映射及保存。

Viacom为何要使用Redis

每当Viacom上传一个视频片断，系统将创建一个私有的对象，并于1个超类关联。每一次修改，他们都须要重估私有对象的每一个改变，并更新全部复合对象。同时，系统还须要无效Akamail中的URL请求。系统现有架构的组合及更敏捷的管理方法需求将Viacom推向了Redis。

基于Viacom主要基于PHP，因此这个解决方案必须支持PHP。他们首先选择了memcached作对象存储，可是它并不能很好的支持hashmap；同时他们还须要一个更有效的进行无效步骤的重估，即更好的理解内容的依赖性。本质上说，他们须要时刻跟进无效步骤中的依赖性改变。所以他们选择了Redis及Predis的组合来解决这个问题。

他们团队使用Redis给southparkstudios.com和thedailyshow.com两个网站建设依赖性图，在取得了很大的成功后他们开始着眼Redis其它适合场景。

Redis的其它使用场景

显而易见，若是有人使用Redis来建设依赖性图，那么使用它来作对象处理也是说得通的。一样，这也成了架构团队为Redis选择的第二使用场景。Redis的复制及持久化特性同时也征服了Viacom的运营团队，所以在几个开发周期后，Redis成为他们网站的主要数据及依赖性储存。

后两个用例则是行为追踪及浏览计数的缓冲，改变后的架构是Redis每几分钟向MySQL中储存一次，而浏览计数则经过Redis进行存储及计数。同时Redis还被用来作人气的计算，一个基于访问数及访问时间的得分系统——若是某个视频最近被访问的次数越多，它的人气就越高。在如此多内容上每隔10-15分钟作一次计算绝对不是相似MySQL这样传统关系型数据库的强项，Viacom使用Redis的理由也很是简单——在1个存储浏览信息的Redis实例上运行Lua批处理做业，计算出全部的得分表。信息被拷贝到另外一个Redis实例上，用以支持相关的产品查询。同时还在MySQL上作了另外一个备份，用以之后的分析，这种组合会将这个过程耗费的时间下降60倍。

Viacom还使用Redis存储一步做业信息，这些信息被插入一个列表中，工做人员则使用BLPOP命令行在队列中抓取顶端的任务。同时zsets被用于从众多社交网络（好比Twitter及Tumblr）上综合内容，Viacom经过Brightcove视频播放器来同步多个内容管理系统。

横跨这些用例，几乎全部的Redis命令都被使用——sets、lists、zlists、hashmaps、scripts、counters等。同时，Redis也成为Viacom可扩展架构中不可或缺的一环。