NoSQL数据库的一致性有以下几种：
1）强一致性：无论更新操作在任意一个副本执行，之后所有的读操作都要能获得最新的数据。
2）弱一致性：用户读取到某一操作对系统特定数据的更新需要一段时间，这段时间被称为“不一致性窗口”。
3）最终一致性：弱一致性的一种特例，保证用户最终能够读取到某一操作对系统特定数据的更新。
一致性可以从客户端和服务器端两个角度来看，客户端关注的是如何获取多并发访问的更新过的数据，对访问多进程并发时，更新的数据在不同进程如何获得不同策略，决定了不同的一致性。服务器端关注的是更新如何复制并分布到整个系统，以保证最终的一致性。一致性因为有并发读/写才出现问题，一定要结合并发读/写的场地应用要求，即如何要求一段时间后能够访问更新后的数据，也就是最终一致性。最终一致性根据其提供的不同保证，可以划分为更多的模型。
1）因果一致性：无因果关系的数据，其读/写不保证一致性。例如3个相互独立的进程A、B、C，进程A更新数据后通知进程B，B完成最后的操作，写入数据，保证了最终结果的一致性，系统不保证和A没有因果关系的C一定能够读取该更新的数据。
2）“读己之所写”一致性：用户自己总能够读到更新后的数据，当进程A更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性的一个特例。
3）会话一致性：把读取存储系统的进程限制在一个会话范围内，只要会话存在，就可以保证读一致性。系统能保证在同一个有效的会话中实现“读己之所写”的一致性，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
4）单调读一致性：如果数据已被用户读取，任何后续操作都不会返回到该数据之前的值。
5）单调写一致性：来自同一个进程的更新操作按照时间顺序执行，也叫时间轴一致性。
以上5种一致性模型可以进行组合，例如“读己之所写”一致性和单调读一致性可以组合，即读自己更新的数据并且一旦读到最新的数据就不会再读以前的数据。系统采用哪种一致性模型，取决于应用的需求。
很多Web实时系统并不要求严格的数据库事务，对单调读一致性的要求很低，有些场合对写一致性要求也不高，允许实现最终一致性。例如，发一条消息之后，过几秒甚至十几秒之后，订阅者才能看到，这是完全可以接受的。对SNS（社交网站）而言，从需求及产品设计角度看，较低的单调读一致性要求避免了多表的连接查询，更多地用单表的主键查询，以及单表的简单条件分页查询，特殊的要求就催生了NoSQL技术的发展，用BASE模型保持数据的可用性和一致性。
