浅谈分布式计算的开发与实现(二)

实时计算

浅谈分布式计算的开发与实现(一)

接上篇，离线计算是对已经入库的数据进行计算，在查询时对批量数据进行检索、磁盘读取展现。 而实时计算是在数据产生时就对其进行计算，而后实时展现结果，通常是秒级。 举个例子来讲，若是有个大型网站，要实时统计用户的搜索内容，这样就能计算出热点新闻及突发事件了。 按照之前离线计算的作法是不能知足的，须要使用到实时计算。

小明做为有理想、有追求的程序员开始设计其解决方案了，主要分三部分。

• 每当搜索内容的数据产生时，先把数据收集到消息队列，因为其数据量较大，以使用kafka为例。 这个收集过程是一直持续的，数据不断产生而后不断流入到kafka中。
• 要有一个能持续计算的框架，一旦收集到数据，计算系统能实时收到数据，根据业务逻辑开始计算，而后不断产生须要的结果，这里以storm为例。
• 根据结果进行实时展现并入库， 能够一边展现一边入库，对外提供实时查询的服务。这里的入库能够是基于内存的Redis、MongoDB，也但是基于磁盘的HBase、Mysql、SqlServer等。

其流程图以下:

storm简介

一般都介绍Storm是一个分布式的、高容错的实时计算系统。 “分布式”是把数据分布到多台上进行计算，“高容错”下面谈，这里主要细节介绍下“实时计算”的实现。

storm有个角色叫topology，它相似mapreduce的job，是一个完整的业务计算任务抽象。 上章谈到hadoop的缺点在于数据源单一依赖HDFS，storm中Spout角色的出现解决了这个问题。 在Spout内部咱们能够读取任意数据源的数据，好比Redis、消息队列、数据库等等。 并且spout能够是多个，这样更好的分类，好比能够SpoutA读取kafka，SpoutB读取Redis。 示例以下：

<pre style="margin:0px; padding:0px; white-space:pre-wrap; overflow-wrap:break-word; font-family:&quot; Courier New&quot; !important; font-size:12px !important; ">
public class CalcPriceSpout:BaseRichSpout {
	private SpoutCollector Collector;
	public override void NexData() {
	//读取各类数据源，Redis、消息队列、数据库等
	Collector.emit("消息")
}
}</pre>
复制代码

代码中NexData是storm的核心方法，它一直被storm循环调用着， 在方法里咱们实时读取kafka的消息，而后把消息经过Collector组件发射到各个计算节点里，它相似小和尚中的Master。 这样应用每产生一条数据，会实时收集到kafka，而后被NextData消费，发射到节点开始计算。 NextData读取的消息时在内存中，而后直接经过网络流动到节点机器上的内存中开始计算，不会持久化到磁盘上。

由于速度比较快，因此叫实时计算，也有叫持续计算，意思是能够很是快的一直进行计算，至于叫什么均可以。

流式计算

主流的流式计算有S四、StreamBase、Borealis，其storm也具备流式计算的特性。 流式计算是指“数据能像液体水同样不断的在各个节点间流动，每一个节点均可以对“数据(液体水)”进行计算，而后产生新的数据，继续像水同样流动”。如图：

图中Spout就是水龙头，它不断的经过NextData产生数据，而后流动各个Bolt中。 Bolt是各个计算节点上的计算逻辑，它拿到数据后开始计算，完成后流向另一个，直到完成。 其Bolt也能够是任意个，这比Mapreduce只能分红Map、Reduce两部分好多了。 这样能够在BlotA中计算中间值，而后经过这个中间值去任意数据源拉取数据后，在流动到下一步处理逻辑中， 这个中间值直接在内存中，经过网络流动BlotB上。 其大大增长了其适用范围和灵活度，Spout和bolt的数据流动构成了一个有向无环图。 Bolt示例代码以下。

<pre style="margin:0px; padding:0px; white-space:pre-wrap; overflow-wrap:break-word; font-family:&quot; Courier New&quot; !important; font-size:12px !important; ">
public class CalcProductPriceBolt:BaseRichBolt {
	private BoltCollector Collector;
	public override void Execute(Tuple<string,string> input) {
	//Result=计算计算计算。 //Collector.Emit("Reulst");
	流动到另一个节点
}
}</pre>
复制代码

数据流动图：

概括总结

结合上篇，发现Hadoop离线计算的计算要求是把业务逻辑包上传到平台上，数据导入到HDFS上，这样才能进行计算。 其产生的结果数据是展现以前就计算好的，另外它的计算是按批次来的，好比不少公司的报表，都是天天凌晨开始计算前一天的数据，以便于展现。 其数据是不动的，计算逻辑也是不动的。

Storm的流式计算一样是把计算逻辑包上传到平台上，由平台调度，计算逻辑是不动的。 但数据能够是任意来源的，不断在计算节点进行流动。 也便是说在数据产生的时刻，就开始进行流动计算，它展现的结果数据是实时变化的。 其数据是流动的，计算逻辑是不动的。storm把产生的每条数据当成一个消息来处理，其内部也是经过消息队列组件zeromq来完成的。

高容错性

storm提供了各级别的可靠性保证，一消息从Spout流动到boltA，在流动boltB， 那storm会经过惟一值不断异或的设计去监测这个消息的完成状况，这个监测是一个和业务逻辑相似的bolt，不过它是有storm自身实现的，叫Acker，它的任务就是接收各个消息任务的完成状态，而后告诉Spout这个消息是否已经彻底处理。下面是几种异常处理状况：

• BoltB所在的节点挂了或消息异常，那么这条消息就没有处理完，Spout可在超时后从新发射该数据便可。
• Acker所在节点挂了后，即当前节点监控的消息彻底状况，会所有丢失，Spout会在消息超时作后续处理。
• 若是Spout所在节点挂了，那Spout发射的数据也会所有丢失， 这时可在消息队列中设置超时时间，若是没有一直没对消息进行Ack的话，那么这条消息会从新让其余的Spout从新接收到。这部分须要单独在消息队列中配置，另外storm消息的Ack确认对性能有必定影响，可根据消息的重要性是否要开启它。
• 若是storm平台级别的组件挂了，平台会尝试重启失败的组件，storm除nimbus组件外都是多节点点部署，挂了某一节点，不会对任务计算有所影响。