当前位置:主页 > SEO优化 >

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

作者: 奕星SEO 分类: SEO优化 发布时间: 2019-10-19 05:28 内容来源:网络整理阅读量:

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

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

  这一阶段是被动满足业务需求阶段,其特点是业务单一、单机单业务服务、无交叉关联、简单 Replication 机制、依赖硬件,数据的存储和管理均由单机实现。

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

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

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

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

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

  我们会从两个角度考虑,一个是正面保障它不出问题,第二个是出问题后如何去修复。在不出问题的时候,也要从硬件和软件两个角度去看。从硬件来说主要是像底层的存储类似的常用技术。但是也要考虑一个问题,因为无论如何都是要通过通信传输的,那通信如何保障?比如像采用光纤这种情况。从软件角度,主要考虑两种情况,从前端应用去保障和数据库本地保障。

  如果是出问题以后,我们一是按照传统的方式是从日历里去做数据结构解析,或者做前端数据的分解或关联关系映射,另一种情况就是保证数据完整不流失的情况下去解析数据结构。

  刚才有人问我说在推拉结合的前提下怎么去做分页,我认为不用去追求每次分页数量的精确性,把这一点放下去的线 倍以上,其实还有很多这样的需求,比如分发前端并发连接的时候,让保持长连接和短连接的 Web 请求分布在不同的 Web 服务器上,这样,在仅能影响一部分用户的情况下,性能也会提升很多。

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

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

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

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


本文链接地址:http://www.seohuizhou.com/seoyouhua/14492.html
上一篇:<<事关人类生死成败外太空XXOO到底有多难?
下一篇:偷卖155万份简历 招聘网站员工受审>>