心有猛虎，细嗅蔷薇: 九月 2016

2016年9月25日星期日

AMQ_010：JBoss A-MQ 6 开发培训

培训对象：Java 开发人员
培训时间：1天

上午

主题：JBoss A-MQ 介绍
演示：安装与启动JBoss A-MQ
演示：使用 Queue 进行 Point-to-Point 通信
演示： Queue 的多个消费者
演示：使用 Topic 进行 Publish/Subscribe 通信
主题：Java Message Service 介绍
演示：持久化订阅
演示：实现Request/Reply 模式通信
演示：使用事务

下午

主题：JBoss A-MQ 高级特性
演示：通配 Queue/Topic
演示：Exclusive Consumers
演示：设置优先级的Exclusive Consumers
演示：Virtual Destinations
主题：客户端连接方式以及Broker 网络拓扑结构
主题：高可用性、可靠性以及负载均衡
演示：Broker 高可用
演示：Message Groups
主题：使用 Fabric 管理 JBoss A-MQ

1. 测试环境
LinkedIn团队做了个实验研究，对比Kafka与Apache ActiveMQ V5.4和RabbitMQ V2.4的性能。他们使用ActiveMQ默认的消息持久化库Kahadb。LinkedIn在两台Linux机器上运行他们的实验，每台机器的配置为8核2GHz、16GB内存，6个磁盘使用RAID10。两台机器通过1GB网络连接。一台机器作为代理，另一台作为生产者或者消费者。

2. 生产者测试
LinkedIn团队在所有系统中配置代理，异步将消息刷入其持久化库。对每个系统，运行一个生产者，总共发布1000万条消息，每条消息200字节。Kafka生产者以1和50批量方式发送消息。ActiveMQ和RabbitMQ似乎没有简单的办法来批量发送消息，LinkedIn假定它的批量值为1。结果如下图所示：

Kafka 性能要好很多的主要原因包括：
（1）Kafka不等待代理的确认，以代理能处理的最快速度发送消息。
（2）Kafka有更高效的存储格式。平均而言，Kafka每条消息有9字节的开销，而ActiveMQ有144字节。其原因是JMS所需的沉重消息头，以及维护各种索引结构的开销。LinkedIn注意到ActiveMQ一个最忙的线程大部分时间都在存取B-Tree以维护消息元数据和状态。

3. 消费者测试
为了做消费者测试，LinkedIn使用一个消费者获取总共1000万条消息。LinkedIn让所有系统每次拉请求都预获取大约相同数量的数据，最多1000条消息或者200KB。对ActiveMQ和RabbitMQ，LinkedIn设置消费者确认模型为自动。结果如下图所示：

Kafka性能要好很多的主要原因包括：
（1）Kafka有更高效的存储格式；在Kafka中，从代理传输到消费者的字节更少。
（2）ActiveMQ和RabbitMQ两个容器中的代理必须维护每个消息的传输状态。LinkedIn团队注意到其中一个ActiveMQ线程在测试过程中，一直在将KahaDB页写入磁盘。与此相反，Kafka代理没有磁盘写入动作。最后，Kafka通过使用sendfile API降低了传输开销。

Kafka_003：各个组件介绍（摘录+整理）

1. Topics
Kafka 只支持基于 Topic 的发布/订阅模式，它并没有实现 JMS 规范。

一个 Topic 可以认为是一类消息，每个 Topic 被分成多个 partitions，每个 partition 是一个有序的队列，在物理存储层面，每个 partition 由多个日志文件组成。每条发布到 partition 的消息都会以 append 方式写到日志文件的尾部，每条消息在文件中的位置称为 offset，offset 是一个 long 型数字，它唯一的标记一条消息。

2. Broker
Broker 不维护 Producer 和 Consumer 的状态信息，这些信息由 Zookeeper 保存，即 Broker 本身是无状态的。

一个 Topic 的多个 partitions 被分布在 Kafka 集群中的多个 Broker 上，每个 Broker 负责 partitions 中消息的读写操作。

此外，Kafka 还可以配置 partitions 的副本个数（replicas），将 partition 备份到多台机器上，提高可用性。

基于 partitions 的副本方案，意味着需要对多个备份进行调度，每个 partition 都有一个 leader 负责所有的读写操作，如果 leader 失效，那么会有一个 follower成为新的 leader 来接管工作。follower 本身不接受用户请求，只是和 leader 进行消息同步。

有多少个 partitions 就有多少个 leader，Kafka 会把 leader 均衡地分布在每个 Broker 实例上，来确保整体的性能稳定。

