分布式系统(数据库)实现中的CAP原则和ACID原则



  • 在学习分布式数据库和编写区块链超级账本的同步过程中,CAP原则(强一致性,可用性,分区容忍性)和ACID原则是我们必须考虑的问题

    CAP原则

    Consistency, Availability, Partition Tolerance

    定义

    • 强一致性: 在分布式系统中(分布式数据库)同一个数据存在多个副本,每台机器都维护自己的账本,我们需要保证外部用户访问的时候,对于数据库的增删读写操作和集中式数据库是一样的。(外面的人看来数据只有一份)

    • 可用性: 外部用户(客户端)在使用我们分布式数据库的增删读写操作应该在一定时间内完成,应该是人类可以接受的速度。起码不能一个操作花一分钟吧?

    • 分区容忍性: 在大规模的分布式数据库中,必须能保证在同一片区域的服务器全部宕机的情况下,不影响整体的功能和使用。

    对于一个大规模分布式数据系统来说,CAP三要素是不可兼得的,同一系统至多只能实现其中的两个,而必须放宽第3个要素来保证其他两个要素被满足。一般在网络环境下,运行环境出现网络分区是不可避免的,所以系统必须具备分区容忍性(P)特性,所以在一般在这种场景下设计大规模分布式系统时,往往在A或者C中选择一个进行舍弃。

    分布式数据库下三者不可兼得

    上述分布式数据库中,必须保证可用性,所以分区容忍性必须优先。那么consistency和availability就是不能相互兼容得了了。如果要加快用户的操作速度,就必须牺牲一致性(即同步的速度,而不会出现数据完全不一样的问题)。

    情况一

    如果这个分布式系统中数据没有副本,那么系统必然满足强一致性,因为只有孤本数据,不会出现数据不一致的问题,此时C、P都满足,但是这是不符合分布式数据库的要求的。一旦这些孤本数据所在的机器宕机了,那么数据库就崩了。

    情况二

    如果在分布式系统(数据库)中数据有多个副本,那么某些服务器宕机,整个分布式系统还是可以正常服务,这里满足Availability,但是副本之间不能保证实时的一致,所以损害了Consistency原则。(有可能导致用户获得的数据是过时的,旧的,不准确的)

    总结

    所以一般情况下,会根据具体业务来侧重于C或者A,对于一致性要求比较高的业务,那么对访问延迟时间要求就会低点;对于访问延时有要求的业务,那么对于数据一致性要求就会低点。一致性模型主要可以分为下面几类:强一致性、弱一致性、最终一致性、因果一致性、读你所写一致性、会话一致性、单调读一致性、以及单调写一致性,所以需要根据不同的业务选择合适的一致性模型。

    ACID原则

    ACID是关系型数据库系统采纳的原则,其代表的含义分别是:Atomicity,Consistency,Isolation,Durability。

    Atomicity原子性

    一个事务要么完全执行,要么就不开始执行。在GO中可以用互斥锁或者channel来保证这个事情。

    Consistency一致性

    事务开始和结束的时候,要始终满足一致性的约束。即保证数据是符合某一个标准的,不会出现改了某个数据,造成另外数据的紊乱。比如系统要求A+B=100,那么事务如果改变了A的数值,则B的数值也要相应修改来满足这样一致性要求。

    Isolation事物的独立性

    如果有多个事物同时执行,彼此之间不需要知晓对方的存在,而且执行时互不影响,事务之间需要序列化执行,有时间顺序。这里相当于异步操作,在GO中可以用多线程来完成。

    Durability持久性

    事务的持久性是指事务执行成功以后,对系统状态的更新是永久的,不会无缘无故回滚撤销。

    以上原则对于分布式数据库,区块链中的超级账本有比较重要的指导作用。当讨论实现方法的时候,会有折中的问题,这时候就应该上升到这些理论的原则分类问题。只有在充分讨论开发的系统侧重之后,并结合上述原则来实现系统的功能,才能最大程度保证系统的稳定性和可用性。



Copyright © 2018 bbs.dian.org.cn All rights reserved.

Looks like your connection to Dian was lost, please wait while we try to reconnect.