Cassandra节点无法相互通信，导致读取超时

这在Datastax Cassandra（dse）版本上：4.8.5-1
这相当于（我相信）卡桑德拉：2.1.x

在从应用程序进行查询时，我遇到许多以下错误：

ReadTimeout:code=1200[协调器节点在等待副本节点的响应时超时]message=“操作超时-仅接收到0个响应。”info={'received_responses'：0，'data_retrieved'：False，'required_responses'：1，'consistency'：1}

更深入地挖掘这一点；示例查询（在每个节点上本地使用cqlsh运行）在环中的3个节点上返回，但在其余节点上失败，导致ReadTimeout。似乎只有包含副本的节点返回响应，而其他节点根本不知道如何找到它们

是否有一些配置或已知问题需要我来解决

当其他节点出现故障时，我在日志中看到此错误：

ERROR [MessagingService-Outgoing-/10.0.10.14] 2016-04-25 20:46:46,818  CassandraDaemon.java:229 - Exception in thread Thread[MessagingService-Outgoing-/10.0.10.14,5,
main]
java.lang.AssertionError: 371205
        at org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:290) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:393) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.composites.AbstractCType$Serializer.serialize(AbstractCType.java:382) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:271) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.filter.ColumnSlice$Serializer.serialize(ColumnSlice.java:259) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:503) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.filter.SliceQueryFilter$Serializer.serialize(SliceQueryFilter.java:490) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.SliceFromReadCommandSerializer.serialize(SliceFromReadCommand.java:168) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:143) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.db.ReadCommandSerializer.serialize(ReadCommand.java:132) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:121) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:330) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:282) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]
        at org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:218) ~[cassandra-all-2.1.13.1131.jar:2.1.13.1131]

Nodetool状态输出

Datacenter: primary
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens  Owns    Host ID                               Rack
UN  10.0.10.224  557.95 GB  1       ?       d1b984b0-50d4-4faa-b349-08bc0cf36447  RAC1
UN  10.0.10.225  740.11 GB  1       ?       16ab3c8c-476e-46c2-837c-6dbb89b7d40d  RAC1
UN  10.0.10.12   748.23 GB  1       ?       4127f0d7-6bd0-4dc8-b6a0-3b261e55b44e  RAC1
UN  10.0.10.45   629.27 GB  1       ?       f4499c5d-f892-43b8-97f3-dcce5be51fb8  RAC2
UN  10.0.10.13   592.57 GB  1       ?       41b58044-942d-4e77-a8de-95495b88a073  RAC1
UN  10.0.10.14   616.45 GB  1       ?       d2b568fb-13e1-4ff7-a247-3751a8ca49cf  RAC1
UN  10.0.10.15   623.23 GB  1       ?       fb10e521-8359-409b-bfd8-b27829157a80  RAC1
UN  10.0.10.21   538.56 GB  1       ?       72288b4c-bd1d-4398-9d95-5af312c2f904  RAC2
UN  10.0.10.25   616.63 GB  1       ?       4a8f04ff-a198-44d1-baf4-72cc430cd8a9  RAC2
UN  10.0.10.218  562.98 GB  1       ?       c00c375d-90bb-48c5-a8d0-7102a13db468  RAC2
UN  10.0.10.219  632.58 GB  1       ?       1e2ea144-35bd-412b-89b5-41544a347a75  RAC2
UN  10.0.10.220  746.85 GB  1       ?       d40f59c1-430a-4d96-9d7e-1e846b8eb1fc  RAC2
UN  10.0.10.221  575.89 GB  1       ?       7e407d6b-2bd5-43b4-9116-96ee72a926b2  RAC2
UN  10.0.10.222  639.98 GB  1       ?       bfd04ab8-7679-4474-8d47-984950bdd2c7  RAC1
UN  10.0.10.223  652.58 GB  1       ?       6366cd3e-7910-40bb-8a12-926c53adf95b  RAC1

此断言的代码如下所示：

• 查看

  system.local

  或

  system.peers

  表时，没有明显的模式不匹配

• nodetool descripebCluster

  从某些节点返回

  无法访问的
  

---

1。检查您的复制系数。 2.检查不同的一致性级别。

---

3.最可能出错的配置是，每个节点只提供一个令牌。如果每个节点有256个令牌，则cassandra会将负载分配给每个节点
您可能达到了64K最大密钥大小限制，
查找您的应用程序代码，可能有人发送cassandra 371205字节长的数据作为主键，可能有人试图破解您的应用程序我不知道，因为作为主键的370k数据极不可能是合理的，请在您的应用程序代码中限制这一点

---

我不知道这方面是否存在任何错误、修复或解决方法。
您能否共享nodetool status的结果，以查看所有环是否正确查看集群？查看所有节点上的结果是否一致。@AlecCollier Addedy您在每个查询和每个表中都看到了这一点吗？如果您创建一个品牌的键空间/表并进行查询，会发生什么情况。@phact创建一个新的键空间/表是有效的——尽管它抱怨在提问和调试更多问题之间检测到“架构版本不匹配”，但我发现一段应用程序代码试图插入一个长得离谱的键，谢谢您的回答！