3. Producers 生产者

Producer 将消息发布到指定的 Topic 中，同时 Producer 也能决定消息归属于哪个 partition，比如基于 round-robin 方式或者通过其他的一些算法等。

4. Consumers 消费者

每个 Consumer 属于一个 Consumer Group；一个 Consumer Group 可以有多个 Consumers。

发送到 Topic 的消息，只会被订阅此 Topic 的每个 Consumer Group 中的一个 Consumer 消费，因此可以认为一个 Consumer Group 是一个“订阅者”。

如果所有的 Consumer 都具有相同的 Consumer Group，消息将会在所有的 Consumers 之间负载均衡，跟 Queue 特性很像。

如果所有的 Consumer 都具有不相同的 Consumer Group，消息将会广播给所有的 Consumers，跟 Topic 特性一样。

Consumer 需要保存已消费消息的 offset。

再说的仔细些，一个 Topic 中的每个 partition，只会被一个“订阅者”（一个 Consumer Group）中的一个 Consumer 消费；不过，一个 Consumer 可以消费多个 partitions 中的消息。

Kafka 的设计原理决定：对于一个 Topic，同一个 Consumer Group 中不能有多于 partitions 个数的 Consumer 同时消费，否则意味着某些 Consumer 将无法得到消息。

Kafka只能保证一个 partition 中的消息被某个 Consumer 消费时是按顺序消费的。但从 Topic 角度来说，消息仍然不是有序消费的.

Kafka 保证

（1）发送到 partitions 中的消息将会按照它接收的顺序追加到日志中。

（2）对于 Consumer 而言，它们消费消息的顺序和日志中消息顺序一致。

（3）如果 Topic 的 replicationfactor=N，那么允许 N-1 个 broker 实例失效。

5. 存储

Kafka的存储布局非常简单。话题的每个分区对应一个逻辑日志。物理上，一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区，代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后，段文件真正写入磁盘中。写入完成后，消息公开给消费者。

与传统的消息系统不同，Kafka系统中存储的消息没有明确的消息Id。

消息通过日志中的逻辑偏移量来公开。这样就避免了维护配套密集寻址，用于映射消息ID到实际消息地址的随机存取索引结构的开销。消息ID是增量的，但不连续。要计算下一消息的ID，可以在其逻辑偏移的基础上加上当前消息的长度。

消费者始终从特定分区顺序地获取消息，如果消费者知道特定消息的偏移量，也就说明消费者已经消费了之前的所有消息。消费者向代理发出异步拉请求，准备字节缓冲区用于消费。每个异步拉请求都包含要消费的消息偏移量。Kafka利用sendfile API高效地从代理的日志段文件中分发字节给消费者。

参考文献：
1. http://www.infoq.com/cn/articles/apache-kafka/
2. http://www.cnblogs.com/likehua/p/3999538.html

Cloud_027：NFS 介绍

共享文件系统时，不同的操作系统使用的是不同的协议：Windows 用 CIFS，Unix 用 NFS，MAC 用 AFP。
其实 NFS 可以工作在任何操作系统上，只不过每种操作系统主推的是自己的协议。
为了能够跨操作系统共享文件系统，NAS 需要支持多种共享协议，比如本文要介绍的 NFS。
NFS（Network File System，网络文件系统）使一台电脑可以通过网络访问另外一台电脑上的共享，使用起来就如同本地文件系统一样方便。
NFS 目前最新的版本是 v4。
下图展示了多台客户端通过 NFS 对 NAS 的访问。

参考文献：
1. http://blog.chinaunix.net/uid-1829236-id-3242030.html
2. http://blog.csdn.net/younger_china/article/details/52175085

2016年9月24日星期六

ActiveMQ_044：支持的通讯协议（摘录+整理）

ActiveMQ 支持的通讯协议有：TCP、SSL、NIO、NIO SSL、OpenWire、STOMP、AMQP、 MQTT。

1. AMQP（Advanced Message Queuing Protocol，高级消息队列协议）
AMQP 主要是由金融领域的软件专家们贡献的创意，而联合了通讯和软件方面的力量，一起打造出来的规范。AMQP 同时定义了消息中间件的语意层面和协议层面。
AMQP 是语言中立的，意味着只要遵循 AMQP 的协议，任何一种语言都可以开发消息组件乃至中间件本身。

2. MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）
MQTT 是 IBM 开发的一个即时通讯协议，可以把所有联网物品和外部连接起来，比如通过 Twitter 让房屋联网。

