storm2

Storm2

storm如何保障消息的完全处理？

​ Storm可以保证从Spout发出的每个消息都能被完全处理。Storm的可靠性机制是完全分布式的(distributed)，可伸缩的(scalable)，容错的(fault-tolerant)。

​ 一条消息被完整处理是指一个从Spout发出的元组所触发的消息树中所有的消息都被Storm处理了，从Spout中发出的Tuple，以及基于他所产生Tuple由这些消息就构成了一棵tuple树，当这棵tuple树发送完成，并且树当中每一条消息都被正确处理，就表明spout发送消息被“完整处理”，即消息的完整性。如果在指定的超时时间里，这个Spout元组触发的消息树中有任何一个消息没有处理完，就认为这个Spout元组处理失败了。这个超时时间是通过每个拓扑的Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS配置项来进行配置的，默认是30秒。只有消息树中所有的消息都被Storm处理完了，才算是这条Spout消息被完整处理了。

Acker – 消息完整性的实现机制

​ 一个Storm拓扑有一组特殊的"acker"任务，它们负责跟踪由每个Spout元组触发的消息的处理状态。当一个"acker"看到一个Spout元组产生的有向无环图中的消息被完全处理，就通知当初创建这个Spout元组的Spout任务，这个元组被成功处理。可以通过拓扑配置项Config.TOPOLOGY_ACKER_EXECUTORS来设置一个拓扑中acker任务executor的数量。Storm默认TOPOLOGY_ACKER_EXECUTORS和拓扑中配置的Worker的数量相同，对于需要处理大量消息的拓扑来说，需要增大acker executor的数量。

​ 当拓扑创建了元组，就会为其分配一个随机的64bit的id，acker使用该ID追踪spout发送的每个元组。元组树上的元组都知道这个ID。当在闪电中创建了新的元组，该ids会拷贝给新的元组。当元组确认后，元素发送消息给acker任务，以改变元组树。


​ 当通过C衍生出D和E并且确认之后，就会从元组树中移除C。这样可以保证元组树不会过早地完成。

​ storm使用hash取模的方式将一个spout的元组id跟一个acker任务绑定。

​ spout发射元组的时候会给合适的acker发送一个消息表示对哪个spout的元组负责。acker发现元组树完成了，就知道向哪个spout任务发送完成的消息。

​ acker不显式地追踪元组。如果有数十万的节点，追踪所有的元组会有耗尽acker内存的风险。acker使用一个定长的空间20字节做这个工作。这个是storm的主要创新。

​ acker将spout发射的元组id和一个64bit的数字（ack val）相关联。ack val代表了该元组树的状态，不管spout发射的元组及其衍生的元组有多少，它仅仅是对所有创建的元组以及确认的元组id求异或xor操作。如果最终这个值ack val变成0，表示元组树已经被完全处理。某个元组的id和该64bit的数字异或结果是0的情况极其少见，比如每秒处理10k的元组，需要5000万年才会产生一个错误，造成数据丢失。

storm中drpc做什么用的？架构是什么样的？

​ DRPC (Distributed RPC) remote procedure call
​ 分布式远程过程调用

​ DRPC 是通过一个 DRPC 服务端(DRPC server)来实现分布式 RPC 功能的。
​ DRPC Server 负责接收 RPC 请求，并将该请求发送到 Storm中运行的 Topology，等待接收 Topology 发送的处理结果，并将该结果返回给发送请求的客户端。

​ DRPC把大量请求分布式的去做，一次请求如果串行的话可能会比较慢，并行的来处理，另一方面通过来降低平均一次请求的时间，解决了响应的吞吐。

​ DRPC设计目的：
​ 为了充分利用Storm的计算能力实现高密度的并行实时计算。
​ （Storm接收若干个数据流输入，数据在Topology当中运行完成，然后通过DRPC将结果进行输出。）

​ 客户端通过向 DRPC 服务器发送待执行函数的名称以及该函数的参数来获取处理结果。实现该函数的拓扑使用一个DRPCSpout 从 DRPC 服务器中接收一个函数调用流。DRPC 服务器会为每个函数调用都标记了一个唯一的 id。随后拓扑会执行函数来计算结果，并在拓扑的最后使用一个名为 ReturnResults 的 bolt 连接到 DRPC 服务器，根据函数调用的 id 来将函数调用的结果返回。

详述kafka的架构

​ Apache Kafka是一个分布式发布 - 订阅消息系统和一个强大的队列，可以处理大量的数据，并使您能够将消息从一个端点传递到另一个端点。 Kafka适合离线和在线消息消费。 Kafka消息保留在磁盘上，并在群集内复制以防止数据丢失。 Kafka构建在ZooKeeper同步服务之上。 它与Apache Storm和Spark非常好地集成，用于实时流式数据分析。

​ Kafka专为分布式高吞吐量系统而设计。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。

主题和分区

​ kafka的消息通过主题进行分类。主题类似于数据库中的表。

​ 主题可以被分为若干个分区，一个分区就是一个提交日志。

​ 消息以追加的方式写入分区，然后以先入先出的顺序读取。

​ 无法保证整个主题消息的顺序，可以保证一个分区内的消息顺序。

​ kafka通过分区实现数据冗余和伸缩性。

​ 一个主题通过将分区分布于不同的服务器上，横跨多个服务器，提供更大的性能。


​ 可以把一个主题的数据看成一个流，不管它有多少个分区。流是一组从生产者移动到消费者的数据。

