在学习分布式数据库和编写区块链超级账本的同步过程中，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持久性
事务的持久性是指事务执行成功以后，对系统状态的更新是永久的，不会无缘无故回滚撤销。
以上原则对于分布式数据库，区块链中的超级账本有比较重要的指导作用。当讨论实现方法的时候，会有折中的问题，这时候就应该上升到这些理论的原则分类问题。只有在充分讨论开发的系统侧重之后，并结合上述原则来实现系统的功能，才能最大程度保证系统的稳定性和可用性。
