anzhsoft的技术专栏

对于一个大型的软件系统来说，它会有很多的组件或者说模块或者说子系统或者（subsystem or Component or submodule）。那么这些模块的如何通信？这和传统的IPC有很大的区别。传统的IPC很多都是在单一系统上的，模块耦合性很大，不适合扩展（Scalability）；如果使用socket那么不同的模块的确可以部署到不同的机器上，但是还是有很多问题需要解决。比如： 1）信息的发送者和接收者如何维持这个连接，如果一方的连接中断，这期间的数据如何方式丢失？ 2）如何降低发送者和接收者的耦

最近我在做流式实时分布式计算系统的架构设计，而正好又要参见优快云博文大赛的决赛。本来想就写Spark源码分析的文章吧。但是又想毕竟是决赛，要拿出一些自己的干货出来，仅仅是源码分析貌似分量不够。因此，我将最近一直在做的系统架构的思路整理出来，形成此文。为什么要参考Storm和Spark，因为没有参照效果可能不会太好，尤其是对于Storm和Spark由了解的同学来说，可能通过对比，更能体会到每个具体实现背后的意义。本文对流式系统出现的背景，特点，数据HA，服务HA，节点间和计算逻辑间的消息传递，存储模型，

本周接手了一个Cassandra系统的维护工作，有一项是需要将应用方的数据导入我们维护的Cassandra集群，并且为应用方提供HTTP的方式访问服务。这是我第一次接触KV系统，原来只是走马观花似的看过KV啊，NoSQL啊。但是实际上没有实际的使用经验。经过两天的学习和接手，终于搞明白了在生产环境中的使用方式。在此简要的笔记一下。本文主要包括的内容有：Cassandra的简介，Cassandra的相关CLICassandra的Python API，并且给出一个批量导入数据的例子。

有没有一种机制能保证Publisher能够感知它的Message有没有被处理的？答案肯定的。唯一能够保证消息不会丢失的方式是利用事务机制 -- 令 channel 处于 transactional 模式、向其 publish 消息、执行 commit 动作。在这种方式下，事务机制会带来大量的多余开销，并会导致吞吐量下降 250% 。为了补救事务带来的问题，引入了 confirmation 机制（即 Publisher Confirm）。 为了使能 confirm 机制，client 首先要发送

高并发的情况下，锁是一个灾难；那么架构是如何做到无锁编程的？

如何解决一个valgrind和gpreftools都检查不出的”内存泄露“？

本文主要关注ShuffledRDD的Shuffle Read是如何从其他的node上读取数据的。上文讲到了获取如何获取的策略都在org.apache.spark.storage.BlockFetcherIterator.BasicBlockFetcherIterator#splitLocalRemoteBlocks中。可以见注释。

通过上面一系列文章，我们知道在集群启动时，在Standalone模式下，Worker会向Master注册，使得Master可以感知进而管理整个集群；Master通过借助ZK，可以简单的实现HA；而应用方通过SparkContext这个与集群的交互接口，在创建SparkContext时就完成了Application的注册，Master为其分配Executor；在应用方创建了RDD并且在这个RDD上进行了很多的Transformation后，触发action，通过DAGScheduler将DAG划分为不同的St

在Spark 0.6和0.7时，Shuffle的结果都需要先存储到内存中（有可能要写入磁盘），因此对于大数据量的情况下，发生GC和OOM的概率非常大。因此在Spark 0.8的时候，Shuffle的每个record都会直接写入磁盘。一直到1.2.0，Shuffle的数据是一定会写入本地文件系统的，那么对于性能要求非常苛刻的用户，如何获得更好的性能呢？

前两篇文章写了Shuffle Read的一些实现细节。但是要想彻底理清楚这里边的实现逻辑，还是需要更多篇幅的；本篇开始，将按照Job的执行顺序，来讲解Shuffle。即，结果数据（ShuffleMapTask的结果和ResultTask的结果）是如何产生的；结果是如何处理的；结果是如何读取的。

本文详细讲解Shuffle Read的整个过程，包括如何获得Block的元数据信息，进行网络，本地读取。通过一个整体的流程架构图，详细大家可以对整个过程有一个更加深刻的把握

Shuffle Map Task运算结果的处理这个结果的处理，分为两部分，一个是在Executor端是如何直接处理Task的结果的；还有就是Driver端，如果在接到Task运行结束的消息时，如何对Shuffle Write的结果进行处理，从而在调度下游的Task时，下游的Task可以得到其需要的数据。Executor端的处理在解析BasicShuffle Writer时，我们知道ShuffleM

最近在做系统升级，由于当时设计的局限，导致系统不停服，保证服务的做法非常麻烦。当时再定方案的时候，由于自己在这方面没有经验，导致有些乐观。到了实际做的时候，预期时间至少比预想的多了一周的时间，要知道，在互联网公司，一周的时间是个非常长的时间。而这一周，还包括了OT。在这里总结一下分布式系统设计的大忌，本来想试着分一下级，但是还是算了，一来标准太多，无法制定一个合适的规则来界定；二来自己的经验也在增