生产者和消费者

​ 生产者（发布者、写入者）将消息发布到一个特定的主题上。

​ 生产者默认情况下把消息均匀地分布到主题的所有分区上，而不关心特定消息会写到哪个分区。

​ 分区器为消息的键生成一个散列值，映射到指定的分区上。这样可以保证包含同一个键的消息被写入到同一个分区。

​ 消费者（订阅者、读者）订阅一个或多个主题，按照消息生成的顺序读取消息。

​ 消费者通过偏移量区分已经读取过的消息。

​ 偏移量是元数据，递增的整数值，在创建消息时kafka把它添加到消息里。

​ 在给定的分区，每个消息偏移量唯一。

​ 消费者把每个分区最后读取的消息偏移量保存在zookeeper或kafka上。

​ 消费者是消费者群组一部分，群组保证每个分区只能被一个消费者使用。

​ 消费者与分区之间的映射称为消费者对分区的所有权关系。


broker和集群

​ 一个独立的kafka服务器是一个broker。

​ broker接收来自生产者的消息，为消息设置偏移量，提交消息到磁盘保存。

​ broker响应消费者请求，对读取分区做出响应，返回已经提交到磁盘上的消息。

​ 单个broker可以轻松处理数千个分区以及每秒百万级的消息量。

​ 每个集群有一个broker是集群控制器（自动选举）

​ 控制器将分区分配给broker和监控broker。

​ 一个分区属于一个broker，broker是分区的master

​ 一个分区可以分配给多个broker，提供了消息冗余，多个副本之间主从切换。

​ 消费者和生产者通过master操作消息。


​ 保留消息是kafka的重要特性。默认的消息保留策略是，要么保存一段时间（7天），要么保留消息到一定大小的字节数（1GB）。当消息数量达到这些上限，旧消息过期被删除。

​ 对每个主题，可配置消息保留策略。

多集群

需求：

​ 数据类型分离

​ 安全需求隔离

​ 多数据中心（灾难恢复）

如果使用多个数据中心，需要在它们之间同步消息。

kafka提供了MirrorMaker工具用于实现多个集群间的消息同步。MirrorMaker核心组件包含一个生产者和一个消费者，两者之间通过队列相连。消费者从一个集群读取消息，生产者把消息发送到另一个集群。


详述kafka消息队列的安装步骤

集群规划：

Zookeeper集群共三台服务器，分别为：node1、node2、node3。

Kafka集群共三台服务器，分别为：node1、node2、node3。

1、Zookeeper集群准备

kafka是一个分布式消息队列，需要依赖ZooKeeper，先安装好zk集群。

2、安装Kafka

下载压缩包（官网地址：http://kafka.apache.org/downloads.html）

解压：

tar -zxvf kafka_2.10-0.9.0.1.tgz -C /opt/

mv kafka_2.10-0.9.0.1/ kafka

​ 修改配置文件：config/server.properties



核心配置参数说明：

​ broker.id: broker集群中唯一标识id，0、1、2、3依次增长（broker即Kafka集群中的一台服务器）

注：

​ 当前Kafka集群共三台节点，分别为：node1、node2、node3。对应的broker.id分别为0、1、2。

​ zookeeper.connect: zk集群地址列表

将当前node1服务器上的Kafka目录同步到其他node2、node3服务器上：

scp -r /opt/kafka/ node2:/opt

scp -r /opt/kafka/ node3:/opt

修改node2、node3上Kafka配置文件中的broker.id（分别在node2、3服务器上执行以下命令修改broker.id）

sed -i -e 's/broker.id=.*/broker.id=1/' /opt/kafka/config/server.properties

sed -i -e 's/broker.id=.*/broker.id=2/' /opt/kafka/config/server.properties

3、启动Kafka集群

​ A、启动Zookeeper集群。

​ B、启动Kafka集群。

分别在三台服务器上执行以下命令启动：

bin/kafka-server-start.sh config/server.properties

4、测试

创建话题

（kafka-topics.sh --help查看帮助手册）

创建topic：

bin/kafka-topics.sh --zookeeper node1:2181,node2:2181,node3:2181 --create --replication-factor 2 --partitions 3 --topic test

（参数说明：

–replication-factor：指定每个分区的复制因子个数，默认1个

–partitions：指定当前创建的kafka分区数量，默认为1个

–topic：指定新建topic的名称*）*

查看topic列表：

bin/kafka-topics.sh --zookeeper node4:2181,node2:2181,node3:2181 --list

查看“test”topic描述：

bin/kafka-topics.sh --zookeeper node4:2181,node2:2181,node3:2181 --describe --topic test


创建生产者：

bin/kafka-console-producer.sh --broker-list node4:9092,node2:9092,node3:9092 --topic test

创建消费者：

bin/kafka-console-consumer.sh --zookeeper node4:2181,node2:2181,node3:2181 --from-beginning --topic test

详述电信项目的整体架构

（1） 采取flume采集数据，实现日志收集，使用负载均衡策略

（2） 使用kafka作为消息通道，将数据传递给storm集群，作用是解耦及不同速度系统缓冲

（3） Storm接收kafka中的数据，通过FiterBolt过滤掉不合法的数据，然后消费合法的数据进行计算，将计算结果传递给Hbase数据库

（4） Hbase：存储storm实时计算的结果

（5） Tomcat：取出Hbase的数据进行数据处理，使用WEB框架展示