![DTCC2011
数据库监控
时间地点
增加结构体监控；
Monitor
struct req_define {
int8_t notused;
};
struct res_define {
char head[3]; MySQL MySQL
uint32_t value = noteq(68222720);
};](https://image.slidesharecdn.com/random-110420003606-phpapp02/85/-16-320.jpg)
![DTCC2011
自动切换设计要点和目标
一些技术及成果
关注点是效率和数据一致性；
[效率]
常规服务控制服务中断5min ，核心服务控制3min内；
[一致性]
patch半同步类、软件veritas类、数据恢复技术；
[目标]
预警控制在15s内；
完成切换master在10s内，slave在60s内；](https://image.slidesharecdn.com/random-110420003606-phpapp02/85/-25-320.jpg)
王龙：百度数据库架构演变与设计
- 1. DTCC2011
- 2. DTCC2011 百度数据库架构综述 业务概念 业务接口 业务规则 业务规模 百度数据库三阶 分散式 集中式 分布式 百度数据库挑战
- 3. DTCC2011 分散式系统是指运行在同一台服务器上，为单一产品线或业务提供服务 的数据库系统，丌不其他系统有交互。 这类结构简单，易设计、构造、操作，数据处理能力有限和易维护。 Client Client Client a b c
- 4. DTCC2011 集中式系统是指运行在同一台服务器上，为多系统提供业务服 务的数据库系统，丌不其他系统有交互。多为架构调整和性能需 求，主要运行在高性能和高稳定的服务器上。 这类结构简单，丌易操控，数据处理能力强，稳定性高。 Client Client Client a b c
- 5. DTCC2011 分布式数据库系统资源充分共享，包括数据和服务器资源；逡辑单一但 物理多个位置，通过通信链路连接；实现应用透明、数据自治； 尽量保证数据库功能、复杂关联等情况下提升数据规模和扩展。 Client Client Client A_a A_b 仸务A执行在a、b
- 6. DTCC2011 通用数据库接口 具有通用的标准数据库接口; 如:Java数据库互连(简称JDBC)接口等。 与用数据库接口 与用数据库接口根据各个DBMS的丌同而丌同; 如:xsql、dbshell、mysqlpool、myclient等。 重点关注对连接池和QUERY的管理，包括对连接池的创建、维护、管 理、扩展、均衡、包装等。
- 7. DTCC2011 数据查询 —— 根据业务需求提交查询请求后返回结果 数据计算 —— 根据业务需求提交计算命令后返回结果 数据管理 —— 根据一定规则组织关系达到管理目的 数据存储 —— 作为数据存储层提供数据存储服务
- 8. DTCC2011 数据总量500T+，单机数据<2T； 集群节点1000台+，单日新增数据T+； PV总量100亿+，波动范围约10%~30%； 核心请求读写比例约5:1，高比例达到20:1； 数据传输延时均值小于50ms；
- 9. DTCC2011 时间段及特点 时间：2005 ~ 2008 重点：应用，被动满足业务需求 特点：业务单一、单机单业务服务、无交叉关联、简单Replication机制、依赖 硬件 数据的存储、管 理均由单机实现
- 10. DTCC2011 数据库监控 语义监控实现，采用amp形式和ping；易造成盲区和弊端； MySQL Monitor Apache + Php MySQL MySQL 通过php访问判断有无返回； 端口监控； 控制策略？报警堵塞？
- 11. DTCC2011 数据库性能 大SQL问题，资源吃紧，连接数上涨，轻易达到500上限； Client MySQL Client 大SQL 额外的开销、 MySQL 资源的占用 ……….. Client MySQL Client
- 12. DTCC2011 业务架构 Client Client W WR R R Master W W Master/ Slave Slave Slave
- 13. DTCC2011 问题 问 题 监控机制、灾备冗余、数据库准入丌健全 数据库性能弱、功能少、扩展难、安全差
- 14. DTCC2011 解决思路 监控机制 灾备冗余 数据库准入 集 中 式 数 性能弱 据 库 功能少 扩展难 安全差
- 15. DTCC2011 时间段及特点 时间地点 时间： 2008 ~ 2010 重点：管理、存储 特点：集群易扩展，功能多； 数据存储不应用分离； Scale out、Scale up； 数据库结构各异，业务连接和使用方式各异。
- 16. DTCC2011 数据库监控 时间地点 增加结构体监控； Monitor struct req_define { int8_t notused; }; struct res_define { char head[3]; MySQL MySQL uint32_t value = noteq(68222720); };
- 17. DTCC2011 数据库性能 时间地点 数据库高并发和流量激增问题，不可抗拒的正确请求； 处理的基本策略是分流与优化并行处理； 业务优化：业务分流、访问类型、SQL优化 架构优化：数据分割、CACHE分级 硬件优化：提升硬件性能、与用设备 数据库优化：引擎选择、特性利用、逡辑改造
- 18. DTCC2011 数据库扩展 扩展类 扩展项 扩展实现与分类 上线slave 自动授权处理、数据重做、注册信息、引入流量 下线slave Slave节点 mis相关 操作slave 不影响业务直接处理； 影响业务判断直到slave总数低于“monkey_keep _least_slave_num”配置的值为止； slave不可用 有冗余不可用； 无冗余不可用； 迁移slave Ip变更； Ip不变更； Master节点 切换master操作 指定系统内服务器作为master切换、强制某slave不能 用于切换、强制某slave不能用于切换、故障情况下自 动切换、自动切换失败后手动切换 不切换master操作 操作主库但不切换、强制master提供读服务 数据重构 新老数据兼容 重构master、重构slave 新老数据不兼容 标记、下线、处理 数据灾备 数据备份 备份master、备份slave
- 19. DTCC2011 数据库稳定性 时间地点 核心主库由单机升级丏用存储设备，通用服务PC Server； 对稳定性要求高的采用廉价存储设备； Master Master Master Master ………… Master
- 20. DTCC2011 数据库风险不影响考虑 时间地点 异常 影响 处理方式/说明 单机房负载能力不足以承担本 dbproxy进行分流，将部分流量 单机房大量slave失效 机房流量 引向其他机房 多机房大量slave失效 所有机房不能承担机房流量 迅速扩容与流控 中断自动切换过程，按照自动 单点切换程序无法使用，切换 切换失败流程处理，并保证注 注册集群失效 过程中切换中断 册集群在手工切换期间不再提 供服务 导致该机房MySQL集群超负荷， 应用层修改配置，连接多个机 机房流量暴涨 有可能无法正常提供服务 房的收敛层以达到分流的目的 级联情况 暂不考虑 暂不考虑 ………… ………… …………
- 21. DTCC2011 集群结构 Master+slave Transfer Master+master 特点 应用广泛 写跟读存储分开 不存在单点 使用经验多 写性能比mysql好 写压力分散 方案成熟 方案成熟 没有成熟的应用方案 主要问题 写入流量大master易成瓶颈 不支持事务 有应用限制 请求为异步完成 对应用存在较多使用限制 是否存在单点 存在 存在 不存在 单点自动切换系统解决 单点自动切换系统解决 结构是否通用 通用，能兼容transfer 原 来 使 用 master+slave 结 构 的 对应用有限制 程序逻辑需要修改 数据一致性 单点故障时存在有方案恢复 能保证 能保证 数据，其它情况下能保证 数据完整性 半同步patch 高可用transfer 不能保证 重构数据操作方式 较为方便 最方便 较为方便 使用Sql语句 重放di 使用Sql语句 transfer为异步请求方式、不支持事务，对应用存在较多限制； master+master方案不成熟，应用范围有限； master+slave结构能解决当前问题，因此一期选择单层master+slave结构。
- 22. DTCC2011 技术架构
- 23. DTCC2011 业务构架
- 24. DTCC2011 一些技术及成果 数据库落差数据主劢补齐 通过截取主数据库数据回放从数据库数据，实现自动补齐相 差数据 数据库数据偏移快速精确定位 通过binfind技术快速查找pos 数据库数据一致性校验改进 通过实际写入数据校验对比，提升一致性数据校验准确度 数据库单点全自劢切换 通过monkey、au、zk实现单点全自动切换，无须人工参不
- 25. DTCC2011 自动切换设计要点和目标 一些技术及成果 关注点是效率和数据一致性； [效率] 常规服务控制服务中断5min ，核心服务控制3min内； [一致性] patch半同步类、软件veritas类、数据恢复技术； [目标] 预警控制在15s内； 完成切换master在10s内，slave在60s内；
- 26. DTCC2011
- 27. DTCC2011 问题 业务与数据逡辑混乱 DB业务层不数据层耦合度强、关联复杂、逡辑扩展难 运维整合难 DB数据量大、分类繁多、维护代价高
- 28. DTCC2011 解决思路 耦合度强 关联复杂 分 布 式 数 据 库 分类繁多 维护代价
- 29. DTCC2011 时间段及特点 时间：2010 ~ 重点：应用、管理、存储 特点：提供透明应用和策略的数据库服务； 自动扩容、节点自动分裂不合并； 分布式数据库资源、安全管理； 单机事务，最终一致性；
- 30. DTCC2011 问题 分布式事务:多机事务丌支持 分布式调度策略较弱 分布式分布式性能有待提升 最终一致、CAP的问题？
- 31. DTCC2011 数据层结构
- 32. DTCC2011 业务架构
- 33. DTCC2011 对比项 分散式 集中式 分布式 可扩展性 ☆ ☆☆ ☆☆☆ 稳定性 ☆☆ ☆☆☆ ☆☆☆ 可维护性 ☆ ☆☆ ☆☆ 功能支持 ☆ ☆☆ ☆☆☆ 安全性 ☆☆☆ ☆☆ ☆☆ 灵活性 ☆ ☆☆ ☆☆
- 34. DTCC2011 分布式数据库传输——数据传控中心 分布式数据库性能——单机、集群 分布式数据库安全——数据库防火墙 分布式数据库架构——nosql？ 分布式数据库服务——云服务？
- 36. DTCC2011
- 37. DTCC2011