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

本文做者：HelloDeveloper

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

 

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

 

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

 

2005 年 -2008 年：分散式数据库结构 

这一阶段是被动知足业务需求阶段，其特色是业务单1、单机单业务服务、无交叉关联、简单 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 论坛中对第十二期百度技术沙龙作了介绍，上传了本期沙龙的一些照片和你们分享。颇受其余用户热议。你们能够点击进入大型网站数据库架构设计和性能优化查看。

原文连接地址：https://developer.baidu.com/topic/show/290172