1.CAP理论
CAP理论的具体内容是在分布式的环境下设计和部署系统时，3个核心的需求 CAP[对应一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）]存在一种特殊的关系。
一致性：在分布式计算中，在执行某项数据的修改操作之后，所有结点在同一时间具有相同的数据，系统具有一致性。
可用性：在每一个操作之后，无论成功或失败，系统都要在一定时间内返回结果，保证每个请求不管成功或者失败都有响应。一定时间指系统操作之后的结果应该是在给定的时间内反馈，如果超时则认为不可用或操作失败。
分区容忍性：系统中任意信息的丢失或失败不会影响系统的继续运行。在网络被分隔成若干个孤立的区域时，系统仍然可以接受服务请求。
CAP理论的核心：一个分布式系统不可能同时很好地满足一致性、可用性和分区容忍性这3个需求，最多只能同时较好地满足两个。系统的设计者要在3个需求之间做出选择。根据CAP原理，NoSQL数据库分成满足CA原则、满足CP原则和满足AP原则三大类。
CA原则：单点集群，满足一致性、可用性的系统，通常在可扩展性上不太强大。
CP原则：满足一致性、分区容忍性的系统，通常性能不是特别高。
AP原则：满足可用性、分区容忍性的系统，通常对一致性要求低一些。
CAP是为了探索不同应用的一致性与可用性之间的平衡，在没有发生分隔时，可以满足一致性与可用性，以及完整的ACID事务支持，通过牺牲一定的一致性来获得更好的性能与扩展性；在有分区发生时，选择可用性，集中关注分区的恢复，需要分隔前、中、后期的处理策略，及合适的补偿处理机制。
2.BASE模型
BASE模型包含如下3个元素。
（1）BA（Basically Available），基本可用：系统能够基本运行，一直提供服务。
（2）S（Soft State），软状态/柔性事务：可以理解为“无连接”的，而“硬状态”（Hard state）是“面向连接”的；系统不要求一直保持强一致状态。
（3）E（Eventually Consistent），最终一致性：系统在某个时刻达到最终一致性，并非时时保持强一致。
软状态是实现BASE模型的方法，基本可用和最终一致是目标。按照BASE模型实现的系统，由于不保证强一致性，系统在处理请求的过程中，可以存在短暂的不一致，在短暂的不一致窗口，请求处理处在临时状态中，系统在做每步操作的时候，通过记录每一个临时状态，在系统出现故障的时候，可以从这些中间状态继续未完成的请求处理或者退回到原始状态，最后达到一致的状态。
3.最终一致性理论
NoSQL数据库一致性有下列几种。
（1）强一致性：要求无论更新操作在哪一个副本执行，之后所有的读操作都要能获得最新的数据。
（2）弱一致性：用户读到某一操作对系统特定数据的更新需要一段时间，这段时间被称为“不一致性窗口”。
（3）最终一致性：弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。
一致性可以从客户端和服务器端两个角度来看，客户端关注的是多并发访问的更新过的数据如何获取的问题，对多进程并发进行访问时，更新的数据在不同进程如何获得不同策略，决定了不同的一致性。服务器关注的是更新如何复制分布到整个系统，以保证最终的一致性。一致性因为有并发读/写才出现问题，一定要结合并发读/写的场地应用要求。如何要求一段时间后能够访问更新后的数据，即为最终一致性。最终一致性根据其提供的不同保证可以划分为更多的模型。
（1）因果一致性：无因果关系的数据的读/写不保证一致性。例如3个相互独立的进程A、B、C，进程A更新数据后通知进程B,B完成最后的操作写入数据，保证了最终结果的一致性，系统不保证和A没有因果关系的C一定能够读取该更新的数据。
（2）读一致性：用户自己总能够读到更新后的数据，不保证所有的用户都能够读到更新的数据。
（3）会话一致性：把读取存储系统的进程限制在一个会话范围内，只要会话存在，就可以保证读一致性。
（4）单调读一致性：如果数据已被用户读取，任何后续的操作都不会返回到给数据之前的值。
（5）单调写一致性：来自同一个进程的更新操作按照时间顺序执行，也叫时间轴一致性。
以上5种一致性模型可以进行组合，例如读一致性和单调读一致性可以组合，即读自己更新的数据并且一旦读到最新的数据就不会再读以前的数据。系统采用哪种一致性模型，依赖于应用的需求。
很多Web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高，允许实现最终一致性。例如，发一条消息之后，过几秒乃至十几秒之后，订阅者才看到，这是完全可以接受的。对SNS类型的网站，从需求及产品设计角度，较低的读一致性要求避免了多表的连接查询，可以更多地用单表的主键查询，以及单表的简单条件分页查询，特殊的要求就催生了NoSQL技术的发展，用BASE模型保持数据的可用性和一致性。