3. OpenWire
OpenWire 是 ActiveMQ 自己的协议，可以以 native 方式访问 ActiveMQ，是默认的通讯协议。

4. STOMP（Streaming Text Orientated Message Protocol，流文本定向消息协议）
STOMP 是一种为面向消息的中间件设计的简单文本协议。

参考文献：
1. https://my.oschina.net/u/914897/blog/420745?p=1
2. http://activemq.apache.org/configuring-transports.html

Cloud_026：三种存储设备（DAS、SAN、NAS）的区别（摘录+整理）

存储按照服务器类型分为：封闭系统的存储和开放系统的存储。
封闭系统主要指大型机，开放系统指基于Windows、UNIX、Linux 等操作系统的服务器。
开放系统的存储分为：内置存储和外挂存储。
外挂存储根据连接的方式分为：直连式存储（Direct-Attached Storage，DAS）和网络化存储（Fabric-Attached Storage，FAS）。
网络化存储根据传输协议又分为：网络接入存储（Network-Attached Storage，NAS）和存储区域网络（Storage Area Network，SAN）。

1. DAS 存储
DAS 存储经常用在中小企业应用中，存储设备被直连到应用的服务器中，数据应用也安装在直连的 DAS 存储设备上。
DAS 存储依赖宿主机的操作系统进行数据的读写和维护，数据备份和恢复要求占用宿主机资源（CPU、I/O），数据流需要回流主机再到服务器连接着的磁带机。数据备份通常占用服务器主机资源 20~30%，因此日常数据备份一般在深夜进行。直连式存储的数据量越大，备份和恢复的时间就越长。
DAS 存储与服务器主机之间的连接通道通常采用 SCSI 连接，随着服务器CPU的处理能力越来越强，存储硬盘空间越来越大，阵列的硬盘数量越来越多，SCSI 通道将会成为 IO 瓶颈；另外，服务器主机 SCSI 插槽也是有限的。
DAS 存储或者服务器主机的扩展时，需要停机，对于银行、电信、传媒等行业 7×24 小时服务的关键业务系统，这是不可接受的。而且 DAS 存储或服务器主机的扩展，只能由厂商提供，受限于厂商。

2. NAS 存储

NAS 存储也称为附加存储，顾名思义，就是存储设备通过标准的网络拓扑结构（例如以太网）添加到一群计算机上。NAS 是文件级的存储方法，主要解决迅速增加存储容量的需求。

NAS 存储使用较多的场景是文档共享、图片共享、电影共享等等。

随着云计算的发展，一些 NAS 厂商也推出了云存储功能。

NAS 存储即插即用，采用标准的 TCP/IP 协议，支持多种操作系统，可用于混合 Unix/Linux/Windows 局域网内。

随着千兆和万兆网卡的出现，NAS 的性能也大幅提升。

NAS 存储的缺点是：备份时消费网络带宽。与将备份数据流从 LAN 中转移出去的 SAN 存储不同，NAS 仍然使用网络进行备份和恢复，这时会影响用户的使用，建议在深夜备份。

3. SAN 存储
SAN 存储，是通过光纤通道交换机连接存储阵列和服务器主机，最后成为一个专用的存储网络。

SAN 存储提供了一种与现有 LAN 连接的简易方法，并且通过同一物理通道支持广泛使用的 SCSI 和 IP 协议。SAN 提供块设备的访问，不受基于 SCSI 存储结构的布局限制。特别重要的是，随着存储容量的爆炸性增长，SAN 可以独立地增加它们的存储容量。SAN 允许任何服务器连接到任何存储阵列，这样不管数据置放在那里，服务器都可直接存取所需的数据。因为采用了光纤接口，SAN 还具有更高的带宽。SAN 存储备份时对网络总体性能没有影响。

与 NAS 文件级的存储不同，SAN 是块设备的存储。

SAN 的缺点就是太贵，大型磁带库、磁盘柜等产品虽然都是很好的存储解决方案，但是价格让人望而却步。

4. 总结

DAS 存储一般应用在中小企业，与计算机采用直连方式；NAS 存储通过以太网添加到计算机上；SAN 存储则使用 FC 接口，提供性能更佳的存储。

参考文献：
1. http://stor.zol.com.cn/387/3876012.html
2. http://zhidao.baidu.com/link?url=SPQ2HDiV3ajQgAzv2192jI8qKuheu-BtFIAX4zq5WFZMDdGwEYI3gjnQXgnyYimn5D9fZmEF1WhR7IK2uSj53wUl7VwoTO6z9LQWbMRJNVm
3. http://wallimn.iteye.com/blog/1290721

