Cassandra是一款分布式的去中心化的数据库，她脱胎于Dynamo以及bigtable，吸收了二者的架构以及数据模型在开源社区的孵化下达到今天这么一个程度。CAP理论中她更强调AP两点，当然C的属性也是可调的，C 和A 这2块在Cassandra身上可以看到一个权衡的存在。本文会从以下几个方面去介绍Cassandra相关知识：
- 基本架构
- 部署运维
- 使用方法
一：基本架构
Cassandra可以有多dc的部署方案，且也有适合在云环境下的部署方案，从复杂的snitch到simple的snitch。不同的环境有不同的部署方式，如果你希望你的cluster下面都是在一个dc，可以使用simple snitch，如果想要有更复杂的rack 以及dc方案，配合network的拓扑，可以组合成比较合适的一套多dc的架构。当然也有适合云上很亲和性的snitch。这里以及简单的simple snitch策略进行介绍。
下面是Cassandra的单DC下的基本架构，其中集群各个节点的conf配置文件里面会配置该节点的partitioner策略，这个策略主要用来计算用户指定的key 以何种hash计算方式计算为一个确定的hash值；其中partitioner策略有4种，分别是：
Murmur3Partitioner;
RandomPartitioner;
ByteOrderedPartitioner;
OrderPreservingPartitioner;各个partitioner分别表示不同的，分别表示不同的hash计算方式，当一条key来到Cassandra的集群中，被计算成对应的hash值，并按照该值路由到key的归属节点。比如pkey 经过A节点的计算得到DKeyA,然后路由到从属的primary 节点B，以及副本节点C,D (假设副本数3，摆放策略simple)。
现阶段一个节点负责的hash范围也是有2种配置方式，一种是一个节点分配一个token，这样每个节点按照顺序就可以负责一定的范围，但是这样需要预先平均的计算好各个节点分配的token值；还有一种就是vnode的方式，一个节点分配特定个的token_num，这样在最初加入集群的时候就会计算好相关的vnode。无论哪种方式，给的建议都是要保证每个节点负责的range区间量一致，不然会出现某些节点读写比较频繁，达不到均衡的效果。当然每种方式也有各自的优缺点。
Cassandra在建keyspace的时候会需要设置副本数，基于keyspace下面的所有的table都是有对应的副本，副本的摆放策略也是基于我们设置的策略进行摆放。此外，在读写的时候需要人为的设置一个Consistencylevel的这个参数，大概的Consistencylevel包括下面几个方面：
LEVEL:
- ONE:只需要一个副本响应即可；
- TWO:需要2个副本给出响应；
- THREE:需要3个副本给出响应；
- QUORUM:需要大多数（副本数/2 + 1）副本响应；
- ALL:需要所有副本响应；
- LOCAL_QUORUM:只需要本地DC下的大多数副本响应；
- EACH_QUORUM:每个DC下都需要有大多数副本响应；
- LOCAL_ONE:只需要一个副本响应即可；
- ANY: 写操作，一个副本响应，或者proxy节点可以记一个hint；读的操作，等一个副本响应；
当我们的请求落到对应的数据节点上以后，在数据节点上由以下几个组件组成我们单机的引擎：
- Commitlog
- Memtable
- Row/Key Cache
- BloomFilter
- Sstable (与之相关的有很多物理文件)
至于具体的细节后续会介绍。
二：部署运维
因为cassandra的部署很简单，只需要一个进程就可以搞定，此外社区也有一些相关的工具支持管理运维。所以整体下来部署还是相对的方便简洁，编译完对应的代码，修改conf下面的yaml文件里的相关配置，其中比较重要的几个就是
- Cluster_name：给你的集群起个名字；
- Num_token，这个参数和initial_token要做好配合选择；
- Parititoner:决定了你的集群以何种方式计算hash key；
- Data_file_directories:虽然在配置里是被注释掉的，但是生产下还是建议自己好好配置下，毕竟还是会影响你的性能；
- Commitlog_directory: commitlog 的位置，建议和数据盘分开；
- Seed_provider:seed 节点的信息；
当然，还有别的东西会影响你的集群的性能，比如cache的配置，认证的配置，log 刷盘的配置，读写处理现场池大小等等配置，暂不一一列举，后面会有单独文章介绍配置调优。
当配置完上述文件以后，我们在bin目录下面启动下cassandra这个可执行文件即可，当然我建议自己可以再写一个start的脚本，在脚本里面可以做一些进程nice值调整等事情；
当你nodetool 执行下status命令可以看到节点的状态是UN，表示各个节点都up了。列如我下面部署了4个物理节点的集群：
当然，也可以按照自己需要进行rack的部署，dc的部署等，这里只是演示下情况；
三：使用方法
可以使用cassandra自己自带的Cql shell进行一些基本的操作，当然cassandra的官方也推荐了一下driver进行基本的数据操作，见这里，通过这些软件，我们可以很方便的操作读写cassandra的集群，除此之外cassandra还为我们提供了一些运维管理的工具，比如所有对集群节点的操作可以再bin下面通过nodetool脚本进行执行：
nodetool cleanup:清理不属于本节点的key
nodetool compact:执行major compaction
nodetool decommission:decommission掉链接的这个节点
nodetool drain:drain掉这个节点
nodetool flush:对一个/多个table执行flush操作
nodetool info:输出节点的信息
nodetool repair:执行repair操作
nodetool status:输出集群状态信息
nodetool tablestats:输出表信息
下面是我们的社区，可以到我们的社区咨询，讨论相关问题：
微信群：
钉钉：
