mongodb mapreduce使用场景,mongodb做缓存

　　随着人们对APP应用的高性能需求日益增加，NoSQL逐渐成为各大公司的系统架构。这里我就展示一下社交巨头新浪微博带来的Redis的做法。我们先来看看新浪微博@齐王科本的Redis实战经验。

　　磁带是死的，磁盘是磁带，闪存是磁盘，RAM本地为王。—吉姆格雷

　　Redis并不是memcache和Mysql的成熟替代品，而是大型互联网APP应用架构的良好补充。目前越来越多的APP应用基于Redis进行改造。先简单公布一下Redis平台的实际情况。

　　200亿条命令/天5000亿次读取/天500亿次写入/天18tb内存500台服务器6idc2000个实例应该是国内外比较大的Redis平台，今天主要是一个APP案例。

　　http://www。Sina.com/http://www.Sina.com/

　　计数的应用将在另一篇文章中详细介绍，以优化计数场景。

　　http://www.xdata.me/?p=262

　　这里不多解释。

　　可以预见，许多学生认为在内存中存储所有的计数是非常昂贵的。这里有一个图表来表达我的想法：

　　在大多数情况下，假设只使用内存的方案开销很大，但实际上还是有一些区别的。

　　对于有一定吞吐量要求的APP应用，成本将分别适用于数据库和缓存资源。很多担心DB写性能的同学会主动在异步队列中填充DB更新，但这三种资源的利用率普遍不高。计算资源。出人意料的是，纯内存的方案会更加简化！KISS原理，对开发非常友好。我只需要设置连接池，不用担心维护数据完整性和异步队列。如果在后端使用DB，缓存透明性风险将不会提供高吞吐量。如果缓存宕机处理不当，将是一场悲剧。大多数初始存储需求都很小。Redis使用场景

　　就像最近爆出来的短链，短时间内就有几万人在微博热点里点击跳转。这里展示了判断用户级别、是否有账号关联、性别爱好等各种内容和信息。在快速跳跃时。

　　当id调用合法时，使用memcache Mysql的传统解决方案支持大吞吐量。但如果调用id无法控制，有大量垃圾用户调用，memcache就会打不中，导致大量连接进入Mysql服务器，连接数量瞬间爆炸，降低整体吞吐量和响应时间。

　　这里redis用来记录字符串key:uid int:type等用户判断信息的全量，并生成反向缓存。用户在redis中快速获得自己的级别信息后，就可以在McMMySQL层获得全量信息图：

　　当然，这也不是一个优化的场景。使用Redis作为布隆过滤器可以节省内存。

　　1.Counting（计数）

　　在产品运营中，会显示最近最火、点击率最高、活跃度最高的top榜单。在使用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脚本的所有内容都记录在一个aof中，并发送给slave。这也需要大量的磁盘和网卡成本。

　　5.Relation List/Message Queue

　　很多测试和APP应用都证明Redis在性能上并不落后于memcache，但是单线程的模式给Redis带来了很强的可扩展性。非常

　　在多种场景下，Redis对相同数据的内存开销小于memcache的slab分配。Redis提供的数据同步功能，其实是缓存的强大功能扩展。Redis使用的重要点1.rdb/aof Backup!

　　我们在线Redis 95%以上都是负责后台存储功能的。我们不仅把它作为缓存，也作为一种k-v存储。它完全取代了后端存储服务(MySQL)，所以它的数据非常重要。如果有数据污染、丢失、误操作，就很难恢复。所以备份是非常必要的！为此，我们共享了hdfs资源作为我们的备份池，希望能够随时恢复业务所需的数据。

　　2.Small item Small instance!

　　由于Redis的单线程模型(严格来说不是单线程，但是请求的处理是单线程的)，大数据结构链表、有序集、哈希集的批量处理意味着等待其他请求，所以在使用Redis的复杂数据结构时，必须控制单个key-struct的大小。

　　此外，应该严格限制Redis的单个实例的内存容量。当单个实例具有大的内存容量时，直接的问题是需要很长时间来从故障中恢复或从库中重建。更糟糕的是，使用Redis重写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-line C实现了服务器状态检测和自动故障转移功能。

　　但由于其实际架构的复杂性，或者说是多角度的考虑，@zqdxlberyk和我一起做过hypnos项目。

　　修普诺斯是神话中的睡神，字面意思是我们工程师在休息时间不用处理任何故障。-)

　　其工作原理如下：

　　空谈不值钱，给我看看你的代码！稍后，我将单独写一篇博客详细介绍修普诺斯的实现。

　　4.In Memory or not?

　　发现开发者在沟通后端资源设计时，往往因为习惯性使用和对产品定位的错误理解而忽略了对真实用户的评价。可能这是一个历史数据，只能访问最近一天的数据，把历史数据的容量和最近一天的请求丢给内存存储现实是非常不合理的。

　　所以，在用什么样的数据结构来存储短心情的时候，请务必先衡量一下成本。需要在内存中存储多少数据？有多少数据对用户真正有意义。因为这对后端资源的设计至关重要，1G的数据容量和1T的数据容量在设计思路上是完全不同的。

　　Plans in future?1.slave sync改造

　　改造所有在线主从数据同步机制。我们借鉴了MySQL复制的思想，使用pos的rdb aof作为数据同步的基础。下面简单解释一下为什么官方psync没有很好的满足我们的需求：

