大数据开发：分布式环境下数据库的一致性

在大数据技术生态，对于大规模的数据存储问题，主要依赖于分布式去解决。而分布式环境下的数据存储，就不免需要去解决一致性的问题。今天的大数据开发学习分享，我们就主要来讲讲分布式环境下数据库的一致性问题。

什么是一致性？

首先，数据库的一致性，从传统的关系型数据库讲，就是指在一个库中一次业务操作，无论涉及多少张表，多少行集，要么都失败，要么都成功，不能出现结果和预想的不一致，就是所谓的事务ACID特性中最重要的强一致性。

事务具有4个特征，分别是原子性、一致性、隔离性和持久性，简称事务的ACID特性；

1、原子性(atomicity)

一个事务要么全部提交成功，要么全部失败回滚，不能只执行其中的一部分操作，这就是事务的原子性

2、一致性(consistency)

事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。

3、隔离性(isolation）

事务的隔离性是指在并发环境中，并发的事务相互隔离的，一个事务的执行不能不被其他事务干扰。

分布式环境下数据库的一致性特点

1、MySQL的分布式一致性

一个特别典型的例子就是MySQL的主从复制架构：异步，半同步，全同步。

异步：尽管主库保证了数据的强一致性，但是数据一旦写给binlog，主库就无视了从库的一致性，继续忙自己的事情，那么这个过程就是异步的，从库从binlog中拿到结果再重放保证与主库的一致性，我们把这个过程叫做最终一致性。

半同步：MySQL主库写入binlog后，至少集群中任意一个MySQL从库反馈主库，它同步成功了，那么主库就继续忙自己的事了，我们可以把这个过程称为弱一致性。

全同步：自然不用想了，MySQL主库写入binlog，集群其他节点都要重放后，报告同步成功了，主库才会忙其他事情，这就是分布式环境的强一致性了！

弱一致性是在强一致性和最终一致性中寻找一个平衡，至少有一个备份点是必须与主保持一致的，那么数据的可靠性是不是就提升了，同时性能上也不至于太差了。

2、NoSQL的分布式一致性

其次纠正一个错误的观点，NoSQL不能都视之为弱一致性。得具体看是哪个NoSQL框架，例如：MongoDB我们认为是NoSQL，它在副本集模式下，可以灵活地设置一致性规则，其中majority选项的意思是主库写入oplog后，大多数成员需要确认才行。

这个够挠头吧，怎么又来了个大多数，这岂不是在弱一致性和强一致性之间又出现了一种一致性模式，可实际就是这样。

大数据生态重点的一个NoSQL：HBase，它可的确是分布式环境下的强一致性，是不是颠覆了你对NoSQL的认知了！

因为HBase的是基于行级的事务，也就是说当一次写入记录的过程，一定是一个Region只分配一个Region Server写入，而且对于行级数据的操作要不写入成功，要不失败。如果一个节点挂了，恢复节点在没有恢复完数据之前就是不可用了。

HBase在CAP定理中保证了CP，舍弃了A：一致性C(HBase同一时间写入不同节点的数据必须一致)，容错性P(即便有节点出错，系统还能正常运行)，但是这个可靠性A就有问题(必须等待节点恢复完成，对请求就不能立刻有响应了)

最后再说说有些NoSQL的弱一致性为什么就可以被接受？

回顾一下最开始的MySQL的异步模式复制，它为什么是MySQL的默认复制模式？

若满足最终一致性，那么这类分布式系统选择了CAP定理中的AP，就是说为了保证系统内部无论是否出错，都会给客户响应。代价就是分布式各节点的数据副本有可能不一致，但这个问题不是此类系统业务最在乎的事情，往往系统的高性能，并能为客户端提供快速响应力才是关键目标，MySQL的默认主从复制如此，有些NoSQL亦如此。

关于大数据开发学习，分布式环境下数据库的一致性，以上就为大家做了简单的介绍了。在分布式环境下，一致性的问题还是需要根据具体的场景需求去选择解决方案，所以主流的分布式数据库一定要心中有数。