通过ap系统，我想你至少会以确保最终的一致性为目标。
假设你正在开发一个社交网络，用户有朋友和自己的新闻源。如果某个特定用户的feed偶尔有5分钟的延迟（他的feed列表最终是一致的），这并不重要。在这种情况下，新闻提要中缺少2/3的最新更新是可以的，只要这些提要最终会出现。事实上，facebook使用cassandra构建了新闻提要。
设想一个分布式键值存储缓存系统，其中更新非常罕见。如果几乎没有更新操作，那么确保强一致性是没有必要的，因此您可以关注可用性。偶尔缓存未命中（键值项尚未填充）以及由于最终一致性而对数据库的请求应该是可以的。

我的问题是在什么情况下你能牺牲一致性？
其中一个例子是构建一个推荐引擎数据集并用cassandra服务它。这些数据集本质上是许多用户的集合，用于确定购买/查看模式。
例如：如果我将一个rey星球大战人物添加到我的购物车中，那么底层的推荐引擎会根据购买了rey人物的其他人运行一个查询，以获得类似的购买模式。查询返回前5个产品结果，并将它们放在页面底部。
这5件退货产品是对几千件以前购买的产品进行分析和汇总的结果。假设其中一些数据不一致，导致返回的5种产品出现差异。这真的有什么大不了的吗？
热释光；博士；真正要问的问题；在不到10毫秒的时间内得到5个产品推荐的准确列表是否比在100毫秒内得到5个产品推荐的100%准确列表要好？
两个结果集都将有助于推动销售。但是返回的速度足够快，并且不会妨碍用户体验的方法更受欢迎。

cap中的“c”指的是线性化能力，这是一种非常强的一致性形式，你大部分时间都不需要。
线性化是一种近期保证，它使数据看起来只有一个拷贝。一旦对数据进行更改，所有后续读取都将返回更改的数据。这样一个级别的一致性是昂贵的，而且不能很好地扩展。但在某些情况下，我们需要线性化，即。
领导人选举
允许最终用户创建其唯一的用户id
分布式锁定等。
当您有这些用例时，您将使用类似zookeeper、etcd等的东西。cassandra还有轻量级事务（lwt），它使用经典paxos算法的扩展来实现线性化。这个特性可以用来处理那些罕见的用例，在这些用例中，您必须具有线性化能力和串行化能力，但是代价很高。在绝大多数情况下，您只需要稍微降低一致性就可以获得更好的可伸缩性和性能。您需要在可伸缩性和性能上交换一点一致性。
一些电子商务网站向未能履行订单的客户发送道歉信。这是因为产品的最后一个拷贝由于缺乏可线性化性而被卖给了不止一个客户。他们更愿意处理这个问题，而不是不能与客户群一起扩展，也不能在严格的sla中响应他们的请求。
Cassandra据说有一个可调的一致性。您可能需要记录用户单击或活动以进行分析。如果某些数据丢失，您可以，但不能影响性能。您可能会在启用提示的情况下使用任意写入一致性级别（sloppyquorum）。
如果您想要更高一点的一致性，您可以使用仲裁一致性级别来读写，同时使用提示和读修复。在绝大多数情况下，所有节点都会即时更新。即使一个或两个节点发生故障，大多数节点都会有数据，当故障节点返回时，也会使用提示、读取修复、反熵修复等方法进行修复。
cassandra对于同一数据上没有太多并发更新的情况特别有用。原因是，与dynamo体系结构不同，它不使用矢量时钟来解决副本之间的冲突。相反，它使用基于时间戳的last write wins（lww）。如果时间戳相同，则使用字典顺序。由于即使存在ntpd，节点上的时间也不准确，因此存在数据丢失的可能性，尽管cassandra已经采取了一些措施来避免这种情况，例如客户端时间戳而不是服务器端时间戳。

cap定理说，给定分区容差，您可以在分布式数据库中选择可用性或一致性（在任何情况下，没有人愿意放弃分区容差）。因此，如果您想获得最大的可用性，就必须放弃一致性。当然，这取决于业务的关键程度。
你回答了某个问题，所以当你访问页面时，答案没有出现？可以容忍。那么，你是说你情绪低落？不可能。关键的金融系统宁愿有很强的一致性，而不是可用性。每隔一段时间，当我试图付款时，银行的服务器就会离线。
通常，您选择可用性和最终一致性。你写的答案最终会出现。