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