分布式数据库架构详解-超大门户百度案例(学习)
示例系统:存放百度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、硬件优先级大于软件