百度技术沙龙第 12 期内容回顾：大型网站数据库架构设计和性能优化

在刚刚结束的第 12 期百度技术沙龙，我们邀请到了百度运维部高级 DBA 经理王龙和飞信互联网产品首席架构师孙朝晖，分别向大家分享了百度数据库架构演变与设计，以及 Mysql HandleSocket 在动态数据存储中的应用的技术话题。本文对这次百度技术沙龙内容做简单的回顾与总结。

百度数据库架构演变与设计（点击进入相关音视频、文字资料下载页面）

在演讲中，百度运维部的高级 DBA 经理王龙和大家分享了百度在数据库架构设计上的演变过程。百度的数据库架构体系总共分为三个阶段：

2005 年 -2008 年：分散式数据库结构 这一阶段是被动满足业务需求阶段，其特点是业务单一、单机单业务服务、无交叉关联、简单 Replication 机制、依赖硬件，数据的存储和管理均由单机实现。

2008 年 -2010 年：集中式数据库结构

这一阶段主要重点是放在了数据库管理和存储上。特点是集群易扩展，功能多；数据存储与应用分离；数据库结构各异，业务连接和使用方式各异。

2010 年至今：分布式数据库结构

其特点是不仅关注存储和管理，并且把应用也注重起来，提供透明应用和策略的数据库服务； 自动扩容、节点自动分裂与合并。

王龙的分享分为三个部分：

● 百度数据库架构综述：业务概念、业务接口、业务规则 ● 百度数据库三阶：分散式、集中式、分布式

● 百度数据库挑战

演讲的开始王龙简单介绍了三种不同数据库的概念：

分散式系统是指运行在同一台服务器上，为单一产品线或业务提供服务的数据库系统，不与其他系统有交互。 集中式系统是指运行在同一台服务器上，为多系统提供业务服务的数据库系统，不与其他系统有交互。多为架构调整和性能需求，主要运行在高性能和高稳定的服务器上。

分布式系统使数据库资源充分共享，包括数据和服务器资源，这种将部件或功能分布到不同计算机系统和不同位置的方法一般称为分布式计算。

本次分享重点介绍了百度在不同的发展阶段，采取不同的数据库架构方式和设计思路。最后王龙提到了简单介绍了目前在数据库架构、性能、传输、安全以及服务方面的挑战。

MySQL HandleSocket 技术在 SNS Feed 存储中的应用（点击进入音视频、文字资料下载页面）

孙朝晖主要为大家分享了他们在 SNS Feed 存储中使用 Mysql HandleSocket 技术的实践经验。

MySQL HandleSocket 技术大家可能很少了解，实践应用据我所知也没见有人用过，我们其实主要用它来处理 NoSQL 技术。其实我今天的主要话题也是 NoSQL 技术，只是我没有用大家熟悉的 HBase 等去实现，而用 MySQL 实现的。

分享内容主要是以下几个部分：

● SNS Feed 应用的主要挑战 ● NoSQL 在 Feed 存储中的应用状况

● MySQL HandleSocket 的技术架构

● MySQL HandleSocket 协议

● MySQL HandleSocket 在飞信开放平台中的应用

在演讲中，孙朝晖提到，SNS Feed 面对的主要问题就是数据量大，更新快。并介绍了 SNS Feed 面临的挑战：

● 数据写入操作密集，高频度，小数据量 ● 读操作访问压力大，读写比高

● 高活跃用户带来的数据快速失效问题（在微博类应用尤其突出）

● 用户体验要求快速被前端感知

● 数据分区存储成为必然选项

● 数据具有时效性，LRU 数据清洗成为必然工作

然后详细介绍了 SNS Feed 的数据架构和技术优势，并把 MySQL HandleSocket 和 MongoDB 做了比较。

OpenSpace

同样在沙龙最后一个环节，我们分成了六个话题小组，小组话题发起分别由我们的两位讲师、我们邀请的嘉宾，新浪 DBA 杨海朝和现场提出话题的三位参会者担任，并在讨论之后跟大家做了分享：

● 沙龙讲师王龙：数据库一致性的保障

