5. 解决的问题 & 价值
① 随时在线
没有 master，多副本，具有可调一致性。比如挂了一台或者删掉一个副本，在一般的强制读模型下，是没有影响的。节点副本越多，冗余度越高，可接受的挂更多的节点。
无主从切换带来的抖动
② 线性扩展，易于运维
由于节点对等，可以进行线性扩展，因此非常易于运维。当集群扩展时，直接加一台机器就好了，绝大多数步骤都可以自动完成。因此很多公司都把商标做成一个环了，代表是可线性扩展的。
③ 多 DC，两地三中心
就近读写，大大降低延时。比如有个国际化的业务，在中国和国外皆有分布，比如 FB 的图片社交业务，国内和国外的用户都会发图片动态，我会关注国外朋友的图片动态，通过多 DC 可以就近读写，读的延时是很低的。
实现业务的多地容灾。比如某个地域发生地震，整个机房宕掉了，可以把业务的就近起一个 DC。
④ Cql + 丰富数据结构 + 类 jdbc driver
⑤ 完备的多语言客户端
有非常完备的多语言客户端，主流的语言都在里面，包括我们常用的 python、C++、Go、node JS、php 等日常使用比较多的语言。
6. 性能表现
这是外部的一些权威的性能披露。左侧图对比了 Cassandra、HBase、MongoDB 和 Conchbase 的性能表现，右侧是比较有名的一篇论文，对比了 Cassandra、HBase 和 Voldemort 在延时、吞吐化方面的表现，Cassandra 的延时表现是优于 HBase 的。
7. 使用场景
下面我们讲一下 Cassandra 的使用场景，这里我分享一下自己的看法，以及自己论文的一些最佳实践。
① 不适合用的场景：
Cassandra 是一种 NoSql 的解决方案，很多 TP 的场景是不适合使用的。
不适用于先读后写的操作。
和其他数据库不太一样的地方，Cassandra 是一种无主的，反言之即 Cassandra 是一种多主的。多主的意思就是多个节点都可以操作，并不是都转发到一个节点上。在一个节点上很容易加锁，只要对某一行加锁，对所有的请求保持串行就可以了。所以对于独立行写其实是有冲突的，在 Cassandra 里面解决冲突的办法是很暴力的，就是 last write win ( 最后写入者获胜 )，因此导致 Cassandra 不适合做先读后写的操作。对于这种场景，Cassandra 建议使用 cas 的语法，但 cas 的性能比较差，因此使用 cassandra 时要避免冲突很多的场景。什么是冲突很多呢？比如多个手机用户同时更新一条数据，就是强冲突的。
② 使用场景
风控领域：用户画像库、爬虫、发欺诈系统、订单数据
个性推荐领域：用户行为分析、用户画像、推荐引擎和海量实时数据处理
大数据
社交 Feeds
Instagram 的 Feeds 应用场景，与微博类似，大 V 会发图片和动态，同时一般也有很多的粉丝。当大 V 发图片或者动态，首先会有一个异步的推送 ( delivery )，把大 V 发布内容推到数据库里，然后粉丝读取大 V 动态的时候，再去拉取数据库的对应信息。比如川普有几千万的粉丝，对于每个粉丝都会去更新消息的 id，然后把信息写进来。对于每个粉丝，通过自己 id 查到对应的消息 id，再关联别的表查一下就可以获取到大 V 的动态。
这个例子充分利用了 Cassandra 的弹性扩展，一般传统的 sqlserver 只有单边节点，存储无论容量还是 ES 都是有限的。还使用了 Cassandra 的其他特性，比如 count 在 cassandra 里面都是分片计算的，效率非常高，因此点赞、计数这种场景做起来是没有压力的。
时空时序
现阶段 IOT ( 物联网 ) 是比较热门的，有各种可穿戴设备，比如手表电话之类，还有像滴滴这样的公司，都会把数据实时上传到在线的数据库里。一般可能会做一些初期的 ETL 转换，在这个例子中使用 kafka、消息队列，然后有可能发的是比较快的，慢慢地把并发起到 Cassandra 里面，基于 Spark，或者基于某些数据，数据不断上传，对旧数据进行定期归档，存到备用。这种场景的特点是客户端非常多，像滴滴有上万台车同时在线地写入非常多的数据，数据量并发非常大。Cassandra 有个特点，是一个 LSM 的存储模型，写入性能非常高，扩展能力是很强的，整体集群扩展能力很高，通过加节点就能作线性扩展。
本文转载自 DataFunTalk 公众平台。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论