我正在尝试构建一个高度可用的超大量购物车应用程序。该应用程序的容量会如此之高，以至于我正在考虑使用cassandra而不是mysql来存储数据库。
现在，在购物车系统中，大多数数据库操作必须100％一致，而其他操作系统则不一定。
100％一致行动的示例： 保存付款确认。 保存购买的商品清单。
不需要100％一致行动的事例示例： 保存客户的地址（如果在付款时，数据库中没有保存地址，则认为它已丢失并再次询问客户）。 其他类似的事情。
现在，如果我在同一区域（Amazon EC2）中运行服务器群集，那么执行所有事务作为最大一致性事务是否存在任何重大障碍。这会提供与mySQl Relational数据库相同的可靠性。请记住，我们正在处理金融交易。
我的数据在cassandra中通常是“安全的”吗？我的意思是完全意外的电源故障，随机光盘故障等等。
答案 0 :(得分：8)
具体到您关于可用性和EC2的问题......正如Theodore写的那样，Cassandra的一致性水平将决定数据的“安全性”。您将面临的问题是如何确保数据进入Cassandra，实现您的交易目标并正确保存。
在Apache Cassandra用户的邮件列表中有一些关于事务和解决这个问题的好线程。
Cassandra本身并不适合交易：
要解决这个问题，您需要一些可以利用Cassandra作为管理数据层之上事务的数据存储的“东西”。
how to integrate cassandra with zookeeper to support transactions
摘要......您无法保证单独使用Cassandra进行财务交易
答案 1 :(得分：3)
定义一致性的方法有很多种。如果通过“最大一致性事务”，您的意思是在ConsistencyLevel ALL中读取和写入，那么这将提供一致性，即您的读取将永远不会返回过时的值，并且在您的写入将被存储的意义上的持久性返回前的所有节点。
然而，这与交易不同。 Cassandra不支持交易。它不像MySQL那样提供不同行之间的一致性。例如，假设您将一个项目添加到购物篮，并更新购物车中的总成本。单独地，每个操作将被一致且持久地存储。但是，可能会有一个时间窗口，您可以在其中看到一个更改但不能看到另一个更改。在关系数据库中，您可以将它们分组到一个事务中，这样您就只能看到这两个，或者两者都不能。
就安全性而言，Cassandra会在其执行任何其他操作之前将所有写入内容存储在提交日志中，就像关系数据库使用事务日志一样。因此，就系统崩溃而言，它同样安全。关于节点故障，如果您在CL.ALL处写入，那么只要每个副本集中的一个节点存活，您就永远不会丢失数据。关于磁盘故障，这是您的底层硬件设置的问题，例如RAID。