百度技术沙龙第 1​5 期 设计可靠而实时的社区型网站

在 6 月 25 日百度主办、InfoQ 策划组织实施的第 15 期百度技术沙龙活动上，来自百度贴吧的技术负责人，百度搜索研发部技术委员会成员李瀚以及去哪儿网酒店技术总监杨淼分别分享了构建社区型网站的相关话题，话题涉及百度贴吧的架构实践以及去哪儿网“知道”的设计经验。本文将对他们各自的分享做下简单的回顾，同时提供相关资料的下载。

 

主题一：百度贴吧的架构实践（视频，MP3 和 Slides 等资料下载） 

 

来自百度贴吧的技术负责人李瀚第一个为大家分享，重点围绕存​ 储架构的解决方案来展开，李瀚首先向大家介绍了贴吧产品的概况： 

 

​贴吧主要由讨论区、视频区、相册区、游戏区、itieba、无线贴吧等组成。使用的技术涉及前端、LAMP、NoSQL、数据挖掘、反作弊以及无线等。

 

复杂的应用必然涉及到复杂的技术组合，同时像贴吧这种大规模社区也同样面临着一些技术上的挑战： 

 

​数据量层面，​目前帖子数量大概在百亿的数量级，某些热门主题可达到千万回复。同时视频数据的存储在 PB 级别，每秒来自于浏览器的请求数在 10 万的数量级，系统内部每秒钟的更新请求转发数在十万左右。

 

可用性和数据安全性方面，要保证 7*24 的不间断服务，还要考虑容灾以及冗余等因素。 

 

此外，快速开发以及丰富的应用形式加上迥异的访问方式，也是贴吧面临的主要挑战之一，例如贴吧目前提供的服务类型就有数百种，不同的应用还有着诸如检索、推送这样的不同需求。 

 

紧接着，李瀚揭示了贴吧在存储上架构上是如何应对这些挑战的，主要包含三个部分：

 

轻量型解决方案

大数据存储解决方案 

​服务集群管理方案

轻量型解决方案是为了解决贴吧日常的 80% 的快速开发需求，大数据存储解决方案是希望用来解决大数据量和突发状况，服务集群管理方案是希望通过架构的手段来更有效的管理数百种服务。

 

轻量型解决方案包含 MySQL、Cache 以及 Flash，其中 MySQL 负责数据的持久化，Cache 负责加速，Flash 卡主要解决在硬件层面的 Scale Up 问题。

 

关于 MySQL 方案分享主要包括： 

 

单机优化手段：​

 

​引擎选择（贴吧采用 InnoDB）；

引擎优化（贴吧曾经遇到过相应延迟的问题，后来发现是由于缓存刷新机制导致，后调整为晚上刷盘以及结合 Flash 盘的形式）；

访问模式设计；

​表设计（主要考虑覆盖索引的问题）。

通过以上手段，单机情况下，在数据不超过 1T 时，可以处理几百到几千 QPS 不等。

 

以上就是李瀚分享的关于轻量型的社区存储方案，主要适用于常规需求，例如单机数据量几百 G 量级，流量在亿量级。优点是开发灵活快速，维护成本低。缺点是通用存储，性能受限。在使用轻量型存储解决了 80% 的日常需求之后，总有 20% 的需求是 MySQL 很难解决的。接下来再来这 20% 的需求贴吧的技术专家是如何考虑的：

 

首先介绍了分区的概念：按功能进行垂直分区或按 Key 进行水平分。 分区的目的是为了解决冗余（主要解决机器宕掉的问题）、可扩展性（通过扩展分区来处应对增长的流量）。同时在性能上还可将不同的访问模式（根据吧来访问主题、根据主题来访问回帖）分开，更有利于优化。

 

接下来李瀚讲到了贴吧的帖子存储的实现方式： 

 

​分区通过将主题列表和帖子列表页存储分离、关系存储和内容存储分离以及水平分区等方法实现。

性能方面使用了随机存储和连续存储、内存 Path 以及多种 Cache 相结合的方法。 

单机数据安全性通过 Binlog 来保证。 

​整体数据安全性使用消息队列来实现。

大数据解决方案主要适用于某些数据量特别大或者对性能要求特别苛刻的应用，还有某些需要特殊功能的需求。其优点是采用了专用存储，所以在性能上可以做到极限优化。缺点是开发维护代价较高，灵活性偏弱等。最后是服务集群的管理方案，这里主要包负载均衡和资源定位两个技术。负载均衡目前主要面临的问题有服务故障、蝴蝶效应、数据迁移以及机器差异等。这里李瀚推荐了一篇参考文章，供各位读者阅读。贴吧的资源定位原理主要是调用方通过资源中心来访问服务集群，资源中心中保存着服务的源信息，调用方通过获取到这些源信息（比如 IP 地址）就可以访问后方的集群，后方的服务集群会自动注册到资源中心。

 

