写如何提高代码水平平很差 对了解分布式数据库会有影响吗

原标题:如何实现高容量大并发數据库服务 | 数据库分布式架构设计

袋鼠学院和优云、阿里云联合举办的沙龙结束之后总是有小伙伴们来问PPT内容,想要进一步了解Topic内容(哦,对了对了竟然还有小伙伴专门冲着袋鼠云去听沙龙,感动cry~~)

千呼万唤忙成狗的袋鼠小妹终于把沙龙总结整理了出来(⊙o⊙)

本次沙龍的主题是“云时代下的运维管理实践”,受邀请的演讲嘉宾花名宏翊(经常关注袋鼠云的同学,肯定已经对这个名字很熟悉了)是袋鼠云首席数据库架构师,袋鼠学院数据库讲师

呼应沙龙运维实践的主题,结合自己的专长领域宏翊主要是从数据库领域来谈云时代丅的运维管理该如何做,主题为“如何实现高容量大并发数据库服务之数据库分布式架构设计”。

为什么数据库需要做分布式架构设计在对数据库进行拆分设计和实施时,会遇到哪些坑又该如何避免踩坑?

袋鼠小妹结合宏翊的PPT和现场演讲整理内容如下,希望和大家┅起分享、探讨

数据库拆分要根据业务现状、模式,选择合适的拆分方式紧密结合业务及应用架构设计,谨慎拆分防止过度设计。

为什么要做分布式数据库架构改造

云计算大数据时代,传统的数据库架构已经无法支撑企业高容量的数据增长满足高并发的业务需求。对企业数据库进行分布式架构设计打破了数据库资源不够用的天花板的同时,还能根据企业业务发展状况随时平滑扩容。

分布式数据库架构改造如何做?

数据库分布式改造要遵循“循序渐进”的拆分原则

拆分方式有垂直拆分和水平拆分两种选择拆分方式要根據企业自身业务发展需要。

一般来说是先做垂直拆分,再做水平拆分

在单一数据节点无法满足业务和用户增长需求的情况下,需要做┅个服务化对业务进行垂直梳理,后面的数据节点可以放在不同的资源节点上以提高数据服务的整体性能。

比如一个APP的业务数据在業务初期阶段,是全部放在一个数据库节点中在业务量和数据量快速增长的中期阶段,需要进行垂直梳理根据业务逻辑,拆分成商品、交易、用户并分别放在不同的数据库。

如果其中的一个服务已经拆的很细了但还是有性能瓶颈,无法支撑我们的业务增长数据库這块才需要再做水平拆分。

水平拆分就是将数据(比如图中APP的交易数据)拆成多片放到不同的资源上,用一个集群来支撑更高的业务增長

在拆分时,要谨慎因为拆分会引入复杂性,能不做就不做最优先是做业务和架构上的优化,最终才是做数据库拆分

在拆分的过程中,不要做过度的设计或者直接从初级跳到高级,这样做其实非常浪费资源投入产出比也不好。

水平拆分的难点及解决方案

对企業数据库进行分布式改造需要理解客户的业务逻辑、丰富的拆分经验积累。尤其是水平拆分有系统复杂度高、技术挑战性强、稳定性控制难、具有一定局限性四大难点。

针对这些问题宏翊给我们提供了两种解决方案。

  1. 此方案不会引入额外的组件架构上比较轻量,简單场景使用尚可但稍复杂的场景会放大它的劣势,比如配置管理复杂等

  2. 中间件的使用最大限度地屏蔽了分布式数据库所引入的复杂性,极大降低了研发的门槛最重要的是,有了数据库中间件应用看到的还是单一的数据库。

水平切分原理及设计原则

要对一个表做拆汾选择一个拆分字段,通过一个路由算法确定数据存放在哪个底层库

比如下列数据选择MEMBE_ID作为拆分键,通过路由算法计算后得出’test1234‘相關的数据应该落在库1上DRDS会把所有MEMBE_ID=‘test1234’相关的请求全都路由到库1。其他数据请求亦落到相应的底层库

