亿级流量架构之分布式事务思路及方法.docxVIP

亿级流量架构之分布式事务思路及方法 前面讲过集群的AKF拆分准绳( Redis集群拆分准绳之AKF ),或许意思是硬件功能是由上限的,当硬件没法支撑恳求流量时,可以将流量分发到不同的服务器上,AKF拆分之Y轴、Z轴拆分是业务拆分与数据拆分,那也就会涉及到将数据库中的数据拆分存储在不同的地方,这就叫分库分表,不同类型数据存储在不同数据库中做多机存储和负载,这样一来,传统的事务机制ACID便无法正常运转。 分库分表内容是数据切分（Sharding），以及切分后对数据的定位、整合。具体来说, 数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库功能问题，从而达到提升数据库操作功能的目的。 数据切分依据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分。 垂直拆分 垂直切分常见有垂直分库和垂直分表两种,两种含义类似。 垂直分库就是依据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与微服务管理的做法相像，每个微服务使用单独的一个数据库。如图： 垂直分表类似,例如将一张表包含一个人全部信息,例如姓名、身份证、性别、身高、体重、省、市、区、村、专业、G点等等,那么可以拆分成三个表: 第一个表只包含基本信息(姓名、身份证、性别、身高、体重); 其次个表包含籍贯信息(省、市、区、村); 第三个表包含学习信息(专业、G点)。 垂直拆分优缺点 垂直切分的优点： 处理业务系统层面的耦合，业务清楚 与微服务的管理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等 高并发场景下，垂直切分肯定程度的提升IO、数据库连接数、单机硬件资源的瓶颈 垂直切分的缺点： 部分表无法join，只能通过接口聚合方式处理，提升了开发的简单度 分布式事务处理简单 照旧存在单表数据量过大的问题（需要水平切分） 水平拆分 上面对数据库垂直拆分之后,假如某个库还是好大,比如存储的数据极其浩大,那么可以再对数据库进行水平的拆分: 上面的水平拆分时依据ID区间来切分。例如：将userId为1~10000的记录分到第一个库，10001~20000的分到其次个库，以此类推。某种意义上，某些系统中使用的冷热数据分别，将一些使用较少的历史数据迁移到其他库中，业务功能上只供应热点数据的查询，也是类似的实践。 除了上面依据用户ID区间拆分,也可以做Hash运算拆分,这儿就不具体开放了。 水平拆分优缺点 水平拆分优点在于： 单表大小可控 自然?便于水平扩展，后期假如想对整个分片集群扩容时，只需要添加节点即可，无需对其他分片的数据进行迁移 使用分片字段进行范围查找时，连续分片可快速定位分片进行快速查询，有效避开跨分片查询的问题。 水平拆分缺点： 热点数据成为功能瓶颈。连续分片可能存在数据热点，例如按时间字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询 分库分表带来的问题 分库分表能有效的缓解单机和单库带来的功能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题,前面说过,事务包含一组子操作,这些造作要么全部执行,要么全部不执行,但是分库之后,一个事务可能涉及多个数据库或者多个表扩库执行,而网络具有不稳定性,也就是事务执行难度加大,分表分库后事务为了与传统事务做出区分,叫做分布式事务(跨分片事务)。 跨分片事务也是分布式事务，没有简约的方案，一般可使用XA协议和两阶段提交处理。 分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间。导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多，这种趋势会越来越严峻，从而成为系统在数据库层面上水平扩展的枷锁。 最终全都性 对于那些功能要求很高，但对全都性要求不高的系统，往往不苛求系统的实时全都性，只需在允许的时间段内达到最终全都性即可，可接受事务补偿的方式。与事务在执行中发生错误后马上回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，基于日志进行对比，定期同标准数据来源进行同步等等。事务补偿还要结合业务系统来考虑。 分布式事务处理思路 讲这个之前需要先简约回顾CAP准绳和Base理论,由于分布式事务不同于 ACID 的刚性事务，在分布式场景下基于 BASE 理论，提出了柔性事务的概念。要想通过柔性事务来达到最终的全都性，就需要依靠于一些特性，这些特性在具体的方案中不肯定都要满足，由于不同的方案要求不一样；但是都不满足的话，是不行能做柔性事务的。 CAP准绳 CAP一般人可能听了不下一百遍了,很多人都说CAP是三选二的关系,让人误以为