杨海朝_基于MySQL可扩展架构设计_更新

基于MySQL的可扩展架构设计杨海朝E-mail:[e-mail]个人简介新浪高级DBA整个新浪数据库运维工作…超过700台数据库机器...每天查询量超过50亿…单个项目每天的查询量超过39亿…鱼缸的启示可扩展的重要性1.非功能性需求0级别2.scale-up&scale-out3.后期改造成本高4.价格性能曲线影响性能因素议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&A议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&AMySQLReplication结构1Master--NSlave1.最常用的方案2.web2.0中小型站点选择3.读密集型应用1Master--NSlave2Master--NSlave1.APorAA2.自增问题3.更新丢失4.HA功能2Master--NSlave1Slave--2Master1.Slave可能成为瓶颈2.不支持事务1Slave--2Master1Slave--2MasterNMaster--NSlave1.自增问题2.更新丢失3.故障恢复NMaster--NSlave议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&A垂直拆分（功能拆分）1.明确业务的功能需求2.逐步去拆分3.需要和水平拆分结合垂直拆分（功能拆分）水平拆分--11.选择partitioningkey至关重要2.拆分粒度大小指定3.考虑后期搬移策略水平拆分--1水平拆分--21.选择partitioningkey至关重要2.多一次查询消耗，索引可能成为瓶颈3.弹性的LB水平拆分--2水平拆分--31.选择partitioningkey至关重要2.冷热数据区分不好3.存在进一步扩展问题水平拆分--3议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&AMMM方式1.实现不了多IDC容灾2.监控是OSPF3.不是真正的LB4.默认不支持自劢切换5.浪费IP资源6.非无缝的切换方式MMM方式Heartbeat+DRBD方式1.多IDC容灾问题2.仅仅是主库的HA3.性能还有一定的损失4.切换时间无法达到毫秒级5.资源浪费6.维护复杂(裂脑，DRBD)Heartbeat+DRBD方式ShardeNothing方式1.IDC容灾问题2.网络带宽要求高3.安全问题4.应用设计方面（FK，join,fulltext）5.性能受限于硬件ShardeNothing方式议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&AM(a)/M(p)结构应用实例优点：1.能实现多IDC的高可用性和容灾2.减少网络流量成本3.减少主库的同步压力缺点：1.lag增加2.资源成本增加3.维护成本增加4.监控复杂M(a)/M(p)结构应用实例结合LVS结构应用实例优点：1.能实现多IDC的高可用性和容灾2.好的读负载均衡3.主库能实现比较好的HA缺点：1.资源利用容易不均衡3.维护成本增加4.监控复杂5.LVS可能成为瓶颈结合LVS结构应用实例M(a)/M(a)结构应用实例优点：1.能做到IDC的容灾2.基于BASE思想设计3.减少业务高峰对资源的需求4.不依赖于网络环境缺点：1.要求业务的耦合性满足2.开发需要做一些工作3.监控和维护成本增加M(a)/M(a)结构应用实例议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&A新浪微博平台开发者大会即将举行:可扩展分布式数据存储微博技术架构微博cache设计即时搜索社会化应用与新浪云more…谢谢Q&A