分布式数据库架构详解-超大门户百度案例(学习)

示例系统:存放百度SDK记录运营商游戏的交易信息

1、背景(2012年左右):

当时开始简单的主从结构,随着数据量增大、规模扩大、对高可用要求越来越高(之前从宕机两小时到后来五分钟),需要继续拓展。

当时的数据库拆分、分库分表,数据库服务器达到4百台,只有一个DBA,每天的数据迁移、拓容很痛苦。

当时数据库峰值能达到每秒2.5万笔。当时淘宝双十一每秒峰值30万笔。

2、为什么使用mysql

社区(主要)、免费

3、mysql目前存在问题

1、单机性能

如果是小网站,每天PV几十万、几百万,数据量不超过1个亿,都不会问题。

数据量大、操作量大,就不行。

a、QPS(读/写)

网上有专门对mysql数据库性能测试的文章。

当时百度存储的物理机是48核、96G内存的IBM机器(主流配置)。

硬件在整个架构里面是最廉价的。原则,如果硬件能解决问题,先升级、增加硬件,不行再改系统架构。因为硬件是最快的,最省成本的。

百度有专门的mysql团队做优化,如针对不同的业务线的数据库进行优化,包括参数、内核。

b、响应时间

一般sql查询要求小于50ms。

c、数据规模

单表的规模不能超过2000万,只能分表分库。

原则,能用空间的去换时间的,尽量用空间。

4、IOPS是读操作和写操作的瓶颈

IOPS磁盘读写。

2、主从数据一致性

应用还是选择主从复制。mysql半同步当时未发布正式版本,没人敢去尝试。

a、异步复制

复制原理

binlog内部结构

复制协议

数据延迟判定

b、半同步复制

3、自动化扩容

按照一定规则扩容(1、hash取模拓容、范围、日期等;2、水平、垂直拓容)

数据容量预估,提前预警(1、单表容量预估(业务、现有机器配置、数据字段类型、数据量);2、buffer pool容量、命中率;3、磁盘容量)

全量+增量自动化扩容(1、从库提升为新主库(主从数据一致);2、自动或者手动;3、扩融完毕通知代理曾对前端透明)

4、主库单点

主备策略(备库只做数据同步,不做线上查询)

数据补全(从主库拉取binlog文件进行数据补全)

单点切换(1、主库宕机,切换新主库,尽量保存数据一致性(业务特性);2、通知代理层切换新的主库对应用透明)

主库就一台,数据库峰值2.5万笔每秒,扛不住。

(如何解决这些问题呢,思路引导,集群、分布式

分布式系统跟集群的很大差别:集群系统干的其实都是一件事情,分布式系统有分工的。

分布式系统两种流:控制流、数据流

架构设计原则:

1、空间换时间

2、硬件优先级大于软件

相关推荐