| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
e21er2131
6年前发布

日请求量过亿,谈陌陌的 Feed 服务优化之路

   <p>摘要: 先从产品层⾯面介绍一下Feed业务。Feed本⾝身就是一段简短文字加一张图片,带有位置信息,发布之后可以被好友和附近的人看到,通过点赞评论的方式互动。类似微博和朋友圈。</p>    <p><img src="https://simg.open-open.com/show/395b5e635b9260935e417c967fabe36f.jpg"></p>    <p>先从产品层⾯面介绍一下Feed业务。Feed本⾝身就是一段简短文字加一张图片,带有位置信息,发布之后可以被好友和附近的人看到,通过点赞评论的方式互动。类似微博和朋友圈。</p>    <p><img src="https://simg.open-open.com/show/12ed2c54e3f5bd0b8a695ee90012b774.jpg"></p>    <p>陌陌上季度的MAU为6980万,Feed作为主要的社交业务,从2013年上线到现在,日请求量超过亿,总数据量超过百亿。下面是Feed系统的整体架构图:</p>    <p><img src="https://simg.open-open.com/show/85cd6cefe8ae29204eb51593e61942b5.jpg"></p>    <ul>     <li> <p>资源层主要使用Redis、MongoDB、HBase等NoSQL类型数据库。</p> </li>     <li> <p>存储层是内部RPC服务,根据业务场景和存储特性,组合各种数据库资源。</p> </li>     <li> <p>业务层调用存储层读写数据,实现产品逻辑,直接面向用户使用。</p> </li>    </ul>    <p>内容存储(Feed Content)</p>    <p>首先介绍Feed内容海量数据存储优化。</p>    <p>Feed内容是json格式,对schema没有做严格限制,可以根据业务灵活扩展,下面是一个基础的结构:</p>    <p>{"content":"今天天⽓气不错啊","id":"88888888","time":1460198781,"owner":"25927525"}</p>    <p>最初使用MongoDB做持久化存储,MongoDB本身对JSON⽀支持非常好,这样从前端API的输出格式到底层数据存储都是统一的,非常简洁。MongoDB另外一个优势是不需要预先定义结构,灵活的增减字段,支持复杂查询,非常适合创业阶段 <strong>快速迭代</strong> 开发。</p>    <p>Feed内容存储是整个系统访问量最大的部分,QPS达到几十万,MongoDB的查询性能不能满足线上要求,在前端使用Redis集群做LRU缓存,缓存id和对应的content。</p>    <p>移动社交产品的热点数据大部分是最近产生的,LRU缓存可以扛住99.5%的线上请求。通过监控,miss(每秒穿透)和evict(每秒逐出)两个指标,用来评估缓存容量,适时扩容。</p>    <p>这里特别说一下,为了快速大规模扩容,Redis的LRU缓存集群没有采用一致性hash,而是最简单 <strong>Mod取余的hash</strong> 方式。通过节点数据复制,快速的翻倍扩容,省去了缓存预热的过程。</p>    <p>随着数据量的增长,MongoDB需要不断扩容,单个MongoDB实例占用空间接近硬盘的上限。而且读性能太低成为瓶颈。最终将持久化迁移到Hbase,废弃掉了MongoDB在线上的使用。</p>    <p>好友动态( Feed timeline)</p>    <p>接下来介绍好友动态(timeline)实现和优化过程。好友动态(timeline)通过好友关系聚合内容,按时间排序,类似微信的朋友圈。</p>    <p>Timeline使用Redis的zset结构做存储,天然有序,支持原子的增/删/查询操作。和早期SNS系统MySQL+Memcached相比,实现简单很多,大部分业务一行代码搞定:</p>    <ol>     <li> <p>ZADD timeline 1460198781 88888888 //插入一条feed_id为88888888的Feed,插入时间为1460198781</p> </li>     <li> <p>ZREVRANGE timeline 0 100 //查看最近的100条Feed</p> </li>    </ol>    <p>关于Feed系统的 <strong>推(push)模式</strong> 和 <strong>拉(pull)模式</strong> 有很多讨论。</p>    <p>陌陌最初使用的是推的模式,也就是发布Feed后,异步插入到每个好友的timeline。这种方式读取效率高,可以看作O(1)的操作。但是写操作开销大,每秒1000条Feed,每人N个好友,会产生1000*N的OPS,而且一个feed_id重复保存N次,产生大量冗余数据。</p>    <p>随着用户产生数据的积累,长尾效应明显,冷数据占比会越来越高。而且redis对小zset采用ziplist的方式紧凑存储,列表增长会转换为skiplist,内存利用率下降。存储timeline的Redis集群近百台服务器,成本太高,推动改造为拉的模式。</p>    <p>通过timeline聚合层,根据用户的好友关系和个人Feed列表,找到上次访问之后产生的新Feed, <strong>增量实时聚合</strong> 新内容。大致步骤:</p>    <ol>     <li> <p>遍历我的好友,找到最近发表过Feed的人</p> </li>     <li> <p>遍历最近发表过Feed的人,得到id和time</p> </li>     <li> <p>合并到我的timeline</p> </li>    </ol>    <p>聚合过程采用多线程并行执行,总体聚合时间平均20ms以下,对查询性能影响很小。</p>    <p>改为拉模式后,timeline从 <strong>存储变为缓存</strong> ,冷数据可以被淘汰删除,timeline不存在的则触发全量聚合,性能上也可以接受。redis集群只缓存最近的热点数据,解决了存储成本高的问题,服务器规模下降了 <strong>一个数量级</strong> 。</p>    <p>附近动态 (Nearby Feed)</p>    <p>最后介绍LBS的附近动态空间查询性能优化,也是有特色的地方。</p>    <p>陌陌上每一条Feed都带有经纬度信息,附近动态是基于位置的timeline,可以看到附近5公里范围内最新的Feed。技术上的难点在于每个人的位置都不一样,每个人看到内容也不同, <strong>需要实时计算无法缓存</strong> 。</p>    <p>第一个版本用mongo的2D索引实现空间查询:</p>    <p>feeds.find({location : {"$near" : [39.9937,116.4361]}}).sort({time:-1});</p>    <p>由于mongo的2D查询不能建立联合索引,按时间排序的话,性能比较低,超过100ms。通过数据文件挂载在内存盘上和按地理位置partition的方法,做了一些优化,效果还是不理想。</p>    <p>第二个版本,采用geohash算法实现了更高效的空间查询。</p>    <p>首先介绍geohash。geohash将二维的经纬度转换成字符串,例如经纬度39.9937,116.4361对应的geohash为wx4g9。每个geohash对应一个矩形区域,矩形范围内的经纬度的geohash是相同的。</p>    <p>根据Feed的经纬度,计算geohash,空间索引使用Redis的zset结构,将geohash作为空间索引的key,feed_id作为member,时间作为score。</p>    <p>查询时根据用户当前经纬度,计算geohash,就能找到他附近的Feed。但存在 <strong>边界问题</strong> ,附近的Feed不一定在同一个矩形区域内。如下图:</p>    <p><img src="https://simg.open-open.com/show/9841d926cd32a48d6e17529acad84757.jpg"></p>    <p>解决这个问题可以在查询时扩大范围,除了查询用户所在的矩形外,还扩散搜索相邻的8个矩形,将9个矩形合并(如下图),按时间排序,过滤掉超出距离范围的Feed,最后做分页查询。</p>    <p><img src="https://simg.open-open.com/show/28b56c928c1d2792f1476227da15f942.jpg"></p>    <p>wx4g9相邻的8个 geohash :wx4gb,wx4gc,wx4gf,wx4g8,wx4gd,wx4g2,wx4g3,wx4g6。</p>    <p>归纳为四个步骤: <strong>ExtendSearch</strong> ->  <strong>MergeAndSort</strong> ->  <strong>DistanceFilter</strong> ->  <strong>Skip</strong> 。</p>    <p>但是这种方式查询效率比较低,作为读远远大于写的场景,换了一种思路,在 <strong>更新Feed空间索引</strong> 时,将Feed写入相邻的8个矩形,这样每个矩形还包含了相邻矩形的Feed,查询省去了</p>    <p>ExtendSearch和MergeAndSort两个步骤。</p>    <p>通过数据冗余的方式,换取了更高的查询效率。将复杂的geo查询,简化为redis的zrange操作,性能 <strong>提高了一个数量级</strong> ,平均耗时降到3ms。空间索引通过geohash分片到redis节点,具有 <strong>数据分布均匀</strong> 、 <strong>方便扩容</strong> 的优势。</p>    <p>总结</p>    <p>陌陌的Feed服务大规模使用Redis作为缓存和存储,Redis的性能非常高,了解它的特性,并且正确使用可以解决很多大规模请求的性能问题。通常内存的故障率远低于硬盘的故障率,生产环境Redis的稳定性是非常高的。通过合理的持久化策略和一主多从的部署结构,可以确保数据丢失的风险降到最低。</p>    <p>另外,陌陌的Feed服务构建在许多内部技术框架和基础组件之上,本文偏重于业务方面,没有深入展开,后续有机会可以再做介绍。</p>    <p>互动问答</p>    <p>问题:MongoDB采用什么集群方式部署的,如果数据量太大,采用什么方式来提高查询性能?</p>    <p>我们通过在mongo客户端按id做hash的方式分片。当时MongoDB版本比较低,复制集(repl-set)还不太成熟,没有在生产环境使用。除了建索引以外,还可以通过把mongo数据文件挂载在内存盘(tmpfs)上提高查询性能,不过有重启丢数据的风险。</p>    <p>问题:用户的关系是怎么存储的呢 还有就是获取好友动态时每条feed的用户信息是动态从Redis或者其他地方读取呢?</p>    <p>陌陌的用户关系使用Redis存储的。获取好友动态是的用户信息是通过feed的owner,再去另外一个用户资料服务(profile服务)读取的,用户资料服务是陌陌请求量最大的服务,QPS超过50W。</p>    <p>问题:具体实现用到Redis解决性能问题,那Redis的可用性是如何保证的?万一某台旦旦机数据怎么保证不丢失的?</p>    <p>Redis通过一主一从或者多从的方式部署,一台机器宕机会切换到备用的实例。另外Redis的数据会定时持久化到rdb文件,如果一主多从都挂了,可以恢复到上一次rdb的数据,会有少量数据丢失。</p>    <p>问题:Redis这么高性能是否有在应用服务器上做本地存储,如果有是如何做Redis集群与本地数据同步的?</p>    <p>没有在本地部署Redis,应用服务器部署的都是无状态的RPC服务。</p>    <p>问题:Redis一个集群大概有多少个点? 主从之间同步用的什么机制? 直接mod问题多吗?</p>    <p>一个Redis集群几个节点到上百个节点都有。大的集群通过分号段再mod的方式hash。Redis 3.0的cluster模式还没在生产环节使用。使用的Redis自带的主从同步机制。</p>    <p>问题:文中提到Redis使用mod方式分片,添加机器时进行数据复制,复制的过程需要停机么,如果不停数据在动态变化,如何处理?</p>    <p>主从同步的方式复制数据不需要停机,扩容的过程中一直保持数据同步,从库和主库数据一致,扩容完成之后从库提升为主库,关闭主从同步。</p>    <p>问题:Redis宕机后的主从切换是通过的哨兵机制吗?在主从切换的时候,是有切换延时的,这段时间的写入主的数据是否会丢失,如果没丢,怎么保证的?</p>    <p>通过内部开发的Sentinel系统,检测Reids是否可用。为了防止误切,切换会有一定延迟,多次检测失败才会切换。如果主库不可用会有数据丢失,重要数据的写入,在业务上有重试机制</p>    <p>来自: https://www.sdk.cn/news/3344</p>    
 本文由用户 e21er2131 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1462432235149.html
Redis Feed 分布式/云计算/大数据