Cassandra集群部署规划
国内关于Cassandra的比较详细的资料还是太少，以下是根据国外的一些资料翻译总结的内容，大家有需要可以参考参考！还没写完，我会边写边上传！Cassandra集群部署规划
在规划正式生产环境中的Cassandra集群部署时，首先必须考虑计划存储的数据量，以及前端主要应用系统常态情况及极值情况下的负载(读/写)压力。
硬件选择：
对任何应用系统而言，合理的硬件资源选择往往意味着在内存、CPU、硬盘、网络这4项基础资源中通盘考虑并获取一个最佳的配置平衡。
内存：
Cassandra节点拥有越多的内存，集群的读取性能越优秀。更多的内存允许更大的缓存大小,同时也能减少磁盘I / O读。更多的内存也允许设置更大的内存表(memtables)来存储最近的读取的数据，这将有效减少在一次读过程中扫描及读取的文件（索引文件、SSTable文件等）。在正式生产环境中单节点采用8GB~16GB是普遍现象，建议最低不低于4GB内存，目前有部分生产集群采用32GB或更高的内存配置。理想的内存配置往往取决于频繁读取中的数据流大小。
CPU：
在实际应用Cassandra集群的系统中，“写频繁”的应用往往在达到内存的处理极限之前其CPU已经不堪重负了。Cassandra的高并发特性决定了其将直接受益于更多的处理器数量。目前，拥有8个CPU内核的节点通常能提供最好的性价比。而在虚拟服务平台上，我们可以考虑使用云服务提供商，他们往往拥有密度更高的处理器单元，能提供更强大的处理能力。（比如纽约时报就租用亚马逊的云服务平台来处理所有历史报纸的扫描件的解析存储工作）。
硬盘：
选择硬盘的两个重要依据是：容量（有多少数据要存储）及I/O（读写吞吐率）。存储方面的优化将有效减少昂贵的SATA硬盘数量，并能够通过扩展节点来增强集群的存储能力及I/O性能（当然这往往也意味着更多的内存投入）。
固态硬盘（SSDs）也是Cassandra集群的一个有效替代选择。基于SSDs，并配合Cassandra的“顺序流”的写模式将能极大降低对写入效率的不良影响。
Cassandra通过两个操作将数据持久化到硬盘中：它首先先将“写入数据”附加到内存中的Commit Log中，并周期性的将内存中的数据顺序刷新到硬盘，写入SSTable（列簇数据的存储文件）中。强烈推荐为CommitLog和SSTables文件采用不同的磁盘存储。CommitLog并不需要太多的存储空间，但其能有有效平衡你的写入负载压力。数据目录不仅要满足存储持久数据的要求，同时也要有足够的吞吐率以满足可以意料到的数据“读取”压力、数据“写入”和压缩的I/O需求。
Cassandra在运行后台的数据压缩及数据修复操作时，硬盘利用率往往会临时增长到实际数据目录容积的2倍多。因此，建议在每个节点中实际使用的容量不要超过磁盘最大容量的50%。
同时考虑磁盘故障影响及数据冗余需求，有两个合适的搭配方式：
[*]存储采用RAID0，通过Cassandra的数据备份机制来解决硬盘故障的影响。一旦某个节点的磁盘出现故障，我们可以通过Cassandra的修复操作来自动找回失去的数据。
[*]存储采用RAID10，这样可以通过纯粹硬件上的水平扩展来解决单个磁盘的故障，这样可以关闭Cassandra的自动备份操作。
如果在磁盘存储方面由足够的投资，推荐采用RAID10，这样可以减少Cassandra副本备份策略所带来的额外存储操作，减少网络负载。反之，则推荐采用RAID0。
网络：
Cassandra是一个分布式数据存储平台，它基于网络来处理读/写请求，同时通过网络来进行节点间的数据备份。Cassandra对副本数据的选择策略是，同机架上节点的优先于不同机架上的节点。同个数据中心的节点优于不同数据中心的节点。
Cassandra使用如下端口，在实际生产环境中如果存在防火墙，必须确保同一集群中的节点可以通过这些端口互相访问。
端口号
描述
7000
Cassandra内部节点间的通信端口
9160
Thrift客户端访问端口
7199
JMX的监控端口（早期版本是8080）
页:
[1]