aXq*_*Xqd 5 consistency eventual-consistency cassandra
根据CAP理论,Cassandra最终只能具有一致性.更糟糕的是,如果我们在一次请求中有多次读写而没有正确处理,我们甚至可能失去逻辑一致性.换句话说,如果我们快速做事,我们可能做错了.
同时,为Cassandra设计数据模型的最佳实践是考虑我们将要拥有的查询,然后添加一个CF. 通过这种方式,添加/更新一个实体意味着在许多情况下更新许多视图/ CF. 没有原子事务功能,很难做到正确.但有了它,我们又失去了A和P部分.
我不认为这涉及很多人,因此我想知道为什么.
它确实与人们有关，但想必您正在使用 cassandra，因为由于扩展或可靠性问题，单个数据库服务器无法满足您的需求。因此，您被迫解决分布式系统的限制。
在实际实践中，我们是否总是在中间的某个地方拥有 ACID 功能？我的意思是也许在应用程序层实现或者添加一个中间件来处理它？
不，你通常不会在其他地方有酸，因为想必其他地方也必须分布在多台机器上。相反，您可以围绕分布式系统的限制来设计应用程序。
如果您要更新多个列来满足查询，您可以查看本演示文稿中的最终原子部分，了解如何执行此操作的想法。基本上，在编写之前，您需要编写有关 cassandra 更新的足够信息。这样如果写入失败，您可以稍后重试。
如果您可以以这种方式构建应用程序，那么使用 Zookeeper 或笼子等协调服务可能会很有用。
| 归档时间： |
|
| 查看次数： |
826 次 |
| 最近记录： |