cassandra集群要求严格的时间同步,有一点同步就会发生这样那样的问题,这个事情我已经在cassandra集群要求严格的时间同步里说明了,所以时间同步是cassandra集群的前提。
cassandra使用的是最后一致性模型,也就是说一开始的并发更新的数据可能是不一致的,但是经过这段不一致的时间之后,系统会达到最终的一致性。让每个客户端看到的结果是一样的。
这个最终一致性的强度,在cassandra中是有你所选的一致性模型决定的。通常使用cassandra,我们选择QUORUM级别,表示有半数副本收到请求的时候,返回客户端响应,这样保证插入的数据,可以肯定被查询到。然而这里存在一个问题,关于并发性,假设客户端对同一条记录进行更新,cassandra是根据什么判断请求的先后呢?只有时间,cassandra会根据请求到达服务器的先后时间。例如:
QueryOptions options = new QueryOptions(); options.setConsistencyLevel(ConsistencyLevel.QUORUM); Cluster cluster = Cluster.builder() .addContactPoint("192.168.1.101") .withCredentials("cassandra", "cassandra") .withQueryOptions(options) .build(); Session session = cluster.connect(); RegularStatement update10 = QueryBuilder.update("myKeysapce","tableName") .with(QueryBuilder.set("col2", 10)) .where(QueryBuilder.eq("key1", 1)); session.execute(update10); RegularStatement update20 = QueryBuilder.update("myKeysapce","tableName") .with(QueryBuilder.set("col2", 20)) .where(QueryBuilder.eq("key1", 1)); session.execute(update20);
但是cassandra集群有多台机器,客户端发到服务器的不同机器上呢?糟了,数据乱掉了。是的,当你使用datastax的驱动程序的时候,你会发现快速对同一条记录进行两次更新,最终的结果有时候并不是第二个请求更新的结果,就像上面的例子,每次更新结果可能是20,也可能是10。即便你的一致性级别选择的ALL,也有可能发生这样的情况。因为两次请求的时间间隔实在很短,而集群的所有机器又不能完全时间同步,即便是使用了ntp同步,时间差也会在ms级别,两次请求发到不同的机器上,就会发生这样的问题。
怎么办呢?当我们换用另外一个cassandra客户端Astyana的时候,我们发现并不会发生上面描述的情况,这是为什么呢?难道客户端有问题,经过调查发现,Astyanax客户端发的两次请求都是发到了集群的同一个节点,而datastax官方驱动客户端,却是发向了不同的节点。
原来Astyanax客户端有一个请求策略的概念,它有三种策略(TOKEN_AWARE,ROUND_ROBIN和BAG),其中TOKEN_AWARE就是根据主键token请求到相同的客户端。
那原生的datastax客户端有没有这样的概念呢?调查后发现也是有的,它叫做LoadBalancingPolicy,可以通过 Cluster.builder().withLoadBalancingPolicy(policy)指定,它也有三个策略,分别是:
DCAwareRoundRobinPolicy
RoundRobinPolicy
TokenAwarePolicy
其中TokenAwarePolicy就是根据token把对同一条记录的请求,发到同一个节点,看代码我们发现datastax默认使用的策略就是TokenAwarePolicy,那为什么没有和Astyana一样的效果呢?
通过阅读它的代码,原因找到了,那就是在更新的时候,要给它指定表的tablemetadata,否则datastatx无法知道哪些字段是主键,额,貌似这个客户端也太傻了。。。
上面的例子改成下面这样,就万事大吉了。
TableMetadata metaData = cluster.getMetadata().getKeyspace("myKeyspace").getTable("tableName"); RegularStatement update10 = QueryBuilder.update(metaData) .with(QueryBuilder.set("col2", 10)) .where(QueryBuilder.eq("key1", 1));
相关推荐
- **Manual Repair**:用户可以手动触发修复过程,检查并修复集群中的数据不一致性。 1. **不一致性产生的原因** - **并发写入**:多个写请求可能导致某些节点未能成功写入,导致读取旧数据。 - **节点故障**:...
- **环形拓扑**:Cassandra集群采用环形结构,每个节点都有一个连续的令牌范围,负责存储相应范围内的数据。 - **一致性级别(Consistency Level)**:用户可以根据需求设置读写操作的一致性级别,平衡数据一致性...
它使用一致性哈希来分发数据,并且支持多数据中心部署,确保低延迟的数据访问。 2. **Spark简介**:Apache Spark是为大规模数据处理设计的开源计算框架,它提供了基于内存的计算,显著提高了数据处理速度。Spark...
- 数据一致性问题是Cassandra常见的问题之一。`nodetool repair`是一个用于修复数据不一致的工具,通过比较不同节点的数据并进行同步来保证一致性。 - 在大规模集群中,智能的修复策略和自动化修复工具是必要的,...
由于分布式系统可能出现数据不一致,Cassandra提供了反熵(Anti-Entropy)机制,定期进行数据修复以保持数据一致性。数据修复可以手动触发,也可以设置为定时任务。 ### 8. 灾备与恢复 为了应对灾难情况,...
6. **网络隔离**:模拟网络故障,如节点间通信中断,用于测试故障恢复和数据一致性。 7. **销毁集群**:测试完成后,可以快速清理所有资源,释放系统资源。 Python-CCM 的使用方法: 首先,你需要安装 CCM。通常...
总而言之,这份关于Cassandra 3.0的文档涵盖了从基础概念、系统架构、数据一致性、存储引擎到具体部署和运维的全面介绍。文档内容详实,对于想要深入学习和使用Cassandra的开发者和系统管理员来说,是一份非常有价值...
Cassandra作为一款开源的分布式NoSQL数据库系统,以其高可扩展性、高性能和强大的数据一致性而著称,被广泛应用于处理大量结构化和半结构化数据的场景中。 ### 关键知识点一:Cassandra架构原理 Cassandra采用了一...
4. **一致性级别**:Cassandra提供了多种一致性级别,如QUORUM、ONE、EACH_QUORUM等,允许在读写速度和数据一致性之间进行权衡。用户可以根据应用需求选择适合的一致性策略。 5. **动态扩展**:Cassandra的节点可以...
- **最终一致性**:虽然牺牲了一定的一致性,但Cassandra保证在没有新的写入操作时,数据最终会达到一致状态,这在大多数互联网应用场景中是足够有效的。 - **列表数据结构**:Cassandra支持复杂的列族结构,包括...
- **存储机制**:Cassandra采用隐式传送(Hinted Handoff)机制处理节点间的数据同步,即使在网络分区或节点故障的情况下,也能保证数据的最终一致性。 - **数据读写操作**:写入操作会自动复制到其他节点,而读取...
5. **写一致性增强**:通过改进Hinted Handoff机制,Cassandra 1.0在写入一致性方面实现了显著提升。新的机制降低了临时存储Hint data的节点负载,同时消除了失效检测中的时间窗口问题,从而提高了数据写入的成功率...
通过灵活的数据模型、复制策略和一致性控制,Cassandra能够满足各种复杂业务的需求。然而,其最终一致性的特性可能不适合那些需要严格一致性的应用,因此在选择Cassandra时,需要根据具体业务场景进行权衡。
- **数据修复**:Cassandra提供了工具如`nodetool repair`来修复数据一致性问题,shell脚本可能会集成此功能。 3. **Crontab 定时任务**: - **计划任务**:Cassandra的监控和修复任务可以通过Linux的crontab服务...
4. **性能监控**:DevCenter能够监控Cassandra集群的性能指标,如读写速率、延迟、节点状态等,帮助用户识别潜在的问题并优化系统性能。 5. **版本控制**:通过DevCenter,用户可以跟踪和管理Cassandra模式的版本。...
在3.11.13版本中,Cassandra继续优化了这一特性,确保在大规模分布式环境下的数据一致性和服务稳定性。 3. **Gossip 协议**:Cassandra 使用 Gossip 协议进行节点间通信,每个节点都会周期性地与其他节点交换状态...
3. **数据比对**:通过接口比较Cassandra和MySQL中的数据,确保数据一致性。 4. **开启双写**:在数据比对无误后,开启双写,同时更新Cassandra和MySQL。 5. **切MySQL读**:逐步切换服务,从Cassandra读切换到MySQL...
在实际应用中,饿了么可能遇到了诸多挑战,如数据一致性、系统扩展性、以及故障恢复等问题,通过使用Cassandra,饿了么可能已经找到了有效的解决方案。此外,对于Cassandra与大数据技术的整合,文章可能会详细讨论...
6. **事务支持**:尽管Cassandra本身不完全支持ACID事务,但Cassandra JDBC Driver提供了一种方式来处理原子性和一致性,使得在一定程度上可以在Cassandra上实现事务操作。 7. **异常处理**:当发生错误时,...