Storage模块负责了Spark计算过程中所有的存储，包括基于Disk的和基于Memory的。用户在实际编程中，面对的是RDD，可以将RDD的数据通过调用org.apache.spark.rdd.RDD#cache将数据持久化；持久化的动作都是由Storage模块完成的。包括Shuffle过程中的数据，也都是由Storage模块管理的。可以说，RDD实现了用户的逻辑，而Storage则管理了用户

通过上面的架构和源码实现的分析，不难得出Shuffle是Spark Core比较复杂的模块的结论。它也是非常影响性能的操作之一。因此，在这里整理了会影响Shuffle性能的各项配置。尽管大部分的配置项在前文已经解释过它的含义，由于这些参数的确是非常重要，这里算是做一个详细的总结。1.1.1  spark.shuffle.manager前文也多次提到过，Spark1.2.0官方支持两种方式的Shuf

如果自己的公司需要打造一个适合自己公司内部使用的PaaS，亦或是你想了解一下一个云平台是怎么构建出来的，这篇文章会比较适合你。

记录了使用k8s过程中遇到的一些问题，不过货有点太干，接下来有时间会写一下关于架构原理和更详细的实践分享

Worker所起的作用有以下几个：1. 接受Master的指令，启动或者杀掉Executor2. 接受Master的指令，启动或者杀掉Driver3. 报告Executor/Driver的状态到Master4. 心跳到Master，心跳超时则Master认为Worker已经挂了不能工作了5. 向GUI报告Worker的状态

Apache Spark™is a fast and general engine for large-scale data processing： 一种快速通用可扩展的数据分析引擎。如果想要搞清楚Spark是什么，那么我们需要知道它解决了什么问题，还有是怎么解决这些问题的。本文将带领你进入Spark的世界，首先阐述了为什么Spark能够在众多的大数据分析平台中脱颖而出：通用，易用，高性能和与Hadoop的有效整合。Spark All in One的解决方案使用一个通用栈解决了流式，交互式，实时查询，迭代

上篇文章中，我们把每个Message都是deliver到某个Consumer。在这篇文章中，我们将会将同一个Message deliver到多个Consumer中。这个模式也被成为 "publish / subscribe"。 这篇文章中，我们将创建一个日志系统，它包含两个部分：第一个部分是发出log（Producer），第二个部分接收到并打印（Consumer）。 我们将构建两个Consumer，第一个将log写到物理磁盘上；第二个将log输出的屏幕。

