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

示例系统：存放百度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、硬件优先级大于软件