分布式架构之CAP与数据库分片架构

CAP定理CAP的特点CP强一致性说明AP: 高可用总结CAP 理论中的C 在实践中是不可能完美实现的在数据复制的过程中节点N1 和节点 N2 的数据并不一致强一致性。即使无法做到强一致性但应用可以采用适合的方式达到最终一致性。具有如下特点基本可用Basically Available分布式系统在出现故障时允许损失部分可用性即保证核心可用。软状态Soft State允许系统存在中间状态而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。最终一致性Eventual Consistency系统中的所有数据副本经过一定时间后最终能够达到一致的状态。2、数据库分片架构读写分离的问题读写分离分散了数据库读写操作的压力但没有分散存储压力为了满足业务数据存储的需求就需要将存储分散到多台数据库服务器上。数据分片将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。 数据分片的有效手段是对关系型数据库进行分库和分表。数据分片的拆分方式又分为垂直分片和水平分片。2.1、垂直分片垂直分库按照业务拆分的方式称为垂直分片又称为纵向拆分它的核心理念是专库专用。 在拆分之前一个数据库由多个数据表构成每个表对应着不同的业务。而拆分之后则是按照业务将表进行归类分布到不同的数据库中从而将压力分散至不同的数据库。下图展示了根据业务需要将用户表和订单表垂直分片到不同的数据库的方案垂直拆分可以缓解数据量和访问量带来的问题但无法根治。如果垂直拆分之后表中的数据量依然超过单节点所能承载的阈值则需要水平分片来进一步处理。垂直分表垂直分表适合将表中某些不常用的列或者是占了大量空间的列拆分出去。假设我们是一个婚恋网站用户在筛选其他用户的时候主要是用 age 和 sex 两个字段进行查询而 nickname 和 description 两个字段主要用于展示一般不会在业务查询中用到。description 本身又比较长因此我们可以将这两个字段独立到另外一张表中这样在查询 age 和 sex 时就能带来一定的性能提升。垂直分表引入的复杂性主要体现在表操作的数量要增加。例如原来只要一次查询就可以获取 name、age、sex、nickname、description现在需要两次查询一次查询获取 name、age、sex另外一次查询获取 nickname、description。水平分表适合表行数特别大的表水平分表属于水平分片。2.2、水平分片水平分片又称为横向拆分。相对于垂直分片它不再将数据根据业务逻辑分类而是通过某个字段或某几个字段根据某种规则将数据分散至多个库或表中每个分片仅包含数据的一部分。 例如根据主键分片偶数主键的记录放入 0 库或表奇数主键的记录放入 1 库或表如下图所示。单表进行切分后是否将多个表分散在不同的数据库服务器中可以根据实际的切分效果来确定。**水平分表**单表切分为多表后新的表即使在同一个数据库服务器中也可能带来可观的性能提升如果性能能够满足业务要求可以不拆分到多台数据库服务器毕竟业务分库也会引入很多复杂性**水平分库**如果单表拆分为多表后单台服务器依然无法满足性能要求那就需要将多个表分散在不同的数据库服务器中。阿里巴巴Java开发手册【推荐】单表行数超过 500 万行或者单表容量超过 2GB才推荐进行分库分表。说明如果预计三年后的数据量根本达不到这个级别请不要在创建表时就分库分表。3、读写分离和数据分片架构下图展现了将数据分片与读写分离一同使用时应用程序与数据库集群之间的复杂拓扑关系。4、实现方式读写分离和数据分片具体的实现方式一般有两种程序代码封装和中间件封装。4.1、程序代码封装程序代码封装指在代码中抽象一个数据访问层或中间层封装实现读写操作分离和数据库服务器连接的管理。**其基本架构是**以读写分离为例4.2、中间件封装中间件封装指的是独立一套系统出来实现读写操作分离和数据库服务器连接的管理。对于业务服务器来说访问中间件和访问数据库没有区别在业务服务器看来中间件就是一个数据库服务器。**基本架构是**以读写分离为例4.3、常用解决方案Apache ShardingSphere程序级别和中间件级别MyCat数据库中间件