运用经验：新浪微博和Pinterest以及Viacom对Redis数据库

新浪微博：历史上最大的Redis集群TapeisDead，DiskisTape，FlashisDisk，RAMLocalityisKing.—Jimgrayredis不是成熟的memcache或mysql的替代品，是大型互联网应用架构的良好补充。现在基于Redis进行架构改造的应用越来越多。首先简单公布Redis平台的实际情况:2200 亿commands/day5000亿Read/day500亿Write/day18TBT Memory500 Serversin6IDC20000 instances应该是国内外比较大的Redis使用平台，今天主要从应用的角度来谈Redis服务平台。使用Redis场景1.Counting(计数)计数的应用在另一篇文章中有详细的描述，计数场景优化http://www.xdata.me/?p=这里就不多描述262了。可以预见，很多学生认为把所有的计数都存储在内存中是非常昂贵的。我在这里用一张图表来表达我的观点：在很多情况下，每个人都会想象纯内存使用方案的成本会很高，但实际情况往往会有所不同：COST，对于有一定吞吐需求的应用程序，DB肯定会单独申请、Cache资源，许多担心DB写入性能的学生也会主动将DB更新记录在异步队列中，而这三部分的资源利用率一般不会太高。算下资源，你会惊讶地发现，纯内存的解决方案会更简洁！当你计算资源时，你会惊讶地发现纯内存的解决方案会更简洁！KISS原则对开发非常友好。我只需要建立一个连接池，不用担心数据一致性的维护和异步队列的维护。Cache穿透风险，如果后端使用DB，肯定不会提供很高的吞吐能力，如果Cache停机处理不当，那就是悲剧。大多数初始存储需求，容量小。2.Reversecache面对微博上经常出现的热点，比如最近流行的短链，成千上万的人在短时间内点击跳转，这里经常会出现一些需求，比如我们在快速跳转时判断用户级别，是否有一些账户绑定，性别爱好，已经向他们展示了不同的内容或信息。memcacachee通常使用 Mysql的解决方案，当调用id合法时，可以支撑更大的吞吐量。但是，当调用id无法控制，更多的垃圾用户调用id时，由于memcache没有命中，会大量穿透mysql服务器，瞬间导致连接数疯狂增长，整体吞吐量减少，响应时间减慢。在这里，我们可以用redis记录所有用户判断信息，如stringkeyy:uidint:type，做一个反向cache，当用户在redis中快速获取自己的等级信息时，再去Mcche Mysql层获取全量信息。如图所示：当然，这也不是最优化的场景，比如用Redis做blomfilter，可能会节省更多的内存。3.top10list产品运营总会让您展示最近、最热、点击率最高、活动度最高等条件的toplist。如果使用MC，许多更新更频繁的列表 如果MySQL进行维护，缓存更容易失效，鉴于内存占用较小，使用Redis作为存储也是相当不错的。4.Lastindex用户最近的访问记录也是redislist的好应用场景。lpushlpop自动过期的旧登录记录对开发非常友好。5.RelationList/MessageQueue在这里把两个功能放在最后，因为这两个功能在实际问题上遇到了一些困难，但在某个阶段确实解决了我们的许多问题，所以这里只解释一下。MessageQueue是通过listlpop和lpush接口编写和消耗队列，因为它的性能也可以解决大多数问题。6.FasttransactionwithluaredisLua的功能扩展实际上给Redis带来了更多的应用场景。您可以编写一些command组合作为小型非阻塞事务或更新逻辑，例如：当您收到message推送时，同时，1.给自己增加一个未读对话2。给自己的私信增加一个未读信息3。最后，给发送人一张完成推送信息的收据，这个逻辑可以在Redisserver端完全实现。但需要注意的是，Redis会在aof中记录luascript的所有内容，并将其传输给slave，这对磁盘和网卡来说也是一笔不小的开支。但需要注意的是，Redis会在aof中记录luascript的所有内容，并将其传输给slave，这对磁盘和网卡来说也是一笔不小的开支。7.Insteadofmemcache的许多测试和应用都证明，Redis在性能上并不落后于Memcache，而单线程模型给Redis带来了很强的可扩展性。在许多情况下，Redis对同一数据的内存费用小于memcache的slab分配。Redis提供的数据同步功能实际上是对cache的强大功能扩展。Redis使用的重点1.rdb/aofBackup!超过95%的在线Redis承担后端存储功能。我们不仅将其用作cache，还将其用作k-v存储。它完全取代了后端存储服务（MySQL），因此，数据非常重要。如果出现数据污染和丢失、误操作等情况，将难以恢复。所以备份是非常必要的！为此，我们有共享的hdfs资源作为我们的备份池，希望能够随时还原业务所需的数据。2.Smallitem&Smallinstance!由于Redis单线程模型(严格意义上不是单线程，但认为Request的处理是单线程)，大数据结构list，sortedset,hashset的批量处理意味着等待其他请求，因此使用redis的复杂数据结构必须控制其单key-struct的大小。此外，Redis单实例的内存容量也应受到严格限制。单实例内存容量大后，直接带来的问题是故障恢复或Rebuild从库中需要很长时间。更糟糕的是，Redisrewriteaof和Saverdb将带来非常大和长的系统压力，并占用额外的内存，这可能导致严重影响性能的在线故障，如系统内存不足。在线96G/128G内存服务器不建议单实例容量大于20/30G。3.BeenAvailable!Redissentinel(哨兵)更多地用于行业信息和使用http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.htmlhttp://qiita.com/wellflat/items/8935016fde25d486d92000行C实现服务器状态检测，自动故障转移等功能。但由于自己的实际结构往往比较复杂，或者考虑的角度比较多，所以@徐琦eryk和我一起做了hypnos项目。然而，由于他们自己的实际结构往往很复杂，或者从更多的角度考虑，@徐琦和我一起做了hypnos项目。hypnos是神话中的睡眠，字面意思是我们的工程师不需要在休息时间处理任何故障。:-)其工作原理如下：Talkischeap,showmeyourcode!稍后将单独写一篇博客详细介绍Hypnos的实现情况。4.InMemoryornot?在沟通后端资源设计时，我们经常忽视对真实用户的评价，因为我们习惯于使用和错误地理解产品定位。也许这是一个历史数据，只有最近一天的数据被访问，把历史数据的容量和最近一天的请求留给内存存储是非常不合理的。因此，当您使用什么样的数据结构存储时，请务必先衡量成本。内存中需要存储多少数据？对用户真正有意义的数据有多少？因为这其实对后端资源的设计非常重要，1G的数据容量和1T的数据容量在设计理念上是完全不同的。1.slavesync改造所有在线master-slave数据同步机制，借鉴了mysqreplication的思路，利用rdbber-slave数据同步机制 aof 作为数据同步的基础，pos简要说明了为什么官方提供的psync不能很好地满足我们的需求：假设有两个来自库B和C，以及A`—B&C，此时，我们发现mastera服务器存在停机隐患，需要重启或A节点直接停机，如果A、B、C不共享rdb和aof信息，C在从库作为B时仍会清除自己的数据，因为C节点只记录与A节点的同步。因此，我们需要有一种方法可以让AA`–B&C结构切换换为A`–B`–虽然psync支持断点续传，但仍不能支持master故障的平滑切换。事实上，我们在定制的Redis计数服务中使用了上述功能的同步，效果非常好，解决了操作和维护的负担，但我们仍然需要推广到所有的Redis服务，如果可能的话，我们也会向官方Redis提出相关的Syncslave改进。2.更适合redisname-systemorproxy的学生发现，除了使用DNS作为命名系统外，我们还记录了zookeper。为什么不让用户直接访问系统，zk或DNS选择其中一个？事实上，这仍然很简单。命名系统是一个非常重要的组成部分，dns是一个相对完善的命名系统。我们做了很多改进和试错。zk的实现仍然相对复杂，我们没有强大的粒度控制。事实上，这仍然很简单。命名系统是一个非常重要的组成部分，dns是一个相对完善的命名系统。我们做了很多改进和试错。zk的实现仍然相对复杂，我们没有强大的粒度控制。我们也在思考什么样的命名系统更符合我们的需要。3.使用后端数据存储大内存必须是成本优化的重要方向，flash磁盘和分布式存储也在我们未来的计划中。二、Pinterest：Pinterest已经成为硅谷最疯狂的故事之一。2012年，基于PC的业务增加了1047%，移动终端增加了1698%。今年3月，其独立访问量飙升至533亿。在Pinterest中，人们*的是100亿件事——每个用户界面都会查询board或用户是否*的行为，这导致了极其复杂的工程问题。这也让Redis得到了用武之地。经过多年的发展，Pinterest已成为媒体、社交网络等领域的领导者，其辉煌成就如下：推荐流量高于谷歌 、YouTube和Linkedin的总和与Facebook和Twitter一起成为最受欢迎的三大社交网络参考Pinterest购买的用户比其他网站更高，Pinterest的高规模基于其独立访问量，促成了对IT基础设施的高需求。最近，Pinterest工程经理Abhikhune通过缓存优化了用户体验，分享了公司的用户体验需求和Redis的使用经验。即使是繁殖的应用程序创建者在分析网站的细节之前也不会理解这些特征，所以首先对使用场景有一个大致的了解：首先，对每个粉丝提到的预检查；其次，UI将准确显示用户的粉丝和*列表页面。即使是繁殖的应用程序创建者在分析网站的细节之前也不会理解这些特征，所以首先对使用场景有一个大致的了解：首先，对每个粉丝提到的预检查；其次，UI将准确显示用户的粉丝和*列表页面。为了有效地执行这些操作，每次点击都需要一个非常高的性能架构。Pinterest的软件工程师和架构师使用了MySQL和Memcache，但缓存解决方案仍然达到瓶颈；因此，缓存必须扩展，以获得更好的用户体验。在实际操作过程中，工程团队发现缓存只有在用户sub-graph已经在缓存中工作时才能工作。因此。任何使用该系统的人都需要缓存，这导致了整个图片的缓存。与此同时，最常见的问题是“用户A是否*用户B”的答案往往是否定的，但它被用作缓存丢失，以促进数据库查询，因此他们需要一种新的方法来扩展缓存。最终，他们的团队决定使用Redis来存储整个图表，以便为许多列表提供服务。2.使用Redis存储大量Pinterest列表Pinterest使用Redis作为解决方案，并将性能推到内存数据库级别，为用户保存多种类型的列表:*者列表你*的board列表粉丝列表*你的board用户列表你没有*的board列表每个board*者和非*者Redis为7000万用户存储了以上所有列表，本质上可以说是通过用户ID存储了所有的粉丝图片。鉴于您可以通过类型查看上述列表的数据，分析系统的存储和访问，这些系统看起来更像是事务。鉴于您可以通过类型查看上述列表的数据，并分析系统存储和访问看起来更像事务的概要信息。Pinterest目前的用户列表仅限于10万，初步统计：如果每个用户*25个board，用户和board之间将有17.5亿的关系。更重要的是，随着系统的使用，这些关系每天都在增加。3.Pinterest的Reids架构和运营通过Pinterest的一位创始人了解到，Pinterest开始使用Python和定制的Django编写应用程序，直到它拥有1800万用户的410TB用户数据。虽然数据存储使用多个存储，但工程师根据用户ID使用8192个虚拟分片，每个分片都在运行