上篇文章中，我们构建了一个简单的日志系统。接下来，我们将丰富它：能够使用不同的severity来监听不同等级的log。比如我们希望只有error的log才保存到磁盘上。1. Bindings绑定    上篇文章中我们是这么做的绑定：channel.queue_bind(exchange=exchange_name, queue=queue_na

本文将使用Python（pika 0.9.8）实现从Producer到Consumer传递数据”Hello, World“。 首先复习一下上篇所学：RabbitMQ实现了AMQP定义的消息队列。它实现的功能”非常简单“：从Producer接收数据然后传递到Consumer。它能保证多并发，数据安全传递，可扩展。 和任何的Hello world一样，它们都不复杂。我们将会设计两个程序，一个发送Hello world，另一个接收这个数据并且打印到屏幕。 整体的设计如下图：

在上篇文章中，我们解决了从发送端（Producer）向接收端（Consumer）发送“Hello World”的问题。在实际的应用场景中，这是远远不够的。从本篇文章开始，我们将结合更加实际的应用场景来讲解更多的高级用法。 当有Consumer需要大量的运算时，RabbitMQ Server需要一定的分发机制来balance每个Consumer的load。试想一下，对于web application来说，在一个很多的HTTP request里是没有时间来处理复杂的运算的，只能通过后台的一些工作线程来完

在云计算环境中，很多时候需要用它其他机器的计算资源，我们有可能会在接收到Message进行处理时，会把一部分计算任务分配到其他节点来完成。那么，RabbitMQ如何使用RPC呢？在本篇文章中，我们将会通过其它节点求来斐波纳契完成示例。

在上篇文章RabbitMQ消息队列（五）：Routing 消息路由 中，我们实现了一个简单的日志系统。Consumer可以监听不同severity的log。但是，这也是它之所以叫做简单日志系统的原因，因为是仅仅能够通过severity设定。不支持更多的标准。 比如syslog unix的日志工具，它可以通过severity (info/warn/crit...) 和模块(auth/cron/kern...)。这可能更是我们想要的：我们可以仅仅需要cron模块的log。 为

什么是ProtoBuf？ 一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。 它可以作为RabbitMQ的Message的数据格式进行传输，由于是结构化的数据，这样就极大的方便了Consumer的数据高效处理。当然了你可能说使用XML不也可以吗？与XML相比，ProtoBuf

OpenStack是一个美国国家航空航天局和Rackspace合作研发的云端运算‎软件，以Apache许可证授权，并且是一个自由软件和开放源代码项目。OpenStack是IaaS（基础设施即服务）‎软件，让任何人都可以自行建立和提供云端运算服务。此外，OpenStack也用作建立防火墙内的“私有云”（Private Cloud），提供机构或企业内各部门共享资源。 Cinder提供了OpenStack的Block Service（块服务）。类似于 Amazon 的 EBS 块存储服务，OpenS

本文主要介绍5个典型的HDFS流程，这些流程充分体现了HDFS实体间IPC接口和stream接口之间的配合。Client和NameNode，主要是介绍了Client对NN的各种文件系统目录树元数据的操作。还通过源码分析了HDFS在读取文件时，Client，NN和DN发生的事件和这些事件的顺序。 即使不考虑出现错误的情况，写文件也是HDFS最复杂的流程。本文通过创建一个新文件并向文件写入数据，结束后关闭这个文件为例，分析文件写入时各个节点之间的配合。还讨论了DN的启动及其与NN之间的交互。包括DN从启动到

一年前开始学习Hadoop。Hadoop， 大数据的事实标准，被Facebook， Yahoo，eBay，taobao，baidu广泛应用。Hadoop本身很复杂，包含了很多子项目，不同的应用场景催生了不同的子项目。        最近要做OpenStack的项目，开始学习OpenStack。也反思了一下我现在所从事的行业：企业存储，路在何方？        IT的技术发展可以说是日新月异。在人们

1. 背景        企业存储是企业信息系统管理很重要的组成部分。企业存储包含了大量的数据，供大量人使用。对于航空系统和金融系统来说，信息存储就更加重要了。 作为企业信息存储，扩展性是非常重要的，因为现在企业对于空间的使用越来越多。          那么一个企业可能会采用其他存储厂商的产品，原来信息如何保留？ 使用数据迁移功能（migration），可以将数据转移到其他系统上。但是企业数据数

BTRFS，通常念成 Butter FS,Better FS 或B-tree FS。下一代的Linux文件系统。 它基于写时拷贝（copy-on-write），支持高效的snapshot和clone。它使用b-tree作为存储的数据结构。在BTRFS项目主页上对自己是这么描述的："一个新的针对Linux的写时复制文件系统，致力于实施高级的功能，同时关注容错、修复和管理方便性。" 它有哪些高级功能呢？下面的feature来自BTRFS的项目主页：http://btrfs.wiki.kerne

Btree数据结构可以说是BTRFS文件系统的基础。它提供了一个通用的方式去存储不同的数据类型。它仅仅存储3个数据类型：key， item和block header。   btrfs_header的定义如下：struct btrfs_header { u8 csum[32]; u8 fsid[16]; __le64 blocknr; __le64 flags;

HDFS，为Hadoop这个分布式计算框架提供高性能、高可靠、高可扩展的存储服务。HDFS的系统架构是典型的主/从架构，早期的架构包括一个主节点NameNode和多个从节点DataNode。 HDFS HA的解决方案可谓百花齐放，Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shared NAS+NFS，因为简单易用，但是需要提供一个HA的共享存储设备。而

Hadoop框架中最核心设计就是：HDFS和MapReduce。HDFS提供了海量数据的存储，MapReduce提供了对数据的计算。HDFS在Hadoop中扮演了非常基础的作用，以文件系统的形式为上层应用提供海量数据的存储服务。 HDFS作为一个分布式文件系统，具有高容错的特点。它可以部署在廉价的通用硬件上，提供高吞吐率(Throughput)的数据访问，特别适合那些需要处理海量数据集的应用程序。它没有遵循POSIX的要求，不支持ls，cp这样标准的UNIX命令，也不支持fopen和fread这

本文分析了Spark1.0.0的Client，Master和Worker之间是如何通信的。通过对通信的分析，可以清楚的理解各个角色的作用和责任，和它在集群中扮演的不同角色。当然了，为了便于源码分析，本文开始分析了akka，一个非常优秀的actor的实现：高性能，易于编程，可扩展和弹性无中心。

本文详细讲解了Spark在Standalone模式下的Master的HA的源码分析。为了解决Standalone模式下的Master的SPOF，Spark采用了ZooKeeper提供的选举功能。Spark并没有采用ZooKeeper原生的Java API，而是采用了Curator，一个对ZooKeeper进行了封装的框架。采用了Curator后，Spark不用管理与ZooKeeper的连接，这些对于Spark来说都是透明的。Spark仅仅使用了100行代码，就实现了Master的HA。当然了，Spark是