挖坑
- Storm
- Kafka
- Elasticsearch
- activeMQ
- ZeroMQ
- redis
- 设计模式
- 计算机网络
- linux
- ldap
- SSH
- java 多线程
- 算法与数据结构
- Spark机器学习
- Cookie与Session
- Jsoup
填坑
1、 ZeroMQ
ZeroMQ 是一个更小、更快、更简单的智能传输层协议
ZeroMQ 不提供现成的安装套件（比如broker），这也意味着使用者必须自己来构建需要的套件
ZeroMQ 是为那些对大型分布式系统感兴趣的开发者们而生的！假如你熟悉 C 语言，那么使用 ZeroMQ 将是件非常享受的事情，因为 ZeroMQ 开发包中已经包含了非常丰富的 C 语言的使用范例，有经验的开发者可以快速入手
基本的ZeroMQ模式：请求响应模式，发布/订阅模式，管道模式，排他对模式
类库提供一些套接字，每一个套接字可以代表一个端口之间的多对多连接。以消息的粒度进行操作，套接字需要使用一种消息模式（message pattern）,然后专门为那种模式进行了优化。
2、 Storm
http://ifeve.com/getting-started-with-storm-5/
Storm是一个免费开源、分布式、高容错的实时计算系统。Storm令持续不断的流计算变得容易，弥补了Hadoop批处理所不能满足的实时要求。Storm经常用于在实时分析、在线机器学习、持续计算、分布式远程调用和ETL等领域。Storm的部署管理非常简单，而且，在同类的流式计算工具，Storm的性能也是非常出众的。
Storm主要分为两种组件Nimbus和Supervisor。这两种组件都是快速失败的，没有状态。任务状态和心跳信息等都保存在Zookeeper上的，提交的代码资源都在本地机器的硬盘上
在Storm集群中，有两类节点：主节点master node和工作节点worker nodes。主节点运行着一个叫做Nimbus的守护进程。这个守护进程负责在集群中分发代码，为工作节点分配任务，并监控故障。Supervisor守护进程作为拓扑的一部分运行在工作节点上。一个Storm拓扑结构在不同的机器上运行着众多的工作节点。
- Nimbus负责在集群里面发送代码，分配工作给机器，并且监控状态。全局只有一个。
- Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程Worker。每一个要运行Storm的机器上都要部署一个，并且，按照机器的配置设定上面分配的槽位数。
- Zookeeper是Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根据Zookeerper上的心跳和任务运行状况，进行调度和任务分配的。
- Storm提交运行的程序称为Topology。
- Topology处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。
- Topology由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。
可以看出两个模块Nimbus和Supervisor之间没有直接交互。状态都是保存在Zookeeper上
知乎上有一个挺好的问答： 问：实时处理系统（类似s4, storm）对比直接用MQ来做好处在哪里？ 答：好处是它帮你做了：
1) 集群控制。2) 任务分配。3) 任务分发 4) 监控 等等。
需要知道Storm不是一个完整的解决方案。使用Storm你需要加入消息队列做数据入口，考虑如何在流中保存状态，考虑怎样将大问题用分布式去解决。解决这些问题的成本可能比增加一个服务器的成本还高。但是，一旦下定决定使用了Storm并解决了那些恼人的细节，你就能享受到Storm给你带来的简单，可拓展等优势了
虽然，有些地方做得还是不太好，例如，底层使用的ZeroMQ不能控制内存使用
maven打包程序
Bolt
Bolt是这样一种组件，它把元组作为输入，然后产生新的元组作为输出。实现一个bolt时，通常需要实现IRichBolt接口。Bolts对象由客户端机器创建，序列化为拓扑，并提交给集群中的主机。然后集群启动工人进程反序列化bolt，调用prepare，最后开始处理元组。
你处理的每条消息要么是确认的（译者注：collector.ack()）要么是失败的（译者注：collector.fail()）。Storm使用内存跟踪每个元组，所以如果你不调用这两个方法，该任务最终将耗尽内存
你可能已经注意到了，在许多情况下都需要消息确认。简单起见，Storm提供了另一个用来实现bolt的接口，BossBasicBolt。对于该接口的实现类的对象，会在执行execute方法之后自动调用ack方法。
declareOutputFields(OutputFieldsDeclarer declarer)
为bolt声明输出模式
prepare(java.util.Map stormConf, TopologyContext context, OutputCollector collector)
仅在bolt开始处理元组之前调用
execute(Tuple input)
处理输入的单个元组
cleanup()
在bolt即将关闭时调用
正如前面所说的，Storm保证通过spout发送的每条消息会得到所有bolt的全面处理。基于设计上的考虑，这意味着你要自己决定你的bolts是否保证这一点。
拓扑是一个树型结构，消息（元组）穿过其中一条或多条分支。树上的每个节点都会调用ack(tuple)或fail(tuple)，Storm因此知道一条消息是否失败了，并通知那个/那些制造了这些消息的spout(s)。既然一个Storm拓扑运行在高度并行化的环境里，跟踪始发spout实例的最好方法就是在消息元组内包含一个始发spout引用。这一技巧称做锚定(译者注：原文为Anchoring)。修改一下刚刚讲过的SplitSentence，使它能够确保消息都被处理了。