接下来,当数据已经放下去了应該如何去查询、访问和变更?

首先计算一个hash值当值等于某一个值,它会知道这个数据存储在哪一个库上所以会直接路由到底层这个库,从这个库查询返回结果。

中间件扮演的就是这个路由和计算的角色性能非常强大。拆分后各底层数据库数据量比较小,查询返回仳较快;二是可以支持更高的并发整体并发基本等于两个底层数据库实例并发之和。

来自阿里云的数据库中间件产品:DRDS

数据库中间件產品中有平民软件OneProxy等商业软件;也有MyCat等开源产品,宏翊为大家则介绍了一款广泛使用的成熟商业产品DRDS并讲解了DRDS如何解决对数据库进行拆分时遇到的难点。

是阿里巴巴自主研发致力于解决单机数据库服务瓶颈问题而推出的分布式数据库产品 DRDS 高度兼容 MySQL 协议和语法、支持自動化水平拆分、平滑扩容、弹性扩展、透明读写分离、分布式事务、具备分布式数据库全生命周期的运维管控能力。DRDS前身为淘宝TDDL是近千核心应用首选组件,已稳定服务8年以上

分库分表是DRDS的核心功能,DRDS 在后端将数据量较大的数据表水平拆分到后端的每个 RDS 数据库中这些拆汾到 RDS 中的数据库被称为分库,分库中的表称为分表拆分后,每个分库负责每一份数据的读写操作从而有效的分散了整体访问压力。在系统扩容时只需要水平增加分库的数量,并且迁移相关数据就可以提高 DRDS 系统的总体容量。DRDS 支持库级拆分表级拆分和分库分表拆分,通过 DRDS DDL 语句指定

在主实例的读请求较多、读压力比较大的时候,可以通过 DRDS 读写分离功能对读流量进行分流减轻 RDS 主实例的读压力。

DRDS 的读写汾离功能是对应用透明的设计应用在不修改任何代码的情况下,只需要在 DRDS 控制台中调整读权重即可将读流量按配置的比例在主 RDS 实例与哆个 RDS 只读实例之间进行分流;写流量则全部到主实例,不做分流

设置读写分离后,从主 RDS 实例读取的是强读既实时强一致读,而只读实唎上的数据是从主实例上异步复制的存在毫秒级的延迟,因此从只读 RDS 实例读取的是弱读属于非强一致性读。个别需要实时性、强一致性读的 SQL 可以通过 DRDS Hint 指定到主实例上执行

DRDS 支持分布式全局唯一且有序递增的数字序列。满足业务在使用分布式数据库下对主键或者唯一键以忣特定场景的需求

DRDS 将一些数据量小且更新频度不高的数据表存储为单表模式,这些数据表称为小表通过数据同步将小表复制到与之 JOIN 的汾库上进而提升 JOIN 效率的解决方案称为“小表广播”或者“小表复制”。支持查询引擎识别和下推复杂查询兼容 98% MySQL 语法。

当逻辑库对应的底層存储已经达到物理瓶颈需要进行水平扩展,比如磁盘余量接近30%那么可以通过平滑扩容来改善。平滑扩容是一种水平扩容方式既把汾库平滑迁移到新添加的底层存储上。在实现上是通过增加 RDS 实例的数量来提升总体数据存储容量将分库迁移到新增的 RDS 实例,从而降低单個 RDS 实例的处理压力

分布式改造之后——运维

进行分布式改造之后,如何更省心省力对数据库进行运维

靠人工?成本高、运维人员也難招!

借助袋鼠云开发的数据库自动化管理平台EasyDB企业数据库运维很简单。

manager具有高可用、高性能、易运维等特点。从性能、资源、集群、备份、容灾入手支持多种数据库实例,大规模量的数据库运维提供稳定准确的数据库告警、大盘趋势分析预警、空间跟踪、SQL跟踪、巡检报告等功能。运维管理人员可以轻松应对复杂的日常管理事务及突发性事件数据库管理从此变得有规划,有效率有预见性。

摘要:目前数据库中间件有很多基本这些中间件在下都有了解和使用,各种中间件优缺点及使用场景也都有些心的所以总结一个关于中间件比较的系列,希望可以对夶家有帮助

分布式数据库中间件对比总结(1)

目前数据库中间件有很多,基本这些中间件在下都有了解和使用各种中间件优缺点及使用场景也都有些心的。所以总结一个关于中间件比较的系列希望可以对大家有帮助。

传统的架构模式就是 应用连接数据库直接对数据进行访問这种架构特点就是简单方便。

但是随着目前数据量不断的增大我们就遇到了问题:

  • 单台数据量服务器压力很大

当面临以上问题时我们會想到的第一种解决方式就是 向上扩展(scale up) 简单来说就是不断增加硬件性能。这种方式只能暂时解决问题当业务量不断增长时还是解决不了問题。特别是淘宝facebook,youtube这种业务成线性甚至指数级上升的情况

此时我们不得不依赖于第二种方式: 水平扩展 。 直接增加机器把数据库放到不同服务器上,在应用到数据库之间加一个proxy进行路由这样就可以解决上面的问题了。

2. 中间件与读写分离

很多人都会把中间件认为是讀写分离其实读写分离只是中间件可以提供的一种功能,最主要的功能还是在于他可以 分库分表 下面是一个读写分离的示意图:

上面嘚图可以看出,红线代表写请求绿线代表读请求。这就是一个简单的读写分离下面我们在看看分库分表中间件。

上面这幅图就可以看絀中间件作用比如下面的这个SQL:

按照中间件分库分表算法,此SQL将发送到DB1节点由DB1这个MySQL负责解析和获取id=1的数据,并通过中间件返回给客户端而在读写分离结构中并没有这些分库分表规则, 他只能在众多读节点中load balance随机进行分发它要求各个节点都要存放一份完整的数据。

目湔市面上中间件种类很多种 先看下各种中间件背景:

阿里巴巴B2B开发的关系型分布式系统管理将近3000个MySQL实例。 在阿里经受住了考验后面由于莋者的走开的原因cobar没有人维护 了,阿里也开发了tddl替代cobar

社区爱好者在阿里cobar基础上进行二次开发,解决了cobar当时存 在的一些问题并且加入了許多新的功能在其中。目前MyCAT社区活 跃度很高目前已经有一些公司在使用MyCAT。总体来说支持度比 较高也会一直维护下去,

数据库界大牛湔支付宝数据库团队领导楼总开发,基于mysql官方 的proxy思想利用c进行开发的OneProxy是一款商业收费的中间件, 楼总舍去了一些功能点专注在性能和穩定性上。有朋友测试过说在 高并发下很稳定

这个中间件是Youtube生产在使用的,但是架构很复杂 与以往中间件不同,使用Vitess应用改动比较大偠 使用他提供语言的API接口我们可以借鉴他其中的一些设计思想。

Kingshard是前360Atlas中间件开发团队的陈菲利用业务时间 用go语言开发的目前参与开发嘚人员有3个左右, 目前来看还不是成熟可以使用的产品需要在不断完善。

360团队基于mysql proxy 把lua用C改写原有版本是支持分表, 目前已经放出了分庫分表版本在网上看到一些朋友经常说在高并 发下会经常挂掉,如果大家要使用需要提前做好测试

这两个中间件都算是官方的吧,MaxScale是mariadb (MySQL原作者维护的一个版本)研发的目前版本不支持分库分表。

这两个中间件后面也会跟进测试下看下效果如何。

这里主要是简单介绍了下各种中间件由来和特点后面文章会陆续介绍各个中间件更详细的特性,优缺点性能测试结果

我要回帖

更多关于 代码水平 的文章

 

随机推荐