　　假设A有两个从库B和C，以及一个`— BC。这时候我们发现主A服务器有宕机隐患，需要重启，或者节点A直接宕机，需要切换B到新的主库。如果A、B、C不共享rdb和aof信息，C在作为B的从库时仍然会清除自己的数据，因为节点C只记录与节点A的同步状态。

　　因此，我们需要一个同步机制来将A`-BC结构切换到a`b`C结构。虽然psync支持断点续传，但仍然不能支持主故障的平滑切换。

　　其实我们已经在我们定制的再贴现服务上使用了上述功能的同步，效果非常好，解决了运维的负担。但是，仍需向所有Redis服务推广。如果可能的话，我们也会向官方Redis提出相关同步从的改进。

　　2.更适合redis的name-system Or proxy

　　细心的同学发现，除了使用DNS作为命名系统，我们在zookeeper中也有记录。为什么不让用户直接访问一个系统，zk或者DNS选一个？

　　其实很简单。命名系统是一个非常重要的组成部分，dns是一个比较完整的命名系统。我们为此做了很多改进和试错。zk的实现还是比较复杂的，我们没有很强的控制粒度。我们也在思考什么样的命名体系更能满足我们的需求。

　　3.后端数据存储

　　大内存的使用肯定是一个重要的成本优化方向，闪存盘和分布式存储也在我们未来的计划中。(原文链接：有史以来最大的Redis集群)

　　2.Pinterest：Reids维护上百亿的相关性Pinterest已经成为硅谷最疯狂的故事之一。2012年，他们基于PC的业务增长了1047%，移动应用增长了1698%。当年3月，独立访问量飙升至533亿。在Pinterest，人们关注了几百亿的东西，——。每个用户界面都会查询某个板卡或者用户是否关注，这就导致了极其复杂的工程问题。这也使得Redis很有用。经过几年的发展，Pinterest已经成为媒体、社交等领域的领导者。其辉煌战绩如下：

　　推荐流量高于谷歌、YouTube和LinkedIn的总和，它们与脸书和Twitter一起成为最受欢迎的三大社交网络。相比其他网站，更多的用户会参考Pinterest进行购买。正如你所料，根据独立访问量，Pinterest的高规模促成了非常高的IT基础设施需求。

　　通过缓存来优化用户体验

　　最近，Pinterest工程经理Abhi Khune分享了他公司的用户体验需求和Redis体验。即使是应用构建者这种品种，在分析网站细节之前也不会了解这些特性，所以先大致了解一下使用场景：首先对每个粉丝进行前面提到的预检；其次，UI会精准显示用户的粉丝和关注列表分页。为了高效地执行这些操作，每次点击都需要非常高性能的架构。

　　这是无法避免的。Pinterest的软件工程师和架构师已经使用了MySQL和memcache，但是缓存解决方案仍然达到了他们的瓶颈；因此，为了有更好的用户体验，必须扩展缓存。在实际操作中，工程团队发现，只有当用户子图已经在缓存中时，缓存才会起作用。因此。任何使用这个系统的人都需要缓存，这就导致了整个图的缓存。同时，最常见的“用户A是否关注用户B”的da情况往往是否定的，但是作为缓存丢失了，导致数据库查询，所以他们需要一种新的方法来扩展缓存。最后，他们的团队决定使用Redis来存储整个图表，以便为众多的列表提供服务。

　　使用Redis存储大量的Pinterest列表

　　Pinterest使用Redis作为解决方案，并将性能提升到内存数据库的水平，为用户保存各种类型的列表：

　　关注者列表：你的关注者列表，你的粉丝列表，关注你的版块的用户列表，不关注你的版块的用户列表。Redis，每个董事会的追随者和非追随者，为其7000万用户存储上述所有列表。本质上可以说，所有的粉丝图片都是按用户id存储切片的。因为您可以按类型查看上面列表中的数据，所以分析摘要信息是由一个看起来更像事务的系统存储和访问的。Pinterest目前用户的赞数限制在10万。据初步统计，如果每个用户关注25个版块，那么用户和版块的关系就有17.5亿次。同时，更重要的是，这些关系会随着系统的使用而与日俱增。

　　Pinterest的Reids架构和运营是由Pinterest的一位创始人学习的。Pinterest开始用Python写应用，定制Django，一直持续到拥有每天410TB的1800万用户级数据。虽然使用多个存储来存储数据，但是工程师根据用户id使用8192个虚拟分片，每个分片运行在一个Redis DB上，一个Redis实例会运行多个Redis DB。为了充分利用CPU内核，在同一台主机上使用多线程和单线程Redis实例。

　　由于整个数据集都在内存中运行，Redis会在Amazon EBS上保存每秒钟写入的数据。扩展主要通过两个方面进行：一是利用率保持在50%，一台机器上运行的Redis实例有一半会通过主从转换翻译到新机器上；第二，展开节点和片段。整个Redis集群将使用主-从配置，从部分将被视为热备份。一旦主节点失效，从部分会立即完成主转换，并增加一个新的从部分，ZooKeeper会完成整个过程。与此同时，他们将每小时在亚马逊S3上运行BGsave，以便更长时间地存储——。这个Reids操作会在后端进行，然后Pinterest会用这些数据做MapReduce和分析。

　　原文链接：http://www.cnblogs.com/tuyile006/p/14125030.html

　　如果你觉得这篇文章对你有帮助，可以关注我的微信官方账号，回复关键词【面试】即可获得Java核心知识点汇编和面试大礼包！还有更多技术干货文章和相关资料可以分享。让我们一起学习，一起进步！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。