《腾讯网数据库平台介绍.ppt》由会员分享，可在线阅读，更多相关《腾讯网数据库平台介绍.ppt（31页珍藏版）》请在三一办公上搜索。
1、,腾讯网数据库托管平台,alanshao（邵宗文）,DTCC2012,项目简介,腾讯网数据库托管平台通过建立南北4个IDC数据中心，数据库实现异地多点分布和跨IDC容灾，用户就近访问IDC数据中心数据，减少专线消耗，缩短响应时间，实现了易扩展;,同时平台集中了项目前期容量规划，授权变更，决策支持和运行状态分析等。另外还有数据库故障自动修复，服务摘除，及自动恢复上线，阀值告警，慢SQL,采样SQL分析等应用功能,实现了高可用性和高性能。现有百台服务器，实现了400多个数据项目的托管，服务稳定性99.999%。,DTCC2012,数据库托管平台目标,目标打造业内一流托管平台，实现高可用，可扩性，高
2、性能，高效性高可用，可扩性：对故障机器，延迟超过阀值的从库进行自动摘除，并通多IDC数据中心实现可扩展性，实现99.999%高可用。高性能：针对各种不同业务项目，提供自动化告警及优化建议，从而应对更大的高并发访问。高效性：采用托管平台，提供了简单的域名访问数据库模式，提高了开发速度。DTCC2012,互动产品,评,论,海量用户+多元服务垂直产品,汽车产品市场竞争激烈，导致新产品及新功能不断,财经产品,体育产品内容类产品,新闻内容,评论论坛,互动组件俱乐部,活动系统,微博,直播,资料库,运营统计分析DTCC2012,腾讯网面临的挑战业务数据之间越来越紧密，相互调用越来,Reader,QQ空间渠道
3、,手机,越频繁。急待于统一的数据库托管平台来支撑。,IM结构化的信息,多媒体内容,分享UGC,互动,编辑内容,搜索,参与,运营平台,资料库,平台,互动平台,内容管理系统DTCC2012,传统数据库使用结构图,用户,应用项目连接一个主库，进行读写操作。从库通过同步主库数据做热备，很少提供服务。MySQLReplication开发人员会产生慢SQL影响服务,存在硬件单点前端应用项目,R/W Master DB无法IDC容灾,Slave DB/Backup高峰时会有性能问题,一个主库带一个从库的双车道式，当有高峰访问时候，就显得拥堵不堪。DTCC2012,Web&Applications,数据库托管
4、平台简要概览,Load BalancerDNS,Queries,Writes,Master A,可应对硬件故障,可应对开发人员慢SQL，保障服务业务监控报表,Master BWrites,R/W Masters单机混跑模式,实现IDC级容灾,遇高峰可扩,实时监控Read-only Replicants,w/Roles,多主库多从库的高架桥模式，从容应付高峰压力，即便某几个道路堵塞，也无碍大局。DTCC2012,数据库托管平台技术要点规范化,由于之前没有对业务数据库使用进行评估，从而导致资源不够及出现上线后数据库频繁出现瓶颈的问题。,再好的道路也怕不遵守规范的汽车，同样，数据库托管平台也需要严格
5、的标准来规范各业务项目。,DTCC2012,数据库托管平台技术要点规范化,通过托管平台提供的规范化的电子流，有效保障了业务的发展。,DTCC2012,数据库托管平台技术要点可扩性,建立多IDC数据中心,建立南北4个IDC中心，防止因某IDC断电，网络故障影响全局服务 用户访问就近IDC数据中心数据，减少专线消耗，缩短响应时间。通过各IDC数据中心分担备份存储压力。通过本地IDC能加速备份，,和数据恢复时间,避免了上百G数据走专线耗时久的问题。,动态调整业务,当出现突发大项目，通过dns可快速扩容，从而保障服务高可用。当出现慢SQL导致从库延迟或网络抖动，监控机通过DNS实现自动,摘除，当从库恢
6、复正常之后，监控机会将对应从库自动上线。,DTCC2012,数据库托管平台技术要点高性能,自选股数据库案例,2012年起财经同事对自选股进行了推广，借助于数据库平台强大,的可扩展性很好的抗住了十倍多的压力。,DTCC2012,数据库托管平台的运行情况数据库平台电子流的运行情况1.新项目申请 450个。2.新授权访问申请 436个。,其他数据,1.数据库平台在目前已经平稳运行800多天左右，全年实现99.999%高可用。2.目前的数据库平台，已提供了近百个端口共上千个实例的混跑服务。4.数据库平台约有上千个数据库，几百万张表。5.目前通过间隔1,2天模式进行各个项目的全量数据库备份，备份存档时间
7、受存储空间的影响只有约10天。DTCC2012,服务规模,隐患库表,宕机时间,高性能,高可用,A,搭建数据库平台之后对比,变化趋势：,关键要素：,维度项目数据库管理可扩展性,新平台特性平台采用上百台新机器，提供上千个实例的混跑服务采用电子流管理项目数据库，有效降低了沟通成本。通过告警形式，及时将隐患库表显现出来从之前的每月2-3次宕机，到现在800多天服务零宕机。从之前主要集中在深圳，到现在扩展为北京，上海，天津，深圳4个IDC数据中心。成功应对世界杯竞猜，球迷中心几千万活跃用户的交互操作。自动对故障机器通过dns模式进行切换。,服务规模：对比之前单个业务申请2-3台DB只能提供服务，现在通过
8、平台混跑模式扩展了10几倍的服务规模。为公司极大的节约了机器成本。项目数据库管理：采用数据库平台之后，可以为业务提供快速高效的服务支持，数据业务需求3分钟即可上线，提升了业务发展。隐患库表：从之前的没有隐患库表检查，到现在定期的库表监控及优化反馈，同时对比之前，已经将暴露出的十几个严重影响性能的库表进行了优化清理。宕机时间：从之前每月2-3次宕机，到现在连续800多天零宕机，实现了数据库平台99.999%的稳定性。高性能：针对技术开发人员偏少的地方站和不少外包等项目，数据库平台很好的弥补了开发实力弱的情况，并且解决之前长期困扰这些项目的数据库瓶颈，赢得了好评。DTCC2012,DBA的时间都用
9、在何处安装 6%创建和配置12%软件维护,6%来源：IOUG 2001 DBA 调查,持续的系统管理55%,加载数据 6%,DTCC2012,B,TCMS,数据库托管平台特点概览,软,硬,多维度监控,业务行情,多IDC分布,故障快速切换,通过全方位监控，将各个业务做成类似股票行情一样。,持续管理,托管平台连续800多天零宕机，服务稳定性提升到99.999%,单机混跑,动态可调,慢SQL定位,SQL采样,15,根据各业务生命周期不同，进行单机多实例混跑，从而有效降低公司服务器成本。兼,平台对于线上托管项目进行慢SQL问题分析和SQL采样，帮助开发人员更快定位问题施DTCC2012,数据库托管平台
10、特点软,多维度监控,业务行情,通过全方位监控，将各个托管业务做成类似股票行情一样。TCMSDTCC201216,数据库托管平台特点硬,多IDC分布,故障快速切换,托管平台连续500天零宕机，服务稳定性提升到99.999%DTCC2012,数据库托管平台特点,单机混跑,动态可调,根据各业务生命周期不同，进行单机多实例混跑，从而有效降低公司服务器成本。兼DTCC201218,数据库托管平台特点TCMS慢SQL定位平台对于线上托管项目进行慢SQL问题分析，帮助开发人员更快定位问题,19,施,DTCC2012,数据库托管平台特点,TCMS,SQL采样,平台对于线上托管项目进行SQL采样分析，帮助开发人
11、员更快定位问题,施,DTCC2012,20,数 据 业 务 常 见 问 题,DTCC2012,业务场景A,对数据吞吐概念含糊，未考虑大返回集合后果，从而导致耗时在网络传输上.是否真有必要一次获取这么多？是否是必须要在早高峰9：30左右操作？同时既然已经有了,book_type=0100,再返回字段时候可否去掉book_type.,DTCC2012,业务场景B,对涉及到分页操作，没有足够的防爬虫意识，一些多表得到结果的操作，本身就很慢了，加分页时候尤其需要谨慎对待。因为会一下子锁2-3个表，导致进程堵塞。,DTCC2012,业务场景C,在遇到大量or操作可以用in来替代降低sql语句网络传输，同
12、,时最好能用临时表join或许更好。,DTCC2012,业务场景D,不同分表策略的项目实践。,DTCC2012,业务场景E,定位问题时候的全局可视化。,DTCC2012,业务场景F,面临的对现有布局和管理的业务挑战。,可以通过去中心化，类似游戏按省分区一样。,DTCC2012,业务场景G,对merge，heap,FEDERATED 引擎等引起的管理挑战。,开发大量使用内存表，存在tar文件备份的隐患。,内存表和临时表使用过量，导致可能的内存不足引发OOM操作和一系列问题,Merge表的滥用，会导致句柄数问题。,update app_use_daopai_2.app_info_summary s
13、et UseNum=UseNum+1,LastUseTime=1330443307 where AppID=801058322;,120210 0:20:55 ERROR Error in accept:Too many open files,120210 0:20:59 ERROR/usr/local/mysql/bin/mysqld:Cant open file:./app_use_daopai_2/app_use_info_18.frm(errno:24),120210 0:20:59 ERROR/usr/local/mysql/bin/mysqld:Cant open file:./app_use_daopai_2/app_use_info_18.frm(errno:24),FEDERATED引擎产生的主，从不同步问题，因为开发只是给主库IP做了向另外一个主库的授权申请,而从库IP存在授权访问问题。,DTCC2012,业务场景H,跨库操作和读写不分离的隐患。,DTCC2012,业务场景I,慢SQL日志和mysql err日志结合的实战分析。,通过分析mysql errlog对应时间，是在做自我修复所引发的慢SQL,DTCC2012,能因敌变化而取胜者，谓之神,-孙子兵法,工作现场有神灵,-稻盛和夫,Thanks,DTCC2012,
