Cassandra一致性问题及客户端解决方案

          数据一致性是分布式原理CAP的一个要素，在以往使用Mysql或Oracle时，几乎不用为一致性操心，而现在用到了Cassandra（目前使用了2.0.0版本），它保证的是数据的最终一致，导致在实际使用过程中出现了很多问题。

 

       很多问题的根源，就是在更新一条记录，如果马上查询，结果竟然还是旧数据，或者新插入条数据，在查询会发现结果为空。这就是最终一致性的特点，而解决这个问题，即实现强一致性，需要实现以下条件：(nodes_written + nodes_read) > replication_factor 。注：replication_factor 表示数据的复制份数，nodes_written 表示一次写需要同步的节点数，nodes_read表示一次读需要读取的节点数。

这都是在Datastax网站提及的。

 

       上面是理论基础，而在具体测试时，还是出了问题，3台服务器，读2份，写2分（2+2>3），按说应该可以实现强一致。

 

       在使用Hector测试时，无论如何修改读写份数，都无法实现强一致，放弃。

 

       后又改用Astyanax，使用的连接池策略为轮询（ConnectionPoolType.ROUND_ROBIN），发现了一个奇怪的规律：每三条记录只能出现一条更新成功的；然后根据这个规律，修改了代码，每个插入操作循环三次，再取出来后结果就是一致的。

       然后使用Cassandra自带的cql客户端，多次的修改同一记录，并且查询，发现结果是一致的。
通过查看日志，发现两种客户端请求产生的后台日志是相同的，但通过Astyanax客户端的请求会轮流发送到三个机器上，而Cassandra的cql客户端的请求只发送的一台机器上。于是想到jAstyanax是否有不同的请求策略，发现其提供了三种策略（TOKEN_AWARE，ROUND_ROBIN和BAG ），测试BAG方式，结果所有的同一主键的请求被发送到一台机器，查询结果是一致的，但连续更新大概3万次后，有出现了不一致，需要再研究一下，不过却是很大的改善了一致性。

      目前正在查看Cassandra的源码实现，努力找出问题根源。

评论

1 楼 yunnick 2014-03-12  

写了一篇总结文章，竟然没了。

以上问题的根源就是时间戳不一致造成的。

所以必须确认时间戳，误差控制在毫秒内