基于MySQL的可扩展架构设计

《基于MySQL的可扩展架构设计》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、www.eimhe.com基于MySQL的可扩展架构设计杨海朝E-mail:jackbillow@gmail.comwww.eimhe.com个人简介新浪高级DBA整个新浪数据库运维工作…超过700台数据库机器...每天查询量超过50亿…单个项目每天的查询量超过39亿…www.eimhe.com鱼缸的启示www.eimhe.com可扩展的重要性1.非功能性需求0级别2.scale-up&scale-out3.后期改造成本高4.价格性能曲线www.eimhe.com影响性能因素www.eimhe.com议题1.复制结构2.基于Sharding策略的结

2、构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&Awww.eimhe.com议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&Awww.eimhe.comMySQLReplication结构1Master--NSlave1Master--NSlave1.最常用的方案2.web2.0中小型站点选择3.读密集型应用2Master--NSlave2Master--NSlave1.APorAA2.自增问题3.更新丢失4.HA功能

3、1Slave--2Master1Slave--2Master1.Slave可能成为瓶颈2.不支持事务NMaster--NSlaveNMaster--NSlave1.自增问题2.更新丢失3.故障恢复议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&A垂直拆分（功能拆分）垂直拆分（功能拆分）1.明确业务的功能需求2.逐步去拆分3.需要和水平拆分结合水平拆分--1水平拆分--11.选择partitioningkey至关重要2.拆分粒度大小指定3.考虑后期搬移策略水平拆

4、分--2水平拆分--21.选择partitioningkey至关重要2.多一次查询消耗，索引可能成为瓶颈3.弹性的LB水平拆分--3水平拆分--31.选择partitioningkey至关重要2.冷热数据区分不好3.存在进一步扩展问题议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&AMMM方式MMM方式1.实现不了多IDC容灾2.监控是OSPF3.不是真正的LB4.默认不支持自劢切换5.浪费IP资源6.非无缝的切换方式Heartbeat+DRBD方式Heart

5、beat+DRBD方式1.多IDC容灾问题2.仅仅是主库的HA3.性能还有一定的损失4.切换时间无法达到毫秒级5.资源浪费6.维护复杂(裂脑，DRBD)ShardeNothing方式ShardeNothing方式1.IDC容灾问题2.网络带宽要求高3.安全问题4.应用设计方面（FK，join,fulltext）5.性能受限于硬件议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&AM(a)/M(p)结构应用实例M(a)/M(p)结构应用实例优点：1.能实现多IDC

6、的高可用性和容灾2.减少网络流量成本3.减少主库的同步压力缺点：1.lag增加2.资源成本增加3.维护成本增加4.监控复杂结合LVS结构应用实例结合LVS结构应用实例优点：1.能实现多IDC的高可用性和容灾2.好的读负载均衡3.主库能实现比较好的HA缺点：1.资源利用容易不均衡3.维护成本增加4.监控复杂5.LVS可能成为瓶颈M(a)/M(a)结构应用实例M(a)/M(a)结构应用实例优点：1.能做到IDC的容灾2.基于BASE思想设计3.减少业务高峰对资源的需求4.不依赖于网络环境缺点：1.要求业务的耦合性满足2.开发需要做一些工作3.监控和维护

7、成本增加议题1.复制结构2.基于Sharding策略的结构设计3.基于HA的scale-out设计4.跨IDC的scale-out设计实例5.Q&A新浪微博平台开发者大会即将举行:可扩展分布式数据存储微博技术架构微博cache设计即时搜索社会化应用与新浪云more…谢谢Q&A