社交巨头新浪微博@启盼cobain的Redis实战经验分享

随着应用程序对高性能的要求不断提高，NoSQL已逐渐扎根于大公司的系统架构中。在这里，我们将与您分享社交巨头新浪微博带来的Redis实践。首先，让我们看一下新浪微博@启盼cobain的Redis实践经验分享：

磁带已死，磁盘为磁带，闪存为磁盘，RAM局部性为王。 —吉姆·格雷

Redis不能替代更成熟的Memcache或Mysql。它是对大型Internet应用程序体系结构的很好的补充。现在，越来越多的应用程序也在基于Redis进行架构转换。首先，简要宣布Redis平台的实际情况：

它应该是相对较大的Redis平台。今天，我将从应用程序角度主要讨论Redis服务平台。

Redis使用场景

1.计数（计数）

计数的应用将在另一篇文章“计数方案的优化”中详细介绍

我不会在这里描述它。

可以预见，许多学生认为将所有计数存储在内存中非常昂贵。我将使用图表来表达我的看法：

在许多情况下，每个人都会认为纯粹的内存解决方案会非常昂贵，但实际情况通常会有所不同：

2.反向缓存（反向缓存）

面对微博上经常出现的热点，例如最近出现的相对流行的短链接，短时间内有成千上万的人点击跳跃，这里经常会有一些需求，例如我们在跳快速确定用户级别时，是否存在一些帐户绑定，性别爱好等，向他们显示了不同的内容或信息。

通常使用Memcache + Mysql解决方案。当呼叫ID合法时，它可以支持更大的吞吐量。但是，当呼叫ID不可控制并且有许多垃圾用户呼叫时，由于内存缓存未命中，它将大量渗透到Mysql服务器，从而导致连接数过长，导致总体吞吐量降低，并且响应时间很慢。

在这里，我们可以使用redis记录全部用户判断信息，例如字符串key：uid int：type，并进行反向缓存。用户在Redis中快速获得其级别和其他信息后，请转到Mc + Mysql层。获取完整的信息。如图所示：

当然，这不是最优化的方案，例如将Redis用作Bloomfilter，它可以节省更多内存。

3.前10名列表

产品操作将始终向您显示最近，最热，最高的点击率，最高的活动等条件的顶部列表。对于许多经常更新的列表，如果使用MC + MySQL维护缓存，则缓存失败的可能性会更大。考虑到较小的内存占用空间，使用Redis进行存储也很好。

4.最后一个索引

最近的用户访问记录也是Redis列表的良好应用方案。 lpush lpop自动使旧的登录记录失效，这对于开发仍然非常友好。

5.关系列表/消息队列

这两个功能放在最后，因为这两个功能在实际问题上遇到了一些困难，但是它们确实在某个阶段解决了我们的许多问题，因此我仅在这里进行解释。

消息队列用于通过列表的lpop和lpush接口写入和使用队列。它具有更好的性能，因此可以解决大多数问题。

6.与Lua快速交易

Redis的Lua功能的扩展实际上为Redis带来了更多的应用场景。您可以将几个命令组合编写为一个小的非阻塞事务或更新逻辑，例如：当您收到消息推送时，同时1.将未读对话添加到您自己的对话中2.将未读消息添加到您的对话中私人消息3.最后，将完整的推送消息发送到发件人的收据中。可以在Redis服务器端实现这一层逻辑。

但是，应该注意的是，Redis会将lua脚本的全部内容记录在aof中并将其发送到从属服务器，这对于磁盘和网卡也将是相当大的开销。

7.代替Memcache

许多测试和应用程序已经证明Redis在性能方面并不落后于memcache，但是单线程模型为Redis带来了强大的可伸缩性。在许多情况下，Redis对于同一数据段的内存开销小于内存缓存板分配的内存开销。 Redis提供的数据同步功能实际上是缓存的强大扩展。 Redis使用的要点

1. rdb / aof备份！

超过95％的Redis负责后端存储功能。我们不仅用作缓存，而且还用作kv存储。它完全替代了后端存储服务（MySQL），因此其数据非常重要。重要的是，如果存在数据污染，丢失，误操作等情况，将很难恢复。因此备份是非常必要的！为此，我们共享了hdfs资源作为我们的备份池，希望能够随时还原企业所需的数据。

2.小物品和小物品！

由于Redis单线程模型（严格意义上不是单线程，但是对请求的处理被认为是单线程），因此对大型数据结构列表，排序集和哈希集的批处理意味着等待对于其他请求，因此使用Redis复杂数据结构必须控制其单个键结构的大小。

此外，还应严格限制单个Redis实例的内存容量。当单个实例的内存容量很大时，直接的问题是从故障中恢复或从库中重建需要花费很长时间，更糟糕的是，当Redis重写aof并保存rdb时，它将带来非常长的时间系统。压力和占用额外的内存可能会导致严重影响性能的联机故障，例如系统内存不足。我们的96G / 128G内存服务器不建议单实例容量大于20 / 30G。

3.可用！

Redis前哨（哨兵）是行业中使用最广泛的。

2000行C实现服务器状态检测，自动故障转移等功能。

但是由于它本身的实际结构通常很复杂，或者有很多角度要考虑，因此，@许琦eryk和我一起做过催眠术。

催眠是神话中的睡眠之神。从字面上看，这意味着我们希望我们的工程师在休息期间无需处理任何故障。 ：-）

工作原理如下：

对话很便宜，请告诉我您的代码！稍后，我将写一个单独的博客来详细讨论Hypnos的实现。

4.是否在内存中？

我发现一种情况，开发人员经常在交流后端资源设计时由于习惯性使用和对产品定位的误解而忽略了对真实用户的评估。也许这是一段历史数据。任何人都只能访问最后一天的数据。将历史数据的容量和最后一天的请求量扔到内存中是非常不合理的。

