|
的原子性也是这个道理,就是事务不可以再拆分,例如上面的事务,看着可以是由两个过程组成的事务,但是你拆开就不是我们认为该有的过程,所以,事务不可再分,具有原子性。
一致性（Consistency）
一致性也很好理解,对于上面的两个账户,如果银行想知道自己这儿被存了多少钱,那么这个事务执行前,A账号有500块,B账号没有钱,银行账户总共500块,事务执行后A账号没有钱,B账号有500块,也就是这个500块是一定的,不可能出现A账号有500块,B账号也有500块, 那就数据不一致了,这样的话,说明事务中某些步骤执行出现了问题,产生中间数据,那么就不一致。
在分布式中,对于一个结果,多处同时查询,得出的结果应该是一致的。
隔离性（Isolation）
一个事务在未完成时，另一个事务不会影响到它,也就是如果B还给C转账1000,记为事务2:
事务1 = (A账号扣除500,B账号增加500)
事务2 = (B账号扣除1000,C账号增加1000)
这两个事务之间不会产生影响,也就是不会发生A转出的500块到达C账号这种情况。
持久性（Durability）
持久化,一般是意味着将数据写入磁盘,不会轻易改变的意思,这儿是事务提交之后,会影响到数据库,不会丢失。这也就意味着,随着系统越来越庞大，我们为了提高可用性、维护性、吞吐量等等技术指标，就算改善原有架构，业务计算的问题解决后，数据库还是会成为整个系统中的瓶颈。
一致性的讨论
ACID本质而言都是为了保护数据的一致性,而数据数据持久化时会触发数据库操作,造成效率低小,所以围绕一致性(效率)产生了一些讨论,分别是强一致性、弱一致性、最终一致性。
强一致性
任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的,这就要求数据一有改变就写到数据库。
弱一致性
数据更新后，不要求及时写会数据库以及同步到所有节点,也就是这时候数据与真实数据可能有一些出入,对于架构而言,如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
最终一致性
不保证在任意时刻任意节点上的同一份数据都是相同的，也就是有些节点数据可能是准确的,有的可能是不准确的, 但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。
三种一致性中,强一致性数据更加可靠,但是由于时时刻刻要求所有数据库保持数据一致,所以效率低下,数据没有统一完,请求就没法得到响应,高并发场景下,体验不太好,所以在实际使用中,根据不同的业务选择是一致性也不同,购物时账号付钱肯定是强一致性,但是商品库存数据就不一定非要强一致性,至于商品下面的评论啥的,甚至可以选择弱一致性。
分库分表
前面讲过集群的AKF拆分原则( Redis集群拆分原则之AKF ),大概意思是硬件性能是由上限的,当硬件没法支撑请求流量时,可以将流量分发到不同的服务器上,AKF拆分之Y轴、Z轴拆分是业务拆分与数据拆分,那也就会涉及到将数据库中的数据拆分存储在不同的地方,这就叫分库分表,不同类型数据存储在不同数据库中做多机存储和负载,这样一来,传统的事务机制ACID便无法正常运行。
分库分表内容是数据切分（Sharding），以及切分后对数据的定位、整合。具体来说, 数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库性能问题，从而达到提升数据库操作性能的目的。
（编辑：宁德站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
