百度技术沙龙第15期回顾：设计可靠而实时的社区型网站（含资料下载）
在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支持异步编程，在未来可以作为尝试的编程方式。
有关百度技术沙龙的更多信息，可以通过新浪微博关注@百度技术沙龙，或者加入百度技术沙龙微群，InfoQ上也总结了过往15期所有百度技术沙龙的演讲视频和资料等，感兴趣的读者可以直接浏览阅读。