我们会从两个角度考虑，一个是正面保障它不出问题，第二个是出问题后如何去修复。在不出问题的时候，也要从硬件和软件两个角度去看。从硬件来说主要是像底层的存储类似的常用技术。但是也要考虑一个问题，因为无论如何都是要通过通信传输的，那通信如何保障？比如像采用光纤这种情况。从软件角度，主要考虑两种情况，从前端应用去保障和数据库本地保障。 如果是出问题以后，我们一是按照传统的方式是从日历里去做数据结构解析，或者做前端数据的分解或关联关系映射，另一种情况就是保证数据完整不流失的情况下去解析数据结构。

● 沙龙讲师孙朝晖：NoSQL 在 Feed 中应用争论点

主要是围绕在 SNS 弱一致性前提下如何提高数据库的性能，其实在放弃一些对用户体验影响非常小的点，虽然看似不合理，其实会在不影响用户体验的情况下把性能提升很多。 刚才有人问我说在推拉结合的前提下怎么去做分页，我认为不用去追求每次分页数量的精确性，把这一点放下去的话，性能起码能够提升 10 倍以上，其实还有很多这样的需求，比如分发前端并发连接的时候，让保持长连接和短连接的 Web 请求分布在不同的 Web 服务器上，这样，在仅能影响一部分用户的情况下，性能也会提升很多。

总之我们的话题总结出来，就是说 SNS 的应用，尤其 SNS Feed 的应用，不必要求像电子商务数据那样百分之百精确，有很多小的点，舍弃一点点用户体验，一点用户察觉不到的体验，能让系统成本降低很多，这里有很多可挖掘的空间。

● 沙龙嘉宾杨海朝：高并发 MySQL 的架构设计

主要是和大家分享了一下高并发架构设计的话题，讨论在实时性要求很高的场合中，MySQL 遇到高并发写入时如何通过架构去解决它的 slave 延时的问题。 传统的方式是通过对写进行分片，分散到多台物理机上，多台机器承担写操作。但这种方式对多个表之间有强 ACID 的场合不太适合，前期通过提高主库的硬件性能，master 不能进行拆分，slave 采用链条策略把不同的表拆分到不同组的机器上，这样每组集群中同步的数据量变小，在一定的时间内缓解了延时问题。但随着量的增加，需要采用 NOCAP 原则把数据写入内存，两份内存互相同步，内存中的数据再异步到持久化存储中，保证达到一个非常高的并发，同时不损失一致性和扩展性的问题。

● 参会者张成斌：消息队列的应用

我们讨论是一个消息队列解决方案的话题：假设客户端性能非常高，如何实现客户的请求通过服务器端调度，在客户端处理，然后呈现在 Web 界面上，对此我们讨论出了一个模型： 比如说我们的页面有加减乘除的处理，然后可能有 a、b、c、d……很多客户，他们把请求传到服务器端，服务器端会把消息包发送到各地的客户端处理后再返给服务器，传给页面。我们小组主要讨论了前面列出的客户相关的实时性、异常处理、路径、程序以及消息的保护等问题，并提出了几个方案，对于实时性，我们需要维护客户端心跳数据来优化调度，对于异常我们不做处理，客户得不到他要的数据可以多次刷新几次；最优路径还是通过这个心跳数据和客户端 CPU 资源评估得出综合分数，对于消息的保护我们会通过非对称密钥去保护我们对称密钥的交换，利用对称密钥保护消息的通讯。

● 参会者王炳山：云计算在脱机业务中的应用

我的话题是一个云计算的话题，可能在今天关注的人不多，虽然没有完全解决掉自己的问题，但是还是从讨论中得到一些收获，以后期望有机会能继续和大家分享这个话题。

● 最后一个小组讨论的话题是：SNS Game 千万量级用户 DB 架构设计

我主要是介绍了我们公司的一个情况：在用户量增长的情况下要经常不断的停机，这样做的成本比较高，相对来说也不太安全。目前业内做的比较好的也能做到平滑升级的，刚才有个朋友说数据库加个中间层可能会解决这个问题，我们公司现在在尝试 NoSQL 的方式。

参会者博客

和往常一样，也有参会者在会后写博客谈到了自己在本期百度技术沙龙中的收获。如有热心参会者 CSDN 论坛中对第十二期百度技术沙龙做了介绍，上传了本期沙龙的一些照片和大家分享。颇受其他用户热议。大家可以点击进入大型网站数据库架构设计和性能优化查看。