我是学习分布式系统的新手，并且阅读了CAP定理，并对诸如Cassandra之类的AP系统感兴趣。
我的问题是，在什么情况下您实际上可以牺牲一致性？实际上，我要说的是牺牲一致性，这意味着要提供不准确的数据。那么，在什么情况下，您实际上将使用Cassandra这样的AP数据存储？我想不出我不希望我的阅读前后保持一致的情况。
答案 0 :(得分：3)
通过AP系统，我认为您至少会确保最终的一致性。
想象一下，您正在开发一个社交网络，用户可以在其中拥有朋友和自己的新闻源。特定用户的Feed是否偶尔有5分钟的延迟（他的Feed列表最终具有一致性）都没关系。在这种情况下，只要新闻提要最终出现，就可以在新闻提要中丢失2/3的最新更新。实际上，Facebook使用Cassandra构建了新闻提要。
想象一下一个分布式键值存储缓存系统，其中很少进行更新。如果几乎没有更新操作，则无需确保强一致性，因此您可以专注于可用性。偶然的高速缓存未命中（键值条目尚未填充），并且由于最终的一致性而对数据库的请求应该可以。
答案 1 :(得分：1)
我的问题是，在什么情况下您可以牺牲一致性？
一种情况是构建推荐引擎数据集并与Cassandra一起使用时。这些数据集实质上是许多用户的汇总，以确定购买/观看模式。
例如：如果我在购物车中添加了《雷伊星球大战》可动人偶，则基础推荐引擎将根据其他人也购买了雷伊的可动人偶来查询相似的结果购买模式。该查询返回前5个产品结果，并将它们放在页面底部。
退回的5种产品是数千笔先前购买产品的分析和汇总的结果。假设其中某些数据不一致，导致返回的5种产品出现差异。这真的很重要吗？
tl; dr; 要问的真正问题；在不到10ms的时间内获得5个产品推荐的有点准确列表，是否比在100ms内获得100％准确的5个产品推荐列表更好？
两个结果集都将有助于推动销售。但是，很多更可取，但返回速度又快又不会妨碍用户体验。
答案 2 :(得分：1)
'C'表示线性化，这是一种非常坚固的一致性形式，您在大多数时候不需要。
可线性化性是一种新近性保证，它使它看起来好像有一个数据副本。一旦更改了数据，所有后续读取将返回更改的数据。这样的一致性水平是昂贵的，并且扩展性不好。但是在某些情况下，我们需要线性化，即。
使用这些用例时，可以使用ZooKeeper，etcd等。Cassandra还具有轻量交易（LWT），该交易使用经典Paxos算法的扩展来实现线性化。此功能可用于解决必须具有线性化和可串行化性但昂贵的罕见用例。在大多数情况下，您会感觉很好，但一致性稍差一些，以获得更好的可伸缩性和性能。您在可扩展性和性能上要保持一点一致性。
某些电子商务网站因无法履行订单而向客户发送道歉信。这是因为由于缺乏和线性化，该产品的最后一个副本已出售给多个客户。他们更喜欢处理这些问题，而不是无法与客户群扩展，也无法在严格的SLA中响应他们的请求。
据说Cassandra具有可调整的一致性。您可能想要记录用户的点击或活动以进行分析。如果某些数据丢失，您可以，但是不能牺牲性能。您可能会使用启用了提示（草率仲裁）的ANY写入一致性级别。
如果想要更多的一致性，则可以使用QUORUM一致性级别来读取和写入提示以及读取修复。在绝大多数情况下，所有节点都会即时更新。即使一个或两个节点发生故障，大多数节点也将拥有数据，并且当故障节点使用提示，读取修复，反熵修复返回时，它们将得到修复。
Cassandra对于在相同数据上没有很多并发更新的情况特别有用。原因是，与发电机体系结构不同，它不使用矢量时钟来解决副本之间的冲突。取而代之的是，它基于时间戳使用上次写入获胜（LWW）。如果时间戳相同，则使用字典顺序。由于即使在存在NTPD的情况下，节点上的时间也无法准确显示，因此存在数据丢失的可能性，尽管Cassandra采取了一些措施来避免这种情况-例如客户端时间戳而不是服务器时间戳。
答案 3 :(得分：1)
除了上面提到的可以容忍不一致数据的情况外，还有一些场景我们可以听从用户的意见来解决不一致的问题。
例如，如果我们在数据库中发现某人地址的两个不同版本，我们可以提示用户识别正确的地址。
答案 4 :(得分：0)
CAP定理指出，给定分区容忍度后，您可以在分布式数据库中选择可用性或一致性（在任何情况下都没有人愿意放弃分区容忍度）。因此，如果要获得最大的可用性，则必须放弃一致性。当然，这取决于业务的重要性。
您在SO上回答了一些问题，但是当您访问该页面时却没有显示答案？可以忍受的。如此沮丧？不可以关键金融系统宁愿具有强一致性而不是可用性。每次我尝试付款时，我的银行服务器都会脱机。
通常，您选择可用性和最终一致性。您写给SO的答案最终会显示出来。