主题二：去哪儿网“知道”设计经验谈（视频，MP3 和 Slides 等资料下载）

 

杨淼主要从运营支持和快速开发的角度分享了去哪儿网对于社区产品的设计经验。 

 

首先从去哪儿网的特点讲起，按照产品分可分为博客、知道、点评等产品。按照社区功能划分，可分为问答、点评、徽章以及积分评级等。

 

目前去哪儿网面临的主要挑战有：

 

运营可靠性保障方面（用户产生数据的持久存储以及 99.99% 的可用性指标）

接口要达到 100qps 和更快的响应时间

​打造稳定可扩展的接口协议

通常来讲，通用的 UDC 平台主要包括以下功能： 

 

​内容提交、审核、查询

​提供简单统一的接口

​提供可定制的审核流程

​提供可靠的存储

​高性能查询

​提供事件消息输出

为了保持平台的通用性，其中最重要的一点就是接口设计，其中接口设计主要遵循以下原则： 

 

​前后端服务接口统一（支持 Ajax，兼容 CallBack）

​规范可扩展的数据结构（元数据一致，content 定制，以及属性扩展和索引扩展等）

​批量获取，元数据 / 属性动态组装特性

Cache​读取加速​​​​​

存储和性能部分主要是基于 MySQL 来实现，主要采用了 Master-Slave 结构，Master 担负写入和实时接口查询的工作，Slave 支持非实时业务查询。此外，为了提高性能，还采用了 Memcached+ 内存 Cache 的方式，主系统通过 Query 映射直接指向应用服务器，从内存中获取缓存​小雨 0.1ms，同时，还可扩展应用使用 Memchached 提供缓存。

 

​另外，UDC 平台还包括一个事件引擎，主要应用于 Cache 更新、积分、徽章、排行榜、评分、摘要、情感倾向分析以及内容推送等场景。 

 

然后 UDC 平台还需要有一套完整的监控机制，杨淼称之为敏感的神经系统，包括数据库请求、线程池使用以及 Server Connection 等重要资源的监控，也包括数据变更量、业务请求数、平均响应时间、成功 / 失败次数以及缓存的 hit/miss 次数等业务数据。

 

Open Space（开放式讨论环节）

 

和以往的环节一样，​为了让参会者能够有更多的时间进行相互的交流，本次活动依然设置了 Open ​Space（开放式讨论）环节。除了讲师​李瀚和杨淼外，中搜宁春雷、汪心胜、淘宝数据专家空无也参与了小组讨论。在 Open Space 的总结环节，几位嘉宾​分别对讨论的内容进行了总结：

 

李瀚​​​​​：​针对 PPT​中的多种 NoSQL 方式进行了深入的讨论，​​​​​​​比如消息队列和集群相关的技术等。主要讨论了消息队列相关技术。在大多数情况下，还是要首先选择 MySQL 这种成型的方案，建议在特殊场合时再使用 NoSQL 方案，但也存在花费 80% 时间要去满足 20% 需求的情况，而且这种情况也难以避免。​

 

​杨淼：主要讨论了对于 Cache 的使用和接口设计等问题。​​大家关注最多的还是如何提高系统的稳定性，一致的结论是最有效的保障还是通过监控的手段，细化每一个指标，让参与开发的所有人观察自己涉及到的每一个指标，通过对每一个指标的观察，时刻了解到各个指标的运行情况，包括以后的改进，最重要的还是发挥人的主观能动性。

 

宁春雷​​​​​​​​​​​：主要​讨论了 Scala 相关的话题，涉及应用的场景，优化映射，如何使缓存失效，利用现有的框架如何对数据库建立索引等。另外还介绍了一个即将开源的项目，主要解决基于模块开发的问题。

 

汪心胜：主要讨论了如何使用 Comet 来帮助浏览器能够开发更多的功能去模拟服务，Comet 就是从后台向前台推送数据的一种模式。此外还讨论了 Erlang，基于函数式编程，通过示例分享了函数式编程的体验。

 

空无：主要分享了在 Node.js 上面的一些技术，适合开发这种高并发的数据中间层以及高性能的 Web 服务。这主要是由 Node.js 的三个特性决定的：非阻塞、单线程和事件驱动。通过它可以使开发人员很轻松的开发出高性能的应用服务。Node.js 支持异步编程，在未来可以作为尝试的编程方式。