因此，当您使用哪种类型的数据结构存储时，请务必先衡量成本。内存中需要存储多少数据？多少数据对用户真正有意义。因为这实际上对后端资源的设计至关重要，所以1G数据容量和1T数据容量对于设计思路完全不同

将来有计划吗？

1.从同步转换

要转变主从数据同步机制，我们借鉴MySQL复制的思想，并使用rdb + aof + pos作为数据同步的基础。这里有一个简短的解释，为什么官方的psync不能使我们满意。需求：

假设A具有两个从属库B和C，以及A`-B＆C，那么我们发现主A服务器具有停机的隐患，需要重新启动，否则A节点将直接关闭。我们需要将B切换到新的主库。如果A，B和C不共享RDB和AOF信息。当C作为B的从设备时，它仍将清除自己的数据，因为节点C仅记录与节点A的同步状态。

因此，我们需要一种同步机制将A`–B＆C结构切换为A`–B`–C结构。尽管psync支持可恢复的传输，但是它仍然不能支持主设备故障的平滑切换。

实际上，我们在定制的Redis计数服务上使用了上述功能的同步。效果非常好，解决了操作维护的负担。但是，它仍然需要升级到所有Redis服务。如果可能的话，我们还将向官方Redis提出建议。相关的同步从属改进。

2.更适合Redis名称系统或代理

专注的学生发现，除了使用DNS作为命名系统外，我们在zookeeper中也有记录。用户为什么不直接访问系统，zk或DNS？

实际上，它仍然非常简单。命名系统是一个非常重要的组件，而dns是一个相对完整的命名系统。为此，我们进行了许多改进和反复试验。 zk的实现仍然相对复杂，我们还不强。控件粒度。我们还在考虑如何使命名系统更符合我们的需求。

3.后端数据存储

使用大容量内存绝对是优化成本的重要方向。闪存盘和分布式存储也在我们的未来计划中。 （原始链接：有史以来最大的Redis集群）

2. Pinterest：Reids保持数百亿的相关性

Pinterest已成为硅谷最疯狂的故事之一。 2012年，他们基于PC的业务增长了1047％，移动终端采用率增长了1698％。同年3月，独立访问次数飙升至533亿。在Pinterest中，人们会注意数百亿个事物，每个用户界面都会查询特定的电路板，或者用户是否正在关注导致极其复杂的工程问题的行为。这也使Redis可以发挥作用。经过数年的发展，Pinterest已成为媒体和社交网络等许多领域的领导者。其辉煌的成就如下：

您可能会想，基于其独特的访问，Pinterest的高规模促成了对IT基础架构的非常高的需求。

通过缓存优化用户体验

最近，Pinterest工程经理Abhi Khune分享了他公司的用户体验要求和Redis体验。即使是产卵的应用程序创建者在分析网站的详细信息之前也不会理解这些功能，因此首先应大致了解其使用场景：首先，对提到的每个风扇进行预检查；其次，用户界面将准确显示用户的粉丝和观看列表页面。要高效地执行这些操作，每次点击都需要一个非常高性能的体系结构。

不被豁免。 Pinterest的软件工程师和架构师已经使用MySQL和内存缓存，但是缓存解决方案仍然遇到瓶颈。因此，为了获得更好的用户体验，必须扩展缓存。在实际的操作过程中，工程团队已经发现，只有当用户子图已经在缓存中时，缓存才起作用。所以。使用该系统的任何人都需要进行缓存，这会导致整个图形的缓存。同时，最常见的查询“用户A是否关注用户B”通常是负数，但这被认为是高速缓存丢失，这有利于查询，因此他们需要一种新的方法来扩展高速缓存。最后，他们的团队决定使用Redis来存储整个图，以服务众多列表。

使用Redis存储大量Pinterest列表

Pinterest使用Redis作为解决方案，并将性能提升到内存级别，为用户保存了多种类型的列表：

Redis为它的7000万用户存储了以上所有列表。从本质上讲，可以说它存储了所有粉丝图片，并按用户ID进行了切片。假定您可以按类型查看上述列表中的数据，则分析摘要信息将在看起来更像事务的系统中存储和访问。 Pinterest当前的用户喜欢度限制为100,000，并且初步统计：如果每个用户关注25个董事会，则该用户与董事会之间的关系为1 7. 5亿。同时，更重要的是，这些关系每天都随着系统的使用而增加。

Pinterest的Reids结构和操作

Pinterest的一位创始人了解到Pinterest开始使用Python和自定义的Django来编写应用程序，并且一直持续到拥有1800万用户和每天410TB的用户数据。尽管使用多个存储来存储数据，但是工程师基于用户ID使用了8192个虚拟分片。每个分片都在一个Redis DB上运行。同时，一个Redis实例将运行多个Redis。为了充分利用CPU内核，多线程和单线程Redis实例都在同一主机上使用。

由于整个数据集都在内存中运行，因此Redis将每秒传输的写入数据持久存储在Amazon EBS上。扩展主要从两个方面进行：首先，为了保持50％的利用率，通过主从转换，将在机器上运行的Redis实例的一半转换为新机器。第二，节点和分片的扩展。整个Redis群集将使用主从配置，而从属部分将被视为热备份。一旦主节点发生故障，从属部分将立即完成主转换，同时将添加新的从属部分，而ZooKeeper将完成整个过程。同时，他们将每小时在Amazon S3上运行BGsave以获得更持久的存储-此Reids操作将在后端执行，然后Pinterest将使用数据进行MapReduce和分析操作。

原始链接：

如果您认为本文对您有所帮助，则可以转发并关注该文章以获得支持

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-373453-1.html