2016年9月22日星期四

Mesos_003：Mesos 工作流（摘录+整理）

（1）Slave 1 向 Master 汇报其空闲资源：4 个 CPU、4 GB RAM。然后，Master 触发分配策略模块，得到的反馈是 Framework 1 要请求全部可用资源。
（2）Master 向 Framework 1 发送资源邀约，描述了 Slave 1 上的可用资源。
（3）Framework 1 的调度器（Scheduler）响应 Master，需要在 Slave 1 上运行两个任务，第一个任务分配 2 CPUs、1 GB RAM 资源，第二个任务分配 1 CPUs、 2 GB RAM 资源。
（4）最后，Master向 Slave 1 下发任务，分配适当的资源给 Framework 1 的任务执行器（Executor），接下来由执行器启动这两个任务（如图中虚线框所示）。
此时，还有 1 个 CPU 和 1GB 的 RAM 尚未分配，因此分配模块可以将这些资源供给 Framework 2。

资源分配
为了实现在同一组 Slave 节点集合上运行多任务这一目标，Mesos 使用了隔离模块，除了原有的容器隔离技术，还增加了 Docker 作为运行任务的隔离机制。
不管使用哪种隔离模块，为运行特定应用程序的任务，都需要将执行器全部打包，并在已经为该任务分配资源的 Slave 服务器上启动。
当任务执行完毕后，容器会被“销毁”，资源会被释放，以便可以执行其他任务。

参考文献：
1. http://www.open-open.com/news/view/139b98b Mesos vs Kubernetes
2. http://dockone.io/article/686 谈谈Apache Mesos和Mesosphere DCOS：历史、架构、发展和应用
3. http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/ 统一资源管理与调度平台（系统）介绍
4. http://dongxicheng.org/apache-mesos/meso-architecture/ Apache Mesos总体架构
5. http://www.infoq.com/cn/articles/analyse-mesos-part-01/ 深入浅出Mesos（一）：为软件定义数据中心而生的操作系统
6. http://www.infoq.com/cn/articles/analyse-mesos-part-02/ 深入浅出Mesos（二）：Mesos的体系结构和工作流
7. http://www.infoq.com/cn/articles/analyse-mesos-part-03/ 深入浅出Mesos（三）：持久化存储和容错
8. http://www.infoq.com/cn/articles/analyse-mesos-part-04/ 深入浅出Mesos（四）：Mesos的资源分配
9. http://www.infoq.com/cn/articles/analyse-mesos-part-05/ 深入浅出Mesos（五）：成功的开源社区
10. http://www.infoq.com/cn/articles/analyse-mesos-part-06/ 深入浅出Mesos（六）：亲身体会Apache Mesos

Mesos_002：Mesos 架构（摘录+整理）

Mesos 实现了两级调度架构，可以管理多种类型的应用程序。

第一级调度是 Master 的守护进程，管理 Mesos 集群中所有节点上运行的 Slave 守护进程。
集群由物理机/虚拟机组成，用于运行应用程序的任务，比如 Hadoop 和 MPI。
第二级调度由 Framework 组件完成，Framework 包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。
Mesos 能和不同类型的 Framework 通信，每种 Framework 由相应的应用集群管理，图中展示了 Hadoop 和 MPI 两种类型，其它类型的应用程序也有相应的 Framework。
每种 Framework 都需要注册到 Master 上。

Master 协调全部的 Slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源，然后向注册到 Master 的 Framework 发出资源邀约。
Framework 可以根据应用程序的需求，选择接受或拒绝来自 Master 的资源邀约。
一旦接受邀约，Master 即协调 Framework 和 Slave，调度节点上任务，并在容器中执行。
多种类型的任务，比如 Hadoop 和 Cassandra，可以在同一个节点上同时运行，这正是使用 Mesos 的好处之一。

Mesos 的设计具有包容性、模块化，核心功能插件化，比如分配策略、隔离机制和 Framework。
特别是 Framework，每接入一种新的 Framework，Master无需为此编码，Slave 模块可以复用。开发者可以专注于他们的应用和 Framework 自身。

