在【Redis深度学习系列 二】 基本概念这篇博客的开始我简单介绍了下NoSQL的基本概念和使用场景，也比较了几种NoSQL数据库，这里再次重温下Web2.0 三个需要解决的问题：
- High performance - 高并发读写，在web2.0时代，需要依据用户个性化需要高并发读写，关系型数据库读还可以，写就很难做到了。例如论坛这样的站点， 网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈
- Huge Storage - 海量数据的高效率存储和访问，海量数据高效率存储和访问， 网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的，类似facebook这样的社交网站、社区。
- High Scalability && High Availability - 高可拓展性和高可用性， 在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。
为解决这些问题而使用的一些数据库常用的两种和它们的应用场景：
| 产品 | 存储方式 | 典型应用 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| Redis | 键值（key-value） | 内容缓存，主要用于处理大量数据的高访问负载 | 一系列键值对 | 快速查询 | 存储的数据缺少结构化 |
| Cassandra | 列存储数据库 | 分布式的文件系统 | 以列模式存储，将同一列数据存在一起 | 查找速度快，可扩展性强，更容易进行分布式扩展 | 功能相对局限 |
| MongoDB | 文档型数据库 | Web应用（与Key-value）类似，Value是结构化的 | 一系列键值对 | 数据结构要求不严格 | 查询性能不高，而且缺乏统一查询语法 |
从以上表格可以发现二者的适用场景：Redis更适合做缓存，而Cassandra更适合做可扩展性的业务数据库，MongoDB则更重一些，介于关系型和非关系型数据库之间，解决的web2.0时代的问题分别为高并发读写、高扩展性、高可用性和海量数据的高效率存储和访问。就效率而言，Cassandra的写操作较MongoDB强一些而且可扩展性更强，所以感觉更适合做业务数据库。同【Kafka从入门到放弃系列 一】概述及基本架构的学习和写作模式类似，对于Cassandra的学习分为如下几部分：
- 【Cassandra从入门到放弃系列 一】概述及基本架构：Cassandra的基本特点和基本架构
- 【Cassandra从入门到放弃系列 二】基本原理和机制解析：Cassandra的基本原理，详细的机制解读。
- 【Cassandra从入门到放弃系列 三】数据模型及查询语句：Cassandra的数据模型和查询语言CQL。
- 【Cassandra从入门到放弃系列 四】安装、配置和运行：Cassandra的安装、配置和运行。
本篇博客是Cassandra系列的第一篇，旨在解答问题的why和when，也就是为什么需要用kafka和什么时候用kafka，again：至于为何是从入门到放弃系列，因为俺相信，框架总会过时，总有更优秀的会出现，重要的是思想，所以这里的放弃是脱离框架而探寻框架的实现原理和思想，这个相较而言更重要吧（但是你无论如何还是需要通过一个中间件的学习去了解设计原理和思想的，这也是浅尝辄止学习的意义）。
Apache Cassandra是一个开源的、分布式、无中心、弹性可扩展、高可用、容错、一致性可调、面向列的数据库，它基于Amazon Dynamo的分布式设计和Google BigTable的数据库。用于处理大量商用服务器上的大量数据，提供高可用性，无单点故障。所以使用Cassandra的场景大多是进行海量业务数据的存储和分布式数据的扩展存储，但是读的性能差一些，所以搭配ElasticSearch进行快速查询和读取感觉就是不错的一个组合了。
在写作过程中参照了部分w3c内容： https://www.w3cschool.cn/cassandra/cassandra_architecture.html
Cassandra基本特点
在学习之前，先了解下Cassandra有哪些特点，并且根据这些特点给出我一些简单的理解，之后再通过原理探究讨论为何Cassandra具备这些特点：
- 弹性可扩展性 - Cassandra是高度可扩展的; 它允许添加更多的硬件以适应更多的客户和更多的数据根据要求。这个应该是Cassandra最值得骄傲的一个特性了，待之后探究下他是怎么实现的
- 始终基于架构 - Cassandra没有单点故障，它可以连续用于不能承担故障的关键业务应用程序。热修复，无坏点，再辣鸡的硬件服务器也可以扛？
- 快速线性性能 - Cassandra是线性可扩展性的，即它为你增加集群中的节点数量增加你的吞吐量。因此，保持一个快速的响应时间（Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，可以增加动态添加节点即可。不必重启任何进程，改变应用查询，或手动迁移任何数据。）。
- 灵活的数据存储 - Cassandra适应所有可能的数据格式，包括：结构化，半结构化和非结构化。它可以根据您的需要动态地适应变化的数据结构。
- 便捷的数据分发 - Cassandra通过在多个数据中心之间复制数据，可以灵活地在需要时分发数据。
- 事务支持 - Cassandra支持属性，如原子性，一致性，隔离和持久性（ACID）。这里的一些ACID估计不是很稳定的，例如一致性Cassandra只支持最终一致性，副本同步还需要时间
- 快速写入 - Cassandra 执行快速写入，并可以存储数百TB的数据，而不牺牲读取效率。
综合而言，最牛的特性应该就是高可扩展，高可用，容易部署（增加服务器节点很简单），数据写入性能强。读取性能一般（但可以通过查询工具弥补（ElasticSearch））。
Cassandra基本架构
在Cassandra中，集群中的一个或多个节点充当给定数据片段的副本（P2P模式而非Master-Slave模式）。如果检测到一些节点以过期值响应，Cassandra将向客户端返回最近的值。返回最新的值后，Cassandra在后台执行读修复以更新失效值。
基本术语表
在该集群中有很多组件，作用各不相同，执行流程和使用方式目前还不甚确定，先将术语表列出来看一下：
- 节点 - 它是存储数据的地方。
- Raker -一个逻辑集合，有多个彼此临近node的组成。比如一个机架上的所有物理机器。
- 数据中心 - 它是相关节点的集合（上图展示了一个数据中心）。
- 集群 - 集群是包含一个或多个数据中心的组件。
- 提交日志 - 提交日志是Cassandra中的崩溃恢复机制。每个写操作都写入提交日志。
- Mem-表 - mem-表是存储器驻留的数据结构。提交日志后，数据将被写入mem表。有时，对于单列族，将有多个mem表
- SSTable - 它是一个磁盘文件，当其内容达到阈值时，数据从mem表中刷新。
- 布隆过滤器 - 快速，非确定性的算法，用于测试元素是否是集合的成员。它是一种特殊的缓存。 每次查询后访问Bloom过滤器。
基本术语表的组件在下一篇使用流程和机制中再详细介绍下。
Gossip协议
Gossip是一种p2p协议,用于failure detection,跟踪其他节点的状态，每秒运行一次。运用Phi Accrual Failure Detection实现failure detection，计算出一个结果level of suspicion,表示节点失败的可能性。
使用Gossip协议，允许节点相互通信并检测集群中的任何故障节点。
总结
本篇博客主要是对Cassandra进行一个简单了解，其适用场景，和其它Nosql的区别，以及基本架构和防坏点机制，在下一篇博客里将会介绍Cassandra的详细执行机制和基本原理。
