咖啡店网站首页怎么做,长沙好的网站建设公司排名,邵阳市建设投资经营集团网站,wordpress后台紧致谷歌字体导语#xff1a; 本文根据马进老师在2018年5月10日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。马进 网易 DDB项目负责人来自网易杭研大数据平台组#xff0c;入职以来先后参与了分布式数据库DDB#xff0c;缓存NKV#xff0c;网易数据运河NDC等项目#xf…导语 本文根据马进老师在2018年5月10日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。马进 网易 DDB项目负责人来自网易杭研大数据平台组入职以来先后参与了分布式数据库DDB缓存NKV网易数据运河NDC等项目目前是DDB项目负责人主导数据库中间件的各种项目研发。专注于分布式系统架构与数据库技术热衷于构建高效的高性能的分布式后台应用。摘要分布式数据库DDB是网易研发最早的分布式系统过去十几年来一直为网易各大互联网产品提供稳定透明的分库分表服务四年前我们推出了私有云DDB为开发和运维人员在使用DDB和弹性伸缩上提供了极大便利一年半之前我们从DDB的在线数据迁移模块中分化出来一套平台化的异构数据库数据迁移、同步和订阅服务NDC现今随着网易内外部应用的网络环境更加复杂应用场景日益繁多对DDB的易用性平台化面向机房和多租户的解决方案提出更多需求和挑战这次分享将带大家一起见证DDB在向结构化数据中心进化过程中的思考和架构变迁。正文DDB发展简介DDB一步到位的分布式数据库DDB是一个分库分表数据库管理成千上万个数据节点并且可以支持PB级结构化数据存储。目前公司内部使用的版本基本上都是查询服务器模式查询服务和存储服务相分离可以分开进行水平线性扩展以及可以支持百万级的qps。此外DDB还支持在线数据迁移的功能可以支持每日GB-TB数据增长并且有标准化的访问协议。DDB的在线迁移功能本质上是我们分布式数据库的一个核心需求目前我们分库分表架构还是将它定义为运维人员需要参与的过程。业界中说我们这种方式有上一代数据库的感觉其一是因为它还不够标准化其二是因为数据库缩容还需运维人员的参与。但我个人觉得这属于一个设计哲学的问题我们可以很好的解决这两个问题但归根结底还是要看它的运维和使用成本有多低。左边这张图是我们数据库的成本曲线。单机数据库随着数据规模和访问规模的提升成本曲线成长很不线性。例如我们一旦达到了商务机器成本上线往上扩容成本就很大。如果使用分库分表分布式数据库我们能很好的实现存储和查询功能的线性扩展它的使用方式能达到我们的要求自然就会得到一个理想的线性曲线。DDB发展历程2006年DDB第一个版本上线当时的功能相对比较简单就是一个简单SQL兼容和部分管理功能。概括的说从2006年的V1版本到2010的V3版本都是一套驱动模式我们内部叫做DBI模式。2012年随着私有云上线我们开发了查询服务器可以支持多语言在查询服务器内部提供丰富的SQL统计功能。同时我们在云计算的管理平台上提供云计算DDB Pass服务可以进行一键部署和管理监控。2017年之后我们开始研发DDB 5.0版本逐渐简化架构并且把相关服务做了模块化的拆分以及进一步扩充了SQL的兼容度。DDB功能特性数据信道在数据信道方面第一我们有比较好的均衡方式有两级映射的功能有应用自定义配置的哈希函数。第二我们有比较高的标准化SQL 92能达到90%的兼容度5.0之后达到了95%。并且我们支持全局自增ID、explain计划有数据标准导入导出查询服务器兼容MySQL通信协议。第三我们支持分布式事务。业内很多专家人士可能会吐槽两阶段提交协议不可靠但我认为ACID本质上是一个概率问题两阶段提交协议的ACID功能在概率上远不如单机版的事务但并不代表它的可靠性没有提升。另外我们也会跟应用强调业务场景里涉及到的敏感数据交易。并且我们分布式事务两阶段提交协议的实现对用户是透明的内部会有一些优化措施并不是所有的事务都是两阶段提交。最后强调一点分布式事物两阶段提交协议在性能上还是存在瓶颈在业务中我们也会跟应用具体强调。第四我们提供Hint功能可以在DDB内部实现读写分离然后实现SQL自定义路由。第五我们在查询服务器层面提供丰富的统计功能包括SQL模式统计、SQL频度统计、慢SQL 统计、多维度QPS统计。DDB功能特性管理信道在管理信道方面需要特别说明的是我们兼容MySQL管理语法创建表等操作都跟MySQL在语法上高度一致用户管理上也比较类似。并且我们在线数据迁移功能提供较多的是场景化的在线迁移。前期应用在创建表的时候如果没有选择好分区字段我们可以在管理工具上做分区字段更改的操作底层就会实施数据重分布。另外还有一些扩展功能比如定时任务、悬挂事务报警。在高可用方面我们查询服务器是一个热备的底层的数据库也是比较经典的主从架构内部做了自动fail-over机制。DDB核心优势DDB的核心优势第一有标准化的访问协议有较高的SQL兼容度。第二分布式事务能够保证数据的高一致有较完善的图形化管理工具、在线扩缩容功能。第三所有的组件都是高可用的。DDB V1-V3架构DBI模型DDB架构过去十年的变迁这是V1-V3的经典架构在这套架构里分库分表实现在驱动层。在应用端它们会依赖我们提供的JDBC驱动的jar包来访问DDB。DDB内部的语法解析执行计划都在驱动层做。另外我们有一个Master组件负责整个集群的元数据管理和同步。但这套集群也会带来一些问题。第一从语法解析到执行计划到最后的结果集合并DBI内部的这些实现比较耗费CPU。第二在这种架构里DDB版本很难管理。第三个问题比较严重尤其对于提量大的应用。DBI跟随应用层做水平扩展如果我们发现体量不够就要加应用服务器DBI也会跟着增加访问底层数据库节点的连接数也会随着增加这样就很可能会导致底下数据库被打爆的问题。这套架构也比较经典很多小伙伴应该能看出来这套架构跟阿里TDDL比较相似。但很重要的一点区别是我们的集群管理比较独立每一套集群都有一个单独的Master做管理。这个跟我们公司的背景也有关系例如淘宝当初做中间件是为了淘宝的核心业务服务的它只需服务于一个业务。但网易不一样从一开始网易内部就有很多不同类型的产品比如网易考拉、网易音乐两个截然不同的应用一个是典型的电商场景一个是典型的读多写少场景这就要求把不同的集群隔离开。DDB V4架构QS模式DDB V4是提供查询服务器的这套架构就相当于通过单独部署QueryServer组件把DBI包起来然后对应用提供一个标准的MySQL协议支持。同时在Query Server和应用之间部署LVS\HAPProxykeepplived组合做负载均衡。如图所示应用发起一个请求要通过LVS、QueryServer到最后的数据库这套架构比原来的架构多了两次转发链路或许会有点长但却很好的解决了之前DBI存在的问题。首先Query Server的数量和应用的数量没有绑定关系。其次Query Server由平台的运维人员部署我们能追踪它的版本管理和内部问题定位。除此之外在集群管理上我们还是沿用老一套包括管理工具。DDB V1-V4小结DBI模式部署简单省机器对JAVA应用较为友好问题跟踪和定位成本高占用比较多应用端的CPU资源版本升级周期长新功能推广困难 QS模式多语言支持集成任意连接池和DAO版本便于管理跟踪定位问题成本大大降低慢语句TopSQL等功能便于SQL优化连接收敛连接池熔断等功能提升可用性DDB v5LBDriverDDB V4虽然解决了之前DBI模式的各种问题但还是会有一些潜在问题。首先就是之前提到过的链路长的问题。其次LVS通过连接做负载均衡存在弊端。第一在低峰期活跃连接数比较少的情况下无法保证这些活跃连接数均匀分散到每个Query Server上如果使用云计算部署查询服务器这种不均衡容易导致CPU使用率飙升。另外一点使用LVS做负载均衡在应用端cancel语句或query timeout情况下创建临时连接执行kill query指令的时候可能创建的临时连接落到另外一个QueryServer上这样如果这个节点上没有一样的connection id那相当于cancel或timeout没有实现如果有connection id相当于错误的kill掉了一个连接。因此我们给应用提供了一套全新均衡方案在应用端的连接池和驱动之间开发了一个loadbalance driver组件这个组件包装了JDBC驱动对连接池提供逻辑连接并与各个QueryServer的物理连接实现映射。在连接池使用连接的过程中它会按照SQL请求做负载均衡这样首先解决了LVS不能够按照请求去均衡的问题。其次在连接超时的情况下能够拿到底层的真实物理连接并通过它复制临时连接来执行kill指令。最后我们的lLBDriver不会给应用带来迁移成本因为它本身就是一个JDBC驱动应用使用lLBDriver时 只需要配置里更改下driver名称和URL就可以了。DDB V5去master这是DDB V5的架构。除了通过LBDriver做负载均衡外我们还去掉了Master组件。原因第一是出于省成本考虑。第二Query Server本身是一个我们自己去掌控的服务端所以完全可以用它去做一些管理上的功能QueryServer之间本身互为热备在实施了master的部分功能集成到QueryServer上后在多个QueryServer之间选择一个leader作为管控节点这样同时解决了我们管理功能的高可用问题。DDB V5面向租户的WEB管理工具DDB V5版本还提供了面向租户的WEB管理工具。因为之前实践私有云的Pass服务时最大的感触就是面向租户的管理方式能够很大程度上减少运维人员在运维上的开销和代价。除此之外我们还在这套WEB管理工具里还提供了SQL统计审核报表和大屏服务等。DDB V5NDC服务拆分DDB V5还做了服务拆分。我们把DDB以前的在线数据迁移组件拎出来独立做了一套NDC服务全名Netease Data Canal直译为网易数据运河系统。它除了可以做DDB在线数据迁移之外也可以把MySQL的binlog独立拉出来做一些复杂的ETL这样我们中间件产品栈就会更加丰富。DDB V5面向IDC的解决方案最后我们在DDB V5里面提供了面向IDC的解决方案。DDB V5做的最大的改进就是架构精简化。我们一般怎样评价一个分布式系统是一个好分布式系统呢例如Hadoop它给我们最大的感受就是复杂。但它会提供 Standalone模式通过一台机器和一些简单的指令就可以拉起一个系统这是所谓的重中有轻我们DDB也希望做到这一点。我们最简单的一个QueryServer集成了分库分表和相关管理功能这样我们只需要部署一个QueryServer和数据节点分布式数据库就能建立起来并且具有DDB整套功能集。后面这些管理工具、组件都是选装的即便没有它DDB也可以使用。DDB的WEB管理工具通过DDL向QS管控节点发起管理操作可以把它当做更加丰富的上层功能。值得一提的是这个管理功能可以跨IaaS一套集群里它既可以有物理部署也可以在云端部署。我们提供了可插拔的接口可以在上面做不同的IaaS层适配好处是在不同的物理平台或云平台上我们可以用统一的界面去运维和使用它。DDB V5小结降低各种成本架构精简去master降低学习和部署成本以LBDriver替换LVS提升可用性降低使用成本QS兼容MySQL DDL向标准化更加迈进一步面向租户的平台化方案降低部署和运维成本通过平台化的NDC支持在线数据迁移和同步从软件包到解决方案面向IDC的解决方案通过NDC实现异地同步跨IaaS的支持物理环境和云环境混合部署结构化数据中心——DDB以及NDC规划和瞻望这是我们比较经典的一个多机房数据库和缓存的架构。单机房内部一般会有应用层、缓存层以及数据库层。传统架构一般是应用层在执行数据库操作之后由它们去负责更新缓存。但如果我们把这种模式迁移到多机房场景另一个机房的cache就很难维护。另外它还可能导致数据不一致。一个比较好的方法就是通过binlog方式把每一个机房的binlog拉出来由NDC数据订阅功能去执行缓存的淘汰或更新。这种场景下我们可以把NDC当做DDB的一个跨系统的触发器。这个在业界算是一个较成熟的方案在很多的互联网公司得到了广泛应用。在这套架构里DDB和NDC可以看成一个有机整体如果我们把NDC当成DDB的一个触发器来看它就可以被当做成一个系统来用。以NDC为总栈的架构这是一个更加复杂的架构除了在不同的机房之间做数据同步之外在一个机房内部也可以通过NDC做异构的数据库在线迁移。同时我们可以用NDC做一些同机房内部的数据订阅满足一些下游应用的解耦。这套复杂的架构里还存在很多可以被挖掘的点。例如在不同的系统之间做数据同步首先每一个系统要配合一个管理界面然后需要把每一个系统之间的用户权限打通由运维人员配NDC任务。但这个过程中会有很多管理上的壁垒我们做一个简单的需求总结ODMP潜在需求各个数据系统之间管理方式有壁垒缺乏统一的资源划分认证方式各个系统间权限不通需要人工同步没有统一的监控部署平台传统的工单流程容易造成资源浪费ODMP在线数据管理平台可插拔可扩展易集成面向IDC的数据系统管理平台集成租户管理权限同步资源池管理报警监控自动部署基于NDC实现异构系统和IDC间数据同步核心实现这是我们最终想要达到的效果。其实我们内部已经实现了这些功能但都是彼此独立不相同的。我们希望建立一个统一标准进行统一维护这样就能很大程度降低运维和使用成本。两个问题一路下来我们总结出这两个问题。其一为什么我们在做应用的时候团队越大DEVOPS门槛越高随着我们应用发展、团队成长、规模扩充面临的业务场景越加复杂需要做的技术选型越来越多开发人员从调研到测试、从部署开发到最后运维长期处于这样的循环里。一套成熟的系统进入到一个比较正规的运维流程往往需要一个很长的周期。其二在这个过程中做中间件怎样做可以降低成本第一尽可能自动化减少工单流程。第二尽可能挖掘出平台运维的角色即我们开发人员开发人员本身就是DBVOPS可以直接面向应用开发这样可以省去运维人员的介入。第四注意各个平台和系统之间的串联这一点也是ODMP的本质问题。ODMPhybrid consolehybrid console相当于一个DDB的命令行工具可以选择访问QueryServer的节点。我们可以对这个功能进行这样的一些展望在选择节点之前是否可以选择要访问的系统是否可以在同一界面进行这些操作具体访问了哪个系统是否可以隐藏起来。目前业界很多产品都在朝这个方向发展hybrid这种访问方式或许会成为未来的主流趋势。总结DDB十年架构变迁V1-V3驱动模式满足JAVA应用所需V4代理模式多语言支持增强可用性和运维能力V5平台模式精简掉lvs和master面向租户和IDC的解决方案 ODMP展望脱胎于DDB和NDC对平台化的理念核心价值打通异构在线数据系统的壁垒实现统一的部署监控 租户认证权限打通使大团队中DEVOPS成为可能核心实现基于NDC实现异构系统和IDC间数据总线