了解了 Mesos 架构，还有一个问题不可避免，那就是 Mesos 适合作为数据中心的哪一层的抽象?
我们知道，IaaS 层抽象的是机器，而 PaaS 层考虑更多是部署和管理应用/服务，它并不关心底层的那些基础架构。
Mesos 这一层抽象的是 CPU、内存、网络，其目的是为运行其上的框架提供抽象后的资源池，使得这些框架更加易于构建和运行。
因此 Mesos 应该位于 IaaS 层和 PaaS 层之间。
换言之，你可以在一个 IaaS 上运行 Mesos（比如 OpenStack）；可以基于 Mesos 之上构建一个 PaaS 系统（比如 Marathon）。

Mesos 是为构建和运行其它分布式系统（比如 Spark）提供服务的分布式系统。

参考文献：
1. http://www.open-open.com/news/view/139b98b Mesos vs Kubernetes
2. http://dockone.io/article/686 谈谈Apache Mesos和Mesosphere DCOS：历史、架构、发展和应用
3. http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/ 统一资源管理与调度平台（系统）介绍
4. http://dongxicheng.org/apache-mesos/meso-architecture/ Apache Mesos总体架构
5. http://www.infoq.com/cn/articles/analyse-mesos-part-01/ 深入浅出Mesos（一）：为软件定义数据中心而生的操作系统
6. http://www.infoq.com/cn/articles/analyse-mesos-part-02/ 深入浅出Mesos（二）：Mesos的体系结构和工作流
7. http://www.infoq.com/cn/articles/analyse-mesos-part-03/ 深入浅出Mesos（三）：持久化存储和容错
8. http://www.infoq.com/cn/articles/analyse-mesos-part-04/ 深入浅出Mesos（四）：Mesos的资源分配
9. http://www.infoq.com/cn/articles/analyse-mesos-part-05/ 深入浅出Mesos（五）：成功的开源社区
10. http://www.infoq.com/cn/articles/analyse-mesos-part-06/ 深入浅出Mesos（六）：亲身体会Apache Mesos

Mesos_001：Mesos 是什么？（摘录+整理）

Mesos 是分布式系统的内核，其设计宗旨在于尝试和提高集群的效能和性能。
Mesos 官网：http://mesos.apache.org

软件定义数据中心（Software Define Data Center），具备把硬件虚拟化成为资源池的能力。
对于应用程序来说，底层的基础架构将被抽象出来，并能够根据应用程序不断变化的需求，动态且自动地分配、重新分配资源给应用程序。
而应用程序运行于数据中心的不同组件之中。

原有的数据中心，以物理机/虚拟机为管理单元，粒度不够精细，运行其上的应用程序过于庞大，难以提高集群的效能和性能。

如今，飞速发展的容器技术、分布式应用程序和微服务技术正悄然改变着数据中心的运行和管理方式。

试想，可否整合数据中心中的所有资源，并将它们放在一个大的虚拟池里，代替单独的物理服务器；然后开放诸如 CPU、内存和 I/O 这些基本资源而不是虚拟机？
可否把应用程序拆分成小的、隔离的任务单位，从而根据数据中心应用的需求，从虚拟数据中心池中动态分配任务资源？
就像操作系统把 CPU 和内存放入资源池，使其可以为不同的进程协调分配和释放资源。
也就是说，把 Mesos 看做操作系统内核，把数据中心看为 PC 机。

Mesos 正在让软件定义数据中心成为现实。

参考文献：

1. http://www.open-open.com/news/view/139b98b Mesos vs Kubernetes
2. http://dockone.io/article/686 谈谈Apache Mesos和Mesosphere DCOS：历史、架构、发展和应用
3. http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/ 统一资源管理与调度平台（系统）介绍
4. http://dongxicheng.org/apache-mesos/meso-architecture/ Apache Mesos总体架构
5. http://www.infoq.com/cn/articles/analyse-mesos-part-01/ 深入浅出Mesos（一）：为软件定义数据中心而生的操作系统
6. http://www.infoq.com/cn/articles/analyse-mesos-part-02/ 深入浅出Mesos（二）：Mesos的体系结构和工作流
7. http://www.infoq.com/cn/articles/analyse-mesos-part-03/ 深入浅出Mesos（三）：持久化存储和容错
8. http://www.infoq.com/cn/articles/analyse-mesos-part-04/ 深入浅出Mesos（四）：Mesos的资源分配
9. http://www.infoq.com/cn/articles/analyse-mesos-part-05/ 深入浅出Mesos（五）：成功的开源社区
10. http://www.infoq.com/cn/articles/analyse-mesos-part-06/ 深入浅出Mesos（六）：亲身体会Apache Mesos