cassandra

本文源码： GitHub·点这里 || GitEE·点这里 一、Cassandra简介 1、基础描述 Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，此后，由于Cassandra良好的可扩展性，逐渐发展成为了一种流行的分布式结构化数据存储方案。 2、特点分析 弹性可扩展性 Cassandra是高度可扩展的;它允许添加更多的硬件以适应更多的客户和更多的数据根据要求，可以根据业务的数据流量轻松扩展集群规模。 架构特点 Cassandra可以基于分布式运行，并采用了许多容错机制。由于去中心化无主的策略，所以没有单点故障。可以做到不停服滚动升级。这是因为Cassandra可以支持多个节点的临时失效（取决于群集大小），对群集的整体性能影响可以忽略不计。并且Cassandra提供多地域容灾。Cassandra允许将数据复制到其他数据中心，并在多个地域保留多副本，十分适用于不能承担故障的关键业务，必须持续提供服务的应用程序。 数据存储机制 Cassandra适应所有可能的数据格式，包括：结构化，半结构化和非结构化。可以根据业务的需要动态地适应变化的数据结构，并且通过在多个数据中心之间复制数据，可以灵活地在需要时分发数据。有许多案例证明Cassandra可以在金融，医疗，物联网等领域使用。 资源整合能力

cassandra 简述 Apache Cassandra 是一种分布式非关系型数据库，具有高性能、可扩展、无中心化等特征。 一种column-based数据库。 Cassandra所支持的基本数据模型。这些基本数据模型有：Column，Super Column，Column Family以及Keyspace。 依赖 <dependency> <groupId>com.datastax.cassandra</groupId> <artifactId>cassandra-driver-core</artifactId> <version>3.4.0</version> </dependency> <dependency> <groupId>com.datastax.cassandra</groupId> <artifactId>cassandra-driver-extras</artifactId> <version>3.4.0</version> <optional>true</optional> </dependency> Java 查询 使用java 的客户端查询 cassandra 时，返回值结构解析比较麻烦,故此封装了一个工具。 根据返回值信息中的列的信息，生成列与类型的关系。 queryColumns（） 根据传入的Java Bean 返回 数据集。 /** *

前面介绍了事件源（EventSource）和集群（cluster），现在到了讨论CQRS的时候了。CQRS即读写分离模式，由独立的写方程序和读方程序组成，具体原理在以前的博客里介绍过了。akka-typed应该自然支持CQRS模式，最起码本身提供了对写方编程的支持，这点从EventSourcedBehavior 可以知道。akka-typed提供了新的EventSourcedBehavior-Actor，极大方便了对persistentActor的应用开发，但同时也给编程者造成了一些限制。如手工改变状态会更困难了、EventSourcedBehavior不支持多层式的persist，也就是说通过persist某些特定的event然后在event-handler程序里进行状态处理是不可能的了。我这里有个例子，是个购物车应用：当完成支付后需要取个快照(snapshot)，下面是这个snapshot的代码： snapshotWhen { (state,evt,seqNr) => CommandHandler.takeSnapshot(state,evt,seqNr) } ... def takeSnapshot(state: Voucher, evt: Events.Action, lstSeqNr: Long)( implicit pid: PID) = { if (evt

Log-Structured Merge-Tree，简称 LSM。 以 Mysql、postgresql 为代表的传统 RDBMS 都是基于 b-tree 的 page-orented 存储引擎。现代计算机的最大处理瓶颈在磁盘的读写上，数据存储无法绕开磁盘的读写，纯内存型数据库除外，但由于内存存储的不稳定性，我们一般只将内存型的存储作为缓存系统。 为提升数据库系统的写性能，我们发现磁盘的 顺序写性能远远大于随机写性能 ，甚至性能高于内存的随机写。所以在很多偏向写性能的数据库系统中，以牺牲一部分读性能和增大写放大的情况下引入了 LSM 数据结构。 设计一个数据库引擎 我们从头开始设计一个数据库引擎。数据模型很简单，我们选最简单的 Key-Value 结构，一条数据只有一个 Key 和一个 Value。操作只有 get 和 put，如下： get(key); put(key, value); 从最简单的开始，每个数据库一个 data.db 文件，我们像写日志一样，将每条记录 append 到文件结尾。 key1,value1 key2,value2 key3,value3 key10,value10 key8,value8 这样我们已经完成了 80%了，然后需要完成读功能。如上数据文件，若需要查询 key2 数据，我们只能从文件开头开始遍历，当直到读取到 key2 数据： for

前面介绍了事件源（EventSource）和集群（cluster），现在到了讨论CQRS的时候了。CQRS即读写分离模式，由独立的写方程序和读方程序组成，具体原理在以前的博客里介绍过了。akka-typed应该自然支持CQRS模式，最起码本身提供了对写方编程的支持，这点从EventSourcedBehavior 可以知道。akka-typed提供了新的EventSourcedBehavior-Actor，极大方便了对persistentActor的应用开发，但同时也给编程者造成了一些限制。如手工改变状态会更困难了、EventSourcedBehavior不支持多层式的persist，也就是说通过persist某些特定的event然后在event-handler程序里进行状态处理是不可能的了。我这里有个例子，是个购物车应用：当完成支付后需要取个快照(snapshot)，下面是这个snapshot的代码： snapshotWhen { (state,evt,seqNr) => CommandHandler.takeSnapshot(state,evt,seqNr) } ... def takeSnapshot(state: Voucher, evt: Events.Action, lstSeqNr: Long)( implicit pid: PID) = { if (evt

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 日志结构的合并树（log-structured merge-tree LSM 树）通常是在处理大量写任务时使用的数据结构。通过顺序写来优化写入路径。 LSM 树是许多数据库（包括 BigTable, Cassandra, Scylla,和 RocksDB）背后的核心数据结构。 排序字符串表 LSM 树使用排序字符串表（Sorted Strings Table 简称 SSTable）的格式保存到磁盘。如名称所示，SSTables 是一种用于存储键-值对的格式，其中键按有序排列。SSTable 将由多个名为段（Segments）的有序文件组成。一旦将这些数据段写入磁盘后，就是不可变的。简化示例如下： 我们可以看到，每个段中的键-值对都是按键排序的。接下来看看什么是片段以及它是如何生成的。 写数据 回想一下，LSM 树只执行顺序写入。我们可能想知道，当值以任意顺序写入时，如何以有序格式的顺序写入数据？这可以通过使用内存中的树结构来解决。通常被称为内存表（memtable），但底层数据结构通常是某种形式的排序树，如红黑树。当写入数据时，将添加到此红黑树中。 我们的写入将存储在这个红黑树中，直到树达到预定义的大小。一旦红黑树有足够的条目，它就会按有序的顺序作为磁盘上的一个段刷新到磁盘

Python 为啥这么火，这么多人学，就是因为简单好学，功能强大，整个社区非常活跃，资料很多。而且这语言涉及了方方面面，比如自动化测试，运维，爬虫，数据分析，机器学习，金融领域，后端开发，云计算，游戏开发都有涉及。 万丈高楼平地起，Python这座大厦能够如此强大，就是拥有强大的成千上万的库的支持，无数牛逼的轮子在支持这座大厦， 今天我们来一起梳理一下，俯瞰整个 Python 宝库。 大概列了一下整个Python库的应用的方法面面，粗略算算就有20几个方向。左右两边分两个方向，左边负责进攻(主外)，每一项单独拉出来都是精品，都是Python应用里面拳头产品；右边负责守(主内)，都是涉及底层的配置，算是整个大厦的地基。 下面我们挑选每个领域的的精品库，展现给大家，看完之后，你一定会大叫，卧槽，这么多库我都没有见过～～ Python大厦的底层基建 环境管理 管理 Python 版本和环境的工具 p：非常简单的交互式 python 版本管理工具。 pyenv：简单的 Python 版本管理工具。 Vex：可以在虚拟环境中执行命令。 virtualenv：创建独立 Python 环境的工具。 buildout：在隔离环境初始化后使用声明性配置管理。 包管理 管理包和依赖的工具。 pip：Python 包和依赖关系管理工具。 pip-tools：保证 Python 包依赖关系更新的一组工具。

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ Uber服务的高性能主要依赖于在当前平台上快速以及稳定的开发新特性能力，和对应服务使用什么技术栈无关。Uber平台最根本的能力是基于微服务架构，这是一种常用的结构化风格，也就是由各种互操作的服务组成的应用。 微服务架构可以提供很好的伸缩性，同时也能够支持稳定的部署和模块化。在Uber，不同的工程师团队都是基于互操作的服务来工作，所以确保我们的技术栈既要能够安全的发布新的变动，也要能够基于模块化方式可靠的使用架构的已有部分，这点非常重要。总而言之，这些功能能够提高开发者的开发速度以及快速的发布周转（turnaround）次数，另外还可以给我们提供基于独立调度（schedules）构建的灵活性，同时依然可以满足服务级别协议（SLAs）。 在一个微服务架构中允许多系统共存是利用微服务稳定性以及模块化最有效的方式之一，这种方式一般被称为多租户（multi-tenancy）。租户可以是测试，金丝雀发布，影子系统（shadow systems），甚至服务层或者产品线，使用租户能够保证代码的隔离性并且能够基于流量租户做路由决策。对于传输中的数据（data-in-flight）（例如，消息队列中的请求或者消息）以及静态数据（data-at-rest）（例如，存储或者持久化缓存）

1. zipkin基础介绍: 分布式追踪系统 概念： tranceID: 请求全局处理标识 spanID: 请求在单个服务流转处理标识 ParentID: 子服务中显示父服务ID(spanID)，主要用于构建服务调用链路 数据传输到Zipkin方式： http kafka Scribe Zipkin构成组件： collector: zipkin校验、保存、索引接收的追踪数据 storage: zipkin 数据存储（Cassandra、mysql、ES、内存等，支持扩展） search: zipkin 数据检索服务（WEB UI） WEB UI: 数据追踪展示UI,默认没有认证 2. 环境部署 参考官网下载： zipkin quickstart 3. 使用案例 3.1 maven 依赖引入 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter