精华内容
下载资源
问答
  • 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在...

    1、什么是分布式事务

    分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

    2、分布式事务的产生的原因

    2.1、数据库分库分表

    当数据库单表一年产生的数据超过1000W,那么就要考虑分库分表,具体分库分表的原理在此不做解释,以后有空详细说,简单的说就是原来的一个数据库变成了多个数据库。这时候,如果一个操作既访问01库,又访问02库,而且要保证数据的一致性,那么就要用到分布式事务。


    2.2、应用SOA化

    所谓的SOA化,就是业务的服务化。比如原来单机支撑了整个电商网站,现在对整个网站进行拆解,分离出了订单中心、用户中心、库存中心。对于订单中心,有专门的数据库存储订单信息,用户中心也有专门的数据库存储用户信息,库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作,那么就会涉及到订单数据库和库存数据库,为了保证数据一致性,就需要用到分布式事务。


    以上两种情况表象不同,但是本质相同,都是因为要操作的数据库变多了!

    3、事务的ACID特性

    3.1、原子性(A)

    所谓的原子性就是说,在整个事务中的所有操作,要么全部完成,要么全部不做,没有中间状态。对于事务在执行中发生错误,所有的操作都会被回滚,整个事务就像从没被执行过一样。

    3.2、一致性(C)

    事务的执行必须保证系统的一致性,就拿转账为例,A有500元,B有300元,如果在一个事务里A成功转给B50元,那么不管并发多少,不管发生什么,只要事务执行成功了,那么最后A账户一定是450元,B账户一定是350元。

    3.3、隔离性(I)

    所谓的隔离性就是说,事务与事务之间不会互相影响,一个事务的中间状态不会被其他事务感知。

    3.4、持久性(D)

    所谓的持久性,就是说一单事务完成了,那么事务对数据所做的变更就完全保存在了数据库中,即使发生停电,系统宕机也是如此。

    4、分布式事务的应用场景

    4.1、支付

    最经典的场景就是支付了,一笔支付,是对买家账户进行扣款,同时对卖家账户进行加钱,这些操作必须在一个事务里执行,要么全部成功,要么全部失败。而对于买家账户属于买家中心,对应的是买家数据库,而卖家账户属于卖家中心,对应的是卖家数据库,对不同数据库的操作必然需要引入分布式事务。

    4.2、在线下单

    买家在电商平台下单,往往会涉及到两个动作,一个是扣库存,第二个是更新订单状态,库存和订单一般属于不同的数据库,需要使用分布式事务保证数据一致性。

    5、常见的分布式事务解决方案

    5.1、基于XA协议的两阶段提交

    XA是一个分布式事务协议,由Tuxedo提出。XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、DB2这些商业数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下:


    总的来说,XA协议比较简单,而且一旦商业数据库实现了XA协议,使用分布式事务的成本也比较低。但是,XA也有致命的缺点,那就是性能不理想,特别是在交易下单链路,往往并发量很高,XA无法满足高并发场景。XA目前在商业数据库支持的比较理想,在mysql数据库中支持的不太理想,mysql的XA实现,没有记录prepare阶段日志,主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA,这让XA的应用场景变得非常狭隘。

    5.2、消息事务+最终一致性

    所谓的消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个分布式事务里,保证要么本地操作成功成功并且对外发消息成功,要么两者都失败,开源的RocketMQ就支持这一特性,具体原理如下:


    1、A系统向消息中间件发送一条预备消息
    2、消息中间件保存预备消息并返回成功
    3、A执行本地事务
    4、A发送提交消息给消息中间件

    通过以上4步完成了一个消息事务。对于以上的4个步骤,每个步骤都可能产生错误,下面一一分析:

    • 步骤一出错,则整个事务失败,不会执行A的本地操作
    • 步骤二出错,则整个事务失败,不会执行A的本地操作
    • 步骤三出错,这时候需要回滚预备消息,怎么回滚?答案是A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口,检查A事务执行是否执行成功,如果失败则回滚预备消息
    • 步骤四出错,这时候A的本地事务是成功的,那么消息中间件要回滚A吗?答案是不需要,其实通过回调接口,消息中间件能够检查到A执行成功了,这时候其实不需要A发提交消息了,消息中间件可以自己对消息进行提交,从而完成整个消息事务

    基于消息中间件的两阶段提交往往用在高并发场景下,将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作,其中B系统的操作由消息驱动,只要消息事务成功,那么A操作一定成功,消息也一定发出来了,这时候B会收到消息去执行本地操作,如果本地操作失败,消息会重投,直到B操作成功,这样就变相地实现了A与B的分布式事务。原理如下:


    虽然上面的方案能够完成A和B的操作,但是A和B并不是严格一致的,而是最终一致的,我们在这里牺牲了一致性,换来了性能的大幅度提升。当然,这种玩法也是有风险的,如果B一直执行不成功,那么一致性会被破坏,具体要不要玩,还是得看业务能够承担多少风险。

    5.3、TCC编程模式

    所谓的TCC编程模式,也是两阶段提交的一个变种。TCC提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。以在线下单为例,Try阶段会去扣库存,Confirm阶段则是去更新订单状态,如果更新订单失败,则进入Cancel阶段,会去恢复库存。总之,TCC就是通过代码人为实现了两阶段提交,不同的业务场景所写的代码都不一样,复杂度也不一样,因此,这种模式并不能很好地被复用。

    6、总结

    分布式事务,本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为:不控制、部分控制和完全控制。不控制就是不引入分布式事务,部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC模式,而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景。作为技术人员,一定不能忘了技术是为业务服务的,不要为了技术而技术,针对不同业务进行技术选型也是一种很重要的能力

    展开全文
  • 遵守Mysql原生协议,跨语言,跨平台,跨数据库的通用中间件代理。 基于心跳的自动故障切换,支持读写分离,支持MySQL主从,以及galera cluster集群。 支持Galera for MySQL集群,Percona Cluster或者MariaDB ...

    Mycat关键特性

    关键特性

    • 支持SQL92标准
    • 遵守Mysql原生协议,跨语言,跨平台,跨数据库的通用中间件代理。
    • 基于心跳的自动故障切换,支持读写分离,支持MySQL主从,以及galera cluster集群。
    • 支持Galera for MySQL集群,Percona Cluster或者MariaDB cluster
    • 基于Nio实现,有效管理线程,高并发问题。
    • 支持数据的多片自动路由与聚合,支持sum,count,max等常用的聚合函数,支持跨库分页。
    • 支持单库内部任意join,支持跨库2表join,甚至基于caltlet的多表join。
    • 支持通过全局表,ER关系的分片策略,实现了高效的多表join查询。
    • 支持多租户方案。
    • 支持分布式事务(弱xa)。
    • 支持全局序列号,解决分布式下的主键生成问题。
    • 分片规则丰富,插件化开发,易于扩展。
    • 强大的web,命令行监控。
    • 支持前端作为mysq通用代理,后端JDBC方式支持Oracle、DB2、SQL Server 、 mongodb 、巨杉。
    • 支持密码加密
    • 支持服务降级
    • 支持IP白名单
    • 支持SQL黑名单、sql注入攻击拦截
    • 支持分表(1.6)
    • 集群基于ZooKeeper管理,在线升级,扩容,智能优化,大数据处理(2.0开发版)。

    什么是MYCAT

    • 一个彻底开源的,面向企业应用开发的大数据库集群
    • 支持事务、ACID、可以替代MySQL的加强版数据库
    • 一个可以视为MySQL集群的企业级数据库,用来替代昂贵的Oracle集群
    • 一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
    • 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
    • 一个新颖的数据库中间件产品

     

     

     

    http://www.mycat.org.cn/ 小米网目前在用它进行分库分表

     

    转载于:https://www.cnblogs.com/lnas01/p/5916948.html

    展开全文
  •  分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务节点上,分布式事务需要...

    https://blog.csdn.net/wanghang88/article/details/79762761

     

    1:分布式事物的理解: 

     

         分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务节点上,分布式事务需要保证这些小操作要么全部成功,要么全部失败;本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

     

    2:分布式事物产生的原因:

    a)数据库分库分表;

       当数据库单表一年产生的数据超过1000W,那么就要考虑分库分表,简单的说就是原来的一个数据库变成了多个数据库,这时候,如果一个操作既访问01库,又访问02库,而且要保证数据的一致性,那么就要用到分布式事务。

    b)应用SOA化;

     

    就是业务的服务化。比如原来单机支撑了整个电商网站,现在对整个网站进行拆解,分离出了订单中心、用户中心、库存中心等,对于订单中心,有专门的数据库存储订单信息,用户中心也有专门的数据库存储用户信息,库存中心也会有专门的数据库存储库存信息,如果要同时对订单和库存进行操作,那么就会涉及到订单数据库和库存数据库,为了保证数据一致性,就需要用到分布式事务。

    3)分布式的使用场景:

     

    支付:一笔支付,是对买家账户进行扣款,同时对卖家账户进行加钱,这些操作必须在一个事务里执行,要么全部成功,要么全部失败,并且卖家账户对应卖家数据库,买家对应买家的数据库,对不同数据库的操作必然需要引入分布式事务。

     

    在线下单:在电商平台下单,往往会涉及到两个动作,一个是扣库存,第二个是更新订单状态,库存和订单一般属于不同的数据库,需要使用分布式事务保证数据一致性。

     

    4)常见的分布式事物解决方案:

     

    a)基于XA协议的两阶段提交,

     

        XA是一个分布式事务协议,XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

     

     

     XA协议比较简单,而且一旦商业数据库实现了XA协议,使用分布式事务的成本也,XA也有致命的缺点,那就是性能不理想,往往并发量很高,XA无法满足高并发场景。

     

    b)消息事务+最终一致性

     

    所谓的消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个分布式事务里,保证要么本地操作成功成功并且对外发消息成功,要么两者都失败,开源的RocketMQ就支持这一特性。

     

    具体原理:

     

     

     

    其执行的顺序:

     

    b.1)A系统向消息中间件发送一条预备消息;

     

    b.2)消息中间件保存预备消息并返回成功;

     

    b.3)消息中间件保存预备消息并返回成功;

     

    b.4)A发送提交消息给消息中间件;

     

    对于这个顺序执行的分析:

     

       步骤一出错,则整个事务失败,不会执行A的本地操作;

     

       步骤二出错,则整个事务失败,不会执行A的本地操作;

     

       步骤三出错,这时候需要回滚预备消息,回滚方法,:A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口,检查A事务执行是否执行成功,如果失败则回滚预备消息。

     

     步骤四出错,这时候A的本地事务是成功的,回滚本地A操作的成功,不需要回滚:其实通过回调接口,消息中间件能够检查到A执行成功了,这时候其实不需要A发提交消息了,消息中间件可以自己对消息进行提交,从而完成整个消息事务。

     

    c)高并发场景下基于消息中间件的两阶段提交的分布式事物:

     

     比如:将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作

     B系统的操作由消息驱动,只要消息事务成功,那么A操作一定成功,消息也一定发出来了,这时候B会收到消息去执行本地操作。如果B本地操作失败,消息会重投,直到B操作成功。这样就变相地实现了A与B的分布式事务。

     

    虽然上面的方案能够完成A和B的操作,但是A和B并不是严格一致的,而是最终一致的,当然,这种玩法也是有风险的,如果B一直执行不成功,那么一致性会被破坏,具体要不要玩,还是得看业务能够承担多少风险。

     

    d)TCC编程模式,

     

    TCC编程模式,也是两阶段提交的一个变种。

     

    TCC提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。

     

      以在线下单为例:Try阶段会去扣库存,Confirm阶段则是去更新订单状态,如果更新订单失败,则进入Cancel阶段,会去恢复库存,TCC就是通过代码人为实现了两阶段提交,不同的业务场景所写的代码都不一样,复杂度也不一样,因此,这种模式并不能很好地被复用。

     

    4)总结:

     

    分布式事务,本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为:不控制、部分控制和完全控制。不控制就是不引入分布式事务;部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC模式;完全控制就是完全实现两阶段提交。

     

    分布式和集群

        分布式是指仔多台不同的服务器中部署不同的服务模块,通过远程调用协同工作对外提供服务。(分布式部署:将一件大的事情拆分成多个小事情,分别交给不同的人来做。每个子系统负责自己的事情,然后通过网络进行通信和协调,)

        集群是指在多台不同的服务器中部署相同应用活服务模块,构成一个集群,通过负载均衡设备对外提供服务

     

    分布式理论    

    分为   CAP定理 and  BASE理论

     

     CAP定理

    他指出WEB服务无法同时满足一下3个属性:

    • 一致性(Consistency) : 客户端知道一系列的操作都会同时发生(生效)
    • 可用性(Availability) : 每个操作都必须以可预期的响应结束
    • 分区容错性(Partition tolerance) : 即使出现单个组件无法可用,操作依然可以完成

    具体地讲在分布式系统中,在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性。显然,任何横向扩展策略都要依赖于数据分区。因此,设计人员必须在一致性与可用性之间做出选择。

    这个定理在迄今为止的分布式系统中都是适用的

    数据库的2PC(两阶段提交) 又叫做 XA Transactions。

    ,XA 是一个两阶段提交协议,该协议分为以 下两个阶段:

    • 第一阶段:事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交.
    • 第二阶段:事务协调器要求每个数据库提交数据。

    其中,如果有任何一个数据库否决此次提交,那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。

    如果CAP 定理是对的,那么它一定会影响到可用性。

     

    BASE理论

    • Basically Available(基本可用)
    • Soft state(软状态)
    • Eventually consistent(最终一致性)

    BASE理论是对CAP中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

     

     

    通过两种手段来扩展我们的数据服务

    1)数据分区:就是把数据分块放在不同的服务器上(如:uid % 16,一致性哈希等)。

        2)数据镜像:让所有的服务器都有相同的数据,提供相当的服务。

    ,数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储  但是,加入更多的机器,会让我们的数据服务变得很复杂,尤其是跨服务器的事务处理,也就是跨服务器的数据一致性

     

    简单说来:

    1)要想让数据有高可用性,就得写多份数据。

    2)写多份的问题会导致数据一致性的问题。

    3)数据一致性的问题又会引发性能问题

     

     

     

     

    数据库分库分表( 单表数据量达到1000W)

    目的就在于减少数据库的负担,缩短查询时间。

    数据库分布式核心内容无非就是数据切分(Sharding),以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中,使得单一数据库中的数据量变小,通过扩充主机的数量缓解单一数据库的性能问题,从而达到提升数据库操作性能的目的。

     

    为两种切分模式 :

    一种是按照不同的表(或者Schema)来切分到不同的数据库(主机)之上,这种切可以称之为数据的垂直(纵向)切分;

    另外一种则是根据表中的数据的逻辑关系,将同一个表中的数据按照某种条件拆分到多台数据库(主机)上面,这种切分称之为数据的水平(横向)切分。

     

    垂直切分

    即业务切分

    垂直分库就是根据业务耦合性,将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似,按业务分类进行独立划分。与"微服务治理"的做法相似,每个微服务使用单独的一个数据库。

    垂直分表是基于数据库中的"列"进行,某个表字段较多,可以新建一张扩展表,将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下(例如一个大表有100多个字段),通过"大表拆小表",更便于开发与维护,也能避免跨页问题,MySQL底层是通过数据页存储的,一条记录占用空间过大会导致跨页,造成额外的性能开销。另外数据库以行为单位将数据加载到内存中,这样表中字段长度较短且访问频率较高,内存能加载更多的数据,命中率更高,减少了磁盘IO,从而提升了数据库性能。

    下面来分析下垂直切分的优缺点:

    优点:

     拆分后业务清晰,拆分规则明确。

     系统之间整合或扩展容易。

     数据维护简单。

    缺点:

     部分业务表无法 join,只能通过接口方式解决,提高了系统复杂度。

     受每种业务不同的限制存在单库性能瓶颈,不易数据扩展跟性能提高。

     事务处理复杂。

    由于垂直切分是按照业务的分类将表分散到不同的库,所以有些业务表会过于庞大,存在单库读写与存储瓶

    颈,所以就需要水平拆分来做解决。

     

      水平拆分

      水平拆分不是将表做分类,而是按照某个字段的某种规则来分散到多个库之中,每个表中 

    包含一部分数据。简单来说,我们可以将数据的水平切分理解为是按照数据行的切分,就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其他的数据库中 

    当一个应用难以再细粒度的垂直切分,或切分后数据量行数巨大,存在单库读写、存储性能瓶颈,这时候就需要进行水平切分了。

    水平切分分为库内分表和分库分表,是根据表内数据内在的逻辑关系,将同一个表按不同的条件分散到多个数据库或多个表中,每个表中只包含一部分数据,从而使得单个表的数据量变小,达到分布式的效果

    库内分表只解决了单一表数据量过大的问题,但没有将表分布到不同机器的库上,因此对于减轻MySQL数据库的压力来说,帮助不是很大,大家还是竞争同一个物理机的CPU、内存、网络IO,最好通过分库分表来解决。

    几种典型的分片规则包括:

     按照用户 ID 求模,将数据分散到不同的数据库,具有相同数据用户的数据都被分散到一个库中。

     按照日期,将不同月甚至日的数据分散到不同的库中。

     按照某个特定的字段求摸,或者根据特定范围段分散到不同的库中。

     切分原则都是根据业务找到适合的切分规则分散到不同的库,

     优点:

     拆分规则抽象好,join 操作基本可以数据库做。

     不存在单库大数据,高并发的性能瓶颈。

     应用端改造较少。

     提高了系统的稳定性跟负载能力。

    缺点:

     拆分规则难以抽象。

     分片事务一致性难以解决。

     数据多次扩展难度跟维护量极大。

     跨库 join 性能较差。

     

    分库分表可以在不同的层做。一般来说有以下几种:

    jdbc层:实现复杂,属于轻量级,对应用基本没有侵入性;缺点是不能复用数据库连接,在应用部署多的时候资源耗费大,不适于大规模部署。类似当当网的sharding-jdbc.

    ORM层:比如蘑菇街TSharding框架封装mybatis,实现简单。缺点是必须依赖ORM层,侵入性比较大。

    DBProxy层:如cobar和mycat,可以做到连接复用,性能不错,完全没侵入性。缺点是实现复杂,框架比较重,维护工作量大。

    DAO层:实现简单,缺点是分表比较麻烦。美团的框架似乎就是这样做到。

    无论怎么做分库分表,其基本思路都是一样的。需要有分库路由,分库规则,分库关键字

     

    分库数量

     

    分库数量首先和单库能处理的记录数有关,一般来说,Mysql 单库超过5000万条记录,Oracle单库超过1亿条记录,DB压力就很大(当然处理能力和字段数量/访问模式/记录长度有进一步关系)。

    在满足上述前提下,如果分库数量少,达不到分散存储和减轻DB性能压力的目的;如果分库的数量多,好处是每个库记录少,单库访问性能好,但对于跨多个库的访问,应用程序需要访问多个库,如果是并发模式,要消耗宝贵的线程资源;如果是串行模式,执行时间会急剧增加。

    最后分库数量还直接影响硬件的投入,一般每个分库跑在单独物理机上,多一个库意味多一台设备。所以具体分多少个库,要综合评估,一般初次分库建议分4-8个库。

     

    路由透明

    分库从某种意义上来说,意味着DB schema改变了,必然影响应用,但这种改变和业务无关,所以要尽量保证分库对应用代码透明,分库逻辑尽量在数据访问层处理。当然完全做到这一点很困难,具体哪些应该由DAL负责,哪些由应用负责,这里有一些建议:

    对于单库访问,比如查询条件指定用户Id,则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库,当库二次分裂时,也只要修改mod 因子,应用代码不受影响。

    对于简单的多库查询,DAL负责汇总各个数据库返回的记录,此时仍对上层应用透明。

     

     

    几种典型的数据分片规则为:

    1、根据数值范围 : 按照时间区间或ID区间来切分

    2、根据数值取模 :  一般采用hash取模mod的切分方式

    问题:

    1、事务一致性问题 : 更新内容同时分布在不同库中,不可避免会带来跨库事务问题。跨分片事务也是分布式事务,没有简单的方案,一般可使用"XA协议"和"两阶段提交"处理。

    2、跨节点关联查询 join 问题  : 切分之前,系统中很多列表和详情页所需的数据可以通过sql join来完成。而切分之后,数据可能分布在不同的节点上,此时join带来的问题就比较麻烦了,考虑到性能,尽量避免使用join查询。

    3、跨节点分页、排序、函数问题   : 跨节点多库进行查询时,会出现limit分页、order by排序等问题。分页需要按照指定字段进行排序,当排序字段就是分片字段时,通过分片规则就比较容易定位到指定的分片;当排序字段非分片字段时,就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回,然后将不同分片返回的结果集进行汇总和再次排序,最终返回给用户。 

    4、全局主键避重问题 : 在分库分表环境中,由于表中数据同时存在不同数据库中,主键值平时使用的自增长将无用武之地,某个分区数据库自生成的ID无法保证全局唯一。因此需要单独设计全局主键,以避免跨库主键重复问题。

    5、数据迁移、扩容问题 

     

    展开全文
  • Oracle 数据库分库分表 分布式事务。

    万次阅读 2017-10-29 11:37:06
    分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在...

    1、什么是分布式事务

    分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释,简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。本质上来说,分布式事务就是为了保证不同数据库的数据一致性。

    2、分布式事务的产生的原因

    2.1、数据库分库分表

    当数据库单表一年产生的数据超过1000W,那么就要考虑分库分表,具体分库分表的原理在此不做解释,以后有空详细说,简单的说就是原来的一个数据库变成了多个数据库。这时候,如果一个操作既访问01库,又访问02库,而且要保证数据的一致性,那么就要用到分布式事务。


    2.2、应用SOA化

    所谓的SOA化,就是业务的服务化。比如原来单机支撑了整个电商网站,现在对整个网站进行拆解,分离出了订单中心、用户中心、库存中心。对于订单中心,有专门的数据库存储订单信息,用户中心也有专门的数据库存储用户信息,库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作,那么就会涉及到订单数据库和库存数据库,为了保证数据一致性,就需要用到分布式事务。


    以上两种情况表象不同,但是本质相同,都是因为要操作的数据库变多了!

    3、事务的ACID特性

    3.1、原子性(A)

    所谓的原子性就是说,在整个事务中的所有操作,要么全部完成,要么全部不做,没有中间状态。对于事务在执行中发生错误,所有的操作都会被回滚,整个事务就像从没被执行过一样。

    3.2、一致性(C)

    事务的执行必须保证系统的一致性,就拿转账为例,A有500元,B有300元,如果在一个事务里A成功转给B50元,那么不管并发多少,不管发生什么,只要事务执行成功了,那么最后A账户一定是450元,B账户一定是350元。

    3.3、隔离性(I)

    所谓的隔离性就是说,事务与事务之间不会互相影响,一个事务的中间状态不会被其他事务感知。

    3.4、持久性(D)

    所谓的持久性,就是说一单事务完成了,那么事务对数据所做的变更就完全保存在了数据库中,即使发生停电,系统宕机也是如此。

    4、分布式事务的应用场景

    4.1、支付

    最经典的场景就是支付了,一笔支付,是对买家账户进行扣款,同时对卖家账户进行加钱,这些操作必须在一个事务里执行,要么全部成功,要么全部失败。而对于买家账户属于买家中心,对应的是买家数据库,而卖家账户属于卖家中心,对应的是卖家数据库,对不同数据库的操作必然需要引入分布式事务。

    4.2、在线下单

    买家在电商平台下单,往往会涉及到两个动作,一个是扣库存,第二个是更新订单状态,库存和订单一般属于不同的数据库,需要使用分布式事务保证数据一致性。

    5、常见的分布式事务解决方案

    5.1、基于XA协议的两阶段提交

    XA是一个分布式事务协议,由Tuxedo提出。XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、DB2这些商业数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下:


    总的来说,XA协议比较简单,而且一旦商业数据库实现了XA协议,使用分布式事务的成本也比较低。但是,XA也有致命的缺点,那就是性能不理想,特别是在交易下单链路,往往并发量很高,XA无法满足高并发场景。XA目前在商业数据库支持的比较理想,在mysql数据库中支持的不太理想,mysql的XA实现,没有记录prepare阶段日志,主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA,这让XA的应用场景变得非常狭隘。

    5.2、消息事务+最终一致性

    所谓的消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个分布式事务里,保证要么本地操作成功成功并且对外发消息成功,要么两者都失败,开源的RocketMQ就支持这一特性,具体原理如下:


    1、A系统向消息中间件发送一条预备消息
    2、消息中间件保存预备消息并返回成功
    3、A执行本地事务
    4、A发送提交消息给消息中间件

    通过以上4步完成了一个消息事务。对于以上的4个步骤,每个步骤都可能产生错误,下面一一分析:

    • 步骤一出错,则整个事务失败,不会执行A的本地操作
    • 步骤二出错,则整个事务失败,不会执行A的本地操作
    • 步骤三出错,这时候需要回滚预备消息,怎么回滚?答案是A系统实现一个消息中间件的回调接口,消息中间件会去不断执行回调接口,检查A事务执行是否执行成功,如果失败则回滚预备消息
    • 步骤四出错,这时候A的本地事务是成功的,那么消息中间件要回滚A吗?答案是不需要,其实通过回调接口,消息中间件能够检查到A执行成功了,这时候其实不需要A发提交消息了,消息中间件可以自己对消息进行提交,从而完成整个消息事务

    基于消息中间件的两阶段提交往往用在高并发场景下,将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作,其中B系统的操作由消息驱动,只要消息事务成功,那么A操作一定成功,消息也一定发出来了,这时候B会收到消息去执行本地操作,如果本地操作失败,消息会重投,直到B操作成功,这样就变相地实现了A与B的分布式事务。原理如下:


    虽然上面的方案能够完成A和B的操作,但是A和B并不是严格一致的,而是最终一致的,我们在这里牺牲了一致性,换来了性能的大幅度提升。当然,这种玩法也是有风险的,如果B一直执行不成功,那么一致性会被破坏,具体要不要玩,还是得看业务能够承担多少风险。

    5.3、TCC编程模式

    所谓的TCC编程模式,也是两阶段提交的一个变种。TCC提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。以在线下单为例,Try阶段会去扣库存,Confirm阶段则是去更新订单状态,如果更新订单失败,则进入Cancel阶段,会去恢复库存。总之,TCC就是通过代码人为实现了两阶段提交,不同的业务场景所写的代码都不一样,复杂度也不一样,因此,这种模式并不能很好地被复用。

    6、总结

    分布式事务,本质上是对多个数据库的事务进行统一控制,按照控制力度可以分为:不控制、部分控制和完全控制。不控制就是不引入分布式事务,部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC模式,而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景。作为技术人员,一定不能忘了技术是为业务服务的,不要为了技术而技术,针对不同业务进行技术选型也是一种很重要的能力

    展开全文
  • 数据库分库分表

    2020-07-23 09:00:27
    当数据量大,表字段多时,对数据库的操作速度影响业务正常使用时,可以考虑分库分表了; 数据切分一般分两种:垂直切分 和 水平切分; 垂直切分 垂直切分,就是根据业务的耦合性,针对不同的业务,将关联度较低的...
  • 分库分表数据库分片方案 数据库数据量达到千万级别时查询效率会很低,分库分表是一种很有效的解决方案。 垂直划分和水平划分 垂直划分:垂直划分又分为垂直分库和垂直分表两种,垂直分库就是将关联度低的各种表...
  • 分库分表技术应运而生。 这些技术看似很高深,其实不难,其核心就是对数据库数据进行划分,将数据放到不同的表、不同数据库中。具体如何划分则需要根据实际业务操作。 讲一讲分区表 分区表是由多个相关的底层表实现...
  • 本发明涉及数据库,尤其涉及一种数据库分库分表扩容方法。背景技术:::数据库是按照数据结构来组织、存储和管理数据的仓库,它产生于距今六十多年前,随着信息技术和市场的发展,特别是二十世纪九十年代以后,...
  • Mysql从5.1版本开始支持分区的功能,分区是指根据一定的规则,数据库把一个表分解成多个更小的、更容易管理的部分,就访问数据库而言,逻辑上只有一个表或一个索引,但是实际上这个表可能由数个物理分区对象组成,每...
  •  分库分表也称作分片技术,主要作用是将存放在一个数据库中的数据按照特定的方法进行拆分,分散存放在多个数据库中,以达到分散多台设备实现负载均衡  垂直分割  纵向切分,把一个表的表结构拆分开来,形成多个...
  • 分库分表或者 sharding 的本质是摩尔定律的失效,单一节点的计算能力无法管理所有的应用状态。由于在多个节点上维护同一份状态并且保证彼此一致的成本太高,所以需要设计一组策略,把应用数据分成若干份,让每一份...
  • 2.分库分表 3.类别 lib库 1)业务直接到数据库,少一层proxy效率更高 2)没有proxy的lvs的单点问题 proxy 1)统一管理所有到数据库的连接,连接复用 2)基础查询功能抽象,减少代码耦合 3)易于实现监控、...
  • 一、分区的概念 数据分区是一种物理数据库的设计技术,它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。...2、数据管理比较方便,比如要清理或废弃某年的数据,就可以直接删除该日期...
  • 目录 ...四 分库分表数据库原理  数据库底层一个以某种有组织的方式存储的数据集合。也就是:保存有组织数据的容器 在此之上会有一套建立、管理、维护数据库的系统软件,也就是数据库管理...
  • 分区是将一个表或索引分解成多个更小,更可管理的部分。 每个区都是独立的,可以独立处理,也可以作为一个更大对象的一部分进行处理。这个是MySQL支持的功能,业务代码无需改动。 要知道MySQL是面向OLTP的数据,它不...
  • 分库分表3.类别lib库1)业务直接到数据库,少一层proxy效率更高2)没有proxy的lvs的单点问题proxy1)统一管理所有到数据库的连接,连接复用2)基础查询功能抽象,减少代码耦合3)易于实现监控、数据迁移、连接管理等功能...
  • 一、项目结构1、工程结构2、模块命名shard-common-entity: 公共代码块shard-open-inte: 开放接口管理shard-eureka-7001: 注册中心shard-two-provider-8001: 8001 基于两台的服务shard-three-provider-8002:...
  • 数据库分布式,其核心内容无非就是数据切分(Sharding),以及切分后对数据的定位、整合工作,解决单一数据库或数据表因数据量过大而导致的...后者分布式数据库则是集数据存储、管理以及分布式协调与计算为一体的...
  • 1、起因 互联网发展带来来了数据量巨增,单数据无法解决,导致出现了数据库分库分表,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。但是分库和分表带来的问题是业务数据的一致性...
  • 应该使用哪一种方式来实施数据库分库分表这要看数据库中数据量的瓶颈所在并综合项目的业务类型进行考虑 分库分表存在的问题 事务问题 跨库跨表的join问题 额外的数据管理负担和数据运算压力 1.基本思想...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 492
精华内容 196
关键字:

数据库分库分表管理