问题与文章中的“CAS操作”段落有关：http://www.datastax.com/dev/blog/cassandra-error-handling-done-right
A）
如果paxos阶段失败，驱动程序将抛出WriteTimeoutException，其中WriteType.CAS与WriteTimeoutException＃getWriteType（）一起检索。在这种情况下，您无法知道CAS操作是否已应用..
你怎么理解这个？
我认为如果paxos（准备）阶段失败，那么协调员根本不会启动提交阶段？ 我想paxos阶段失败并不重要（没有足够的副本或副本超时或......）。
b）中
提交阶段类似于常规的Cassandra写入...如果确保在此事务触及的列上的后续读取语句中使用setConsistencyLevel（ConsistencyLevel.SERIAL），则可以简单地忽略此错误，因为它将在继续读取
之前，强制Cassandra提交任何剩余未提交的Paxos状态
想知道上面与ConsistencyLevel.QUORUM写的关系：
如果提交阶段失败，因为没有仲裁（不可用的节点或超时），那么我们得到WriteType为SIMPLE的WriteTimeoutException，对吧？ 在这种情况下，不清楚写入是否真的成功，对吧？ 所以我不确定从现在开始的所有可能性（恢复/回滚/没有）？
是不是说如果我使用ConsistencyLevel.QUORUM进行读取操作，我可以看到旧的数据版本（好像上面写的不成功）一段时间后再用QUORUM读取后我会看到写的成功了吗？ （实际上我在一个3节点集群中看到了这一点，在WriteTimeoutException之后复制因子= 3（需要2个副本，但只有1个确认写入） - 在返回旧数据之后读取仲裁，然后当我用cqlsh检查时看新数据。）
这怎么可能？ 猜测： 可能在超时之后，协调器表示我们没有提交阶段尚未的法定人数（以及后续的QUORUM读取获取较旧的数据版本）并将WriteTimeoutException.type = SIMPLE返回给客户端。当具有超时的节点实际响应/提交时，我们在此未来时刻具有仲裁，并且在此之后所有仲裁读取将获得更新的数据版本。 但不确定何时使用SERIAL进行读取的解释。