创建网页的代码seo查询系统源码

当前位置： 首页 > news >正文

创建网页的代码,seo查询系统源码,太原网站建设解决方案,网络营销的工具有哪些1、集群节点宕机 Nimbus服务器 硬件 单点故障#xff1f;可以搭建HA jStorm搭建 nimbus的HA nimbus的信息存储到zookeeper中#xff0c;只要下游没问题#xff08;进程退出#xff09;nimbus退出就不会有问题#xff0c; 如果在nimbus宕机#xff0c;也不能提交… 1、集群节点宕机 Nimbus服务器     硬件 单点故障可以搭建HA jStorm搭建  nimbus的HA nimbus的信息存储到zookeeper中只要下游没问题进程退出nimbus退出就不会有问题 如果在nimbus宕机也不能提交作业。 非Nimbus服务器     硬件 supervisor故障时该节点上所有Task任务都会超时Nimbus会将这些Task任务重新分配到其他服务器上运行 2、进程挂掉 Worker 挂掉时Supervisor会重新启动这个进程。如果启动过程中仍然一直失败并且无法向zookeeper发送心跳Nimbus会将该Worker执行的任务重新分配到其他服务器上 Supervisor 无状态所有的状态信息都存放在Zookeeper中来管理 快速失败每当遇到任何异常情况都会自动毁灭 Nimbus 无状态所有的状态信息都存放在Zookeeper中来管理 快速失败每当遇到任何异常情况都会自动毁灭 3、消息的完整性 从Spout中发出的Tuple以及基于他所产生Tuple例如上个例子当中Spout发出的句子以及句子当中单词的tuple等。由这些消息就构成了一棵tuple树。当这棵tuple树发送完成并且树当中每一条消息都被正确处理就表明spout发送消息被“完整处理”即消息的完整性。 元组树 如果衍生元组出错则重发根元组 根元组就是spout发送的那个元组 Acker – 消息完整性的实现机制 Storm的拓扑当中特殊的一些任务 负责跟踪每个Spout发出的Tuple的DAG有向无环图 默认每个worker一个acker 保证消息至少处理一次 Storm提供了几种不同级别的保证消息处理包括尽力而为best effort至少一次at least once以及通过Trident保证只完全处理一次exactly once。 此处指的是至少完全处理一次。 当元组树已经用完并且树中的每条消息都已处理完毕时Storm会认为从水龙头发射的元组是“完全处理”的。如果在指定的超时内无法完全处理其消息树则认为该元组失败。可以使用Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS对指定的拓扑进行配置默认为30秒。 public interface ISpout extends Serializable {void open(Map conf, TopologyContext context, SpoutOutputCollector collector);void close();void nextTuple();void ack(Object msgId);void fail(Object msgId); } 首先storm调用spout的nextTuple方法发射一个元组。spout使用SpoutOutputCollector在声明的流中发射元组。当发射元组的时候spout使用messageId标记该元组。 _collector.emit(new Values(field1, field2, 3) , msgId); 其次当向消费闪电发送元组的时候strom追踪该消息树。如果storm发现一个元组被完全处理了storm就会调用spout的ack方法并将该元组的messageId传送给它。如果元组处理超时storm就调用spout的fail方法。只会在发射该元组的spout中调用它的ack或者fail方法。 好处是 首先当创建了新的元组树边的时候要通知storm。其次当完成了一个元组的处理之后要告诉storm。通过这种方式storm就可以知道元组被完全处理了然后调用ack方法或者调用fail方法如果处理失败。 在元组树中创建一条边称为锚点。当发送一个新元组的时候就会创建一条边。 public class SplitSentence extends BaseRichBolt {OutputCollector _collector;public void prepare(Map conf, TopologyContext context, OutputCollector collector) {_collector collector;}public void execute(Tuple tuple) {String sentence tuple.getString(0);for(String word: sentence.split( )) {_collector.emit(tuple, new Values(word));}_collector.ack(tuple);}public void declareOutputFields(OutputFieldsDeclarer declarer) {declarer.declare(new Fields(word));} } 每个元组通过在emit中指定输入的元组进行锚点标记。 由于被标记锚点如果在下游处理中处理失败了元组树顶点的元组会重新发送。 _collector.emit(new Values(word)); 上述方式没有对元组进行锚点标记。当元组在下游处理失败了根元组不会重发。输出的元组也可以标记多个锚点。如果流中有聚合或者join就比较有用。标记了多个锚点的元组如果处理失败就会触发多个元组树根元组重发。通过list集合为元组标记多个锚点 ListTuple anchors new ArrayListTuple(); anchors.add(tuple1); anchors.add(tuple2); _collector.emit(anchors, new Values(1, 2, 3)); 很明显手动调用fail方法比通过元组的处理超时从而由storm调用fail方法要更快地重发根元组。由于storm使用内存来存储元组树如果不及时的ack或者fail有可能导致内存溢出。 storm的拓扑中提供了一组acker用于追踪spout发射的每个元组及其衍生的元组一旦发现DAG处理完了就同创建该元组的spout进行确认。 Config.TOPOLOGY_ACKERS用于设置acker的数量。默认情况下一个worker一个acker任务。 当拓扑创建了元组就会为其分配一个随机的64bit的idacker使用该ID追踪spout发送的每个元组。元组树上的元组都知道这个ID。当在闪电中创建了新的元组该ids会拷贝给新的元组。当元组确认后元素发送消息给acker任务以改变元组树。 当通过C衍生出D和E并且确认之后就会从元组树中移除C。这样可以保证元组树不会过早地完成。 如果拓扑中包含多个acker当一个元组确认后如何知道向哪个acker发送确认消息 storm使用hash取模的方式将一个spout的元组id跟一个acker任务绑定。 acker任务如何知道该向哪个spout任务发送确认消息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万年才会产生一个错误造成数据丢失。 元组都会产生和消亡元组不会凭空产生也不会凭空消失 元组守恒定理 acker为当前根元组预留一个000二进制数字 messageId 000 100 100 010 110 001 111 100 011 010 001 001 000 如果这个值不是0则过30s要求spout重发根元组。 acker 异常情况 由于任务死掉没有确认元组元组树根节点的元组和丢掉的元组确认会超时重新发送根元组。acker死掉所有的元组确认都会超时根节点元组重发spout死掉spout获取数据的数据源负责重新发送消息。例如MQ等会将所有打开的消息放回到队列中之后重新处理。 由此可见strom的可靠性机制完全是分布式的可扩展的以及容错的。