分布式数据库

应对数据库的压力日益增大方案：

1、更换更好的硬件（在我们能付得起硬件费用并且没有达到硬件单机瓶颈，这是比较简单的解决方案）

2、现有数据库减压（超过单机极限时，应该考虑的方案）

减压思路有三：

1）优化应用（减少没有必要的数据库压力）

2）其它机制降低对数据库的压力（引入缓存、加搜索引擎）

3）数据拆分，把数据库的数据和访问分到多台数据上，分开支持

数据拆分：垂直拆分、水平拆分

1、垂直拆分（同一数据库中不同业务单元的数据拆分到多个数据库中）

面临的问题：

1）单机的ACID保证被打破了。（拆分后，原来的单机通过事务来进行处理逻辑会受到影响，要么放弃之前的单机实现，修改实现，要么引入分布式事务）

2）一些Join操作会变得比较困难

3）靠外键约束的场景会受到影响

2、水平拆分（同一数据库中同一业务单元的数据拆分到多个数据库中）

面临的问题：

同上1、2、3问题

4、依赖单库的自增序列生成唯一ID会受影响

5、针对单个逻辑意义上的表查询要跨库了

问题1的解决方案（分布式事务实现）：

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。

对于传统的单机事务，所有的事情都在这一台机器上完成，而分布式事务中，会有多个节点参与。

X/Open组织提出一个分布式事务的规范-XA。

定义一个分布式事务处理模型-X/Open DTP模型。含三个组件：Application Program、Resource Manager和Transaction Manager

两阶段提交：

在单库上完成相关的数据操作后，就会直接提交或者回滚，而在分布式系统中，在提交前增加了准备阶段，所以称为两阶段提交。

分布式系统中，节点之间的信息交换有两种方式，一种是通过共享内存共用一份数据；另一种是通过消息投递来完成信息的传递。

消息投递方式面临意外：网络问题、进程挂掉、机器挂掉、进程很慢没有响应、进程重启等情况。

除了使用两阶段提交外，更轻量级的Paxos协议，都提供解决分布式系统中一致性问题的解决方案。

大型网站一致性理论-CAP/BASE

CAP:

Consistency：一致性（所有界节点在同一时间对到同样数据）

Availability：可用性（无论成功还是失败，一定要有响应）

Partition-Tolerance：分区容忍性（系统一部分出现问题，整个系统仍能够继续工作）

分布式系统不能同时满足以上三点，大型互联网站一般采用AP，首先满足A和P，对于C，策略是保证最终一致，放弃强一致性。

BASE 模型：

Basically Available：基本可用，允许分区失败

Soft State：软状态，接受一段时间的状态不同步

Eventually Consistent：最终一致，保证最终数据的状态是一致的

问题2的解决方案（跨库Join）：

1、在应用层把原数据库的join操作分成多次数据库操作（先从一张表查记录A，再根据记录A的属性查另一张表）

2、数据冗余（需要联表查的字段，冗余到一张表）

3、借助外部系统解决跨库问题

问题3的解决方案（外键约束）：

问题棘手，如果分库后单数据库的数据非内聚，则只能靠应用层的判断、容错等方式了

问题4的解决方案（多机的Sequence问题）：

多机sequence考虑两方面问题：唯一性和连续性

唯一性：可参看UUID生成方式，或根据业务场景（不同维度标识，例如IP、MAC、时间等）来生成唯一ID

连续性：可采用单独的系统负责ID的生成（底层使用独立的存储记录每一个ID序列当前的最大值，并控制并发与更新）

应对多机的数据查询

跨库Json