共计 1149 个字符，预计需要花费 3 分钟才能阅读完成。
背景介绍
在对某个表做 count 时出现如下错误(在做业务性测试，生产环境请不要简单粗暴做 count 操作，耗时还可能不准)
Cassandra timeout during read query at consistency LOCAL_ONE (1 responses were required but only 0 replica responded)
很奇怪，另外一个表应该是跟他相同条数的，都能直接 count 出来，但是当前表 count 一直报错，而且数据还差 2 两条(跟 ES 里面的数据对比后得知)
问题查找
在网上可以直接查询相关问题，结果也出来了很多。其中我给出几个具有参考性的链接
- 【stackoverflow】Cassandra timeout during read query at consistency LOCAL_ONE
- 【datastax】ReadTimeoutException seen when using the java driver caused by excessive tombstones
- 【datastax】Message seen in logs “Maximum memory usage reached (512.000MiB), cannot allocate chunk of 1.000MiB”
其中第一个链接其实已经反映了我这次的问题，但是我第一眼看到这个答案并没有感觉到确切符合我当前的问题，然后后面看到第二个链接时，明白了去哪儿看日志。
在 cassandra system.log 看到了 count 产生的日志，虽然不是第二个链接那样出现明显的 ERROR，但是看到了出现问题的提示
INFO [ReadStage-18] 2019-07-08 23:02:30,820 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576然后再第三个链接中就是跟我同样问题. 连接里面说的很清楚了，但是我还是在我这里记录下。
原因
做 count 操作操作时，就跟其他读操作一样，需要将数据加载到缓存中。数据来源包括 SSTables，tombstone 标记，这些数据都放在缓存中。
缓存的大小由 cassandra.yaml 中的 file_cache_size_in_mb设置控制。默认大小为 512 MB
count 出问题这张表是因为有一个字段存了很长的文本内容，count 整个表时，将所有数据 (完整的每行数据) 加载到内存就导致内存不足。
解决
将 file_cache_size_in_mb 设置成 1024 后，重启 count，统计成功
附
当然也很有可能不是你某个字段放了很大的信息，但是还是出现超时，那么可能是因为你 SSTables 太多，或者 tombstone 太多都会导致查询耗时而出现超时
