有状态实例VS无状态实例
无状态实例：每个运行的实例不需要自己持久化(存储)数据；多个实例可以共享相同的持久化数据；可以轻易地进行扩缩容。
有状态实例：每个运行的实例都需要自己持久化(存储)数据；扩缩容时，需要考虑数据一致性问题。
PS：此处用的是”实例“而不是”服务“，主要是”服务“的概念比较宽泛，容易引起误解。
无状态实例类似于编程语言中的函数编程，只要输入是相同的，输出那么一定也是相同的。有状态实例类似于编程语言中具有属性的对象实例，输入相同，输出未必相同，多个对象实例之间还会有"属性一致性"等问题。
一般系统架构分成两个部分，无状态部分和有状态部分。业务逻辑的部分往往作为无状态的部分，可以很容易的部署、扩缩容；业务数据往往保存在有状态的中间件中，如缓存、数据库、对象存储、大数据平台、消息队列等，这些中间件设计之初，就考虑了扩缩容、状态迁移、复制、同步等机制，不用业务层关心。
CAP
CAP原则又称CAP定理，指的是在一个分布式存储系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
(1)一致性（读、写的执行结果）
每次读操作都能保证返回最新数据。如果针对一个数据项的更新执行成功后，在所有实例中都可以读取到最新值。
(2)可用性（读、写的执行）
没有发生故障的实例，在合理时间内，能正常执行一个读写操作。
(3)分区容错性（环境故障）
允许实例发生网络分区的情况。什么是网络分区？有些实例因为网络通讯等故障，不能再互相联通。
- 准许网络分区（分区容错性）
假设有5个实例n1~n5，网络分区被分成两组[n1,n2] [n3,n4,n5]。
如果保证CP without A，n1实例写操作必须通知n2~n5实例更新持久化的数据，保证一致性，但因为网络分区被分成两组[n1,n2] [n3,n4,n5]，n1无法同[n3,n4,n5]通信，所以n1只能不再提供正常的写操作。其他实例的写操作请求同理，因此整个系统变得不可用。
如果保证AP without C，n1实例写操作正常执行后，通知n2~n5实例更新持久化的数据，但因为网络分区被分成两组[n1,n2] [n3,n4,n5]，n1无法同[n3,n4,n5]通信，造成[n1,n2] [n3,n4,n5]两组实例的数据不再一致，无法保证一致性。
- 不准许网络分区（分区容错性）
如果实例之间通过网络通信，那么网络分区故障是必然的。不准许有网络分区故障，等于没有网络不分区。这时候，一般都是单实例存储系统，例如Mysql等关系数据库，这时候保证CA是很容易的。
BASE
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
(1)Basically Available（基本可用）
以AP without C为主，即以可用性为系统设计的主要目标，绝大部分时候有可用的实例。
(2)Soft state（软状态）
允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
(3)Eventually consistent（最终一致性）
强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
