#
简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
例如：如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行改任务需10小时。
采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。
而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，10小后，10个任务同时完成，这样，整身来看，还是1小时内完成一个任务!
集群概念
1. 两大关键特性
集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就象是一个服务实体，但事实上集群由一组服务实体组成。与单一服务实体相比较，集群提供了以下两个关键特性：
· 可扩展性--集群的性能不限于单一的服务实体，新的服务实体可以动态地加入到集群，从而增强集群的性能。
· 高可用性--集 群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出 错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。
2. 两大能力
为了具有可扩展性和高可用性特点，集群的必须具备以下两大能力：
· 负载均衡--负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。
· 错误恢复--由于某种原因，执行某个任务的资源出现故障，另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。
负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图(信息上下文)必须是一样的。
3. 两大技术
实现集群务必要有以下两大技术：
· 集群地址--集 群由多个服务实体组成，集群客户端通过访问集群的集群地址获取集群内部各服务实体的功能。具有单一集群地址(也叫单一影像)是集群的一个基 本特征。维护集群地址的设置被称为负载均衡器。负载均衡器内部负责管理各个服务实体的加入和退出，外部负责集群地址向内部服务实体地址的转换。有的负载均 衡器实现真正的负载均衡算法，有的只支持任务的转换。只实现任务转换的负载均衡器适用于支持ACTIVE-STANDBY的集群环境，在那里，集群中只有 一个服务实体工作，当正在工作的服务实体发生故障时，负载均衡器把后来的任务转向另外一个服务实体。
· 内部通信--为了能协同工作、实现负载均衡和错误恢复，集群各实体间必须时常通信，比如负载均衡器对服务实体心跳测试信息、服务实体间任务执行上下文信息的通信。
具有同一个集群地址使得客户端能访问集群提供的计算服务，一个集群地址下隐藏了各个服务实体的内部地址，使得客户要求的计算服务能在各个服务实体之间分布。内部通信是集群能正常运转的基础，它使得集群具有均衡负载和错误恢复的能力。
集群分类
Linux集群主要分成三大类( 高可用集群， 负载均衡集群，科学计算集群)，高可用集群( High Availability Cluster)，负载均衡集群(Load Balance Cluster)，科学计算集群(High Performance Computing Cluster)
具体包括：
Linux High Availability 高可用集群：普通两节点双机热备，多节点HA集群，RAC, shared, share-nothing集群等；Linux Load Balance 负载均衡集群：LVS等....；Linux High Performance Computing 高性能科学计算集群：Beowulf 类集群....；分布式存储；其他类linux集群：如Openmosix, rendering farm 等..
详细介绍
1. 高可用集群(High Availability Cluster)
常见的就是2个节点做成的HA集群，有很多通俗的不科学的名称，比如"双机热备", "双机互备", "双机".
高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的，保护的是用户的业务程序对外不间断提供服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)。
2. 负载均衡集群(Load Balance Cluster)
负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。
负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。
3. 科学计算集群(High Performance Computing Cluster)
高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。
高性能计算分类
高吞吐计算(High-throughput Computing)
有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。象在家搜寻外星人( SETI@HOME -- Search for Extraterrestrial Intelligence at Home )就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上 参加SETI的计算节点，计算节点在给定的数据上用给定的模式进行搜索，然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的 数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照 Flynn的分类，高吞吐计算属于SIMD(Single Instruction/Multiple Data)的范畴。
分布计算(Distributed Computing)
另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。按照Flynn的分类，分布式的高性能计算属于MIMD(Multiple Instruction/Multiple Data)的范畴。
4. 分布式(集群)与集群的联系与区别
分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务。分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。
举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。
而分布式，从窄意上理解，也跟集群差不多， 但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。
分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。
传统MySQL+ Memcached架构遇到的问题
实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：
1.MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。
2.Memcached与MySQL数据库数据一致性问题。
3.Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。
4.跨机房cache同步问题。
众多NoSQL百花齐放，如何选择
最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实 际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几 种问题
1.少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。
2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。
3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。
4.Schema free，auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。
面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。
Redis适用场景，如何正确的使用
前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功 能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用 Memcached,何时使用Redis呢?
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2 Redis支持数据的备份，即master-slave模式的数据备份。
3 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。Redis只会缓存所有的 key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以 保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。
使用Redis特有内存模型前后的情况对比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行 批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。
补充的知识点：
memcached和redis的比较
1 网络IO模型
Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接描述字 pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。
(Memcached网络IO模型)
Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯 只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重 影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。
2.内存管理方面
Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方 式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔 除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储 命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非 临时数据(但会尝试剔除部分临时数据)，这点上Redis更适合作为存储而不是cache。
3.数据一致性问题
Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。
4.存储方式及其它方面
Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能
Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS
进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。
5.关于不同语言的客户端支持
在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客 户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应 第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。
根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。
关于Redis的一些周边功能
Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清楚地 了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的，又比 如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。
总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。
总结：
1.Redis使用最佳方式是全部数据in-memory。
2.Redis更多场景是作为Memcached的替代者来使用。
3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
4.当存储的数据不能被剔除时，使用Redis更合适。
开源大数据框架Apache Hadoop已经成了大数据处理的事实标准，同时也几乎成了大数据的代名词，虽然这多少有些以偏概全。
根据Gartner的估计，目前的Hadoop生态系统市场规模在7700万美元左右，2016年，该市场规模将快速增长至8.13亿美元。
但是在Hadoop这个快速扩增的蓝海中游泳并非易事，不仅开发大数据基础设施技术产品这件事很难，销售起来也很难，具体到大数据基础设施工具如 Hadoop、NoSQL数据库和流处理系统则更是难上加难。客户需要大量培训和教育，付费用户需要大量支持和及时跟进的产品开发工作。而跟企业级客户打 交道往往并非创业公司团队的强项。此外，大数据基础设施技术创业通常对风险投资规模也有较高要求。
尽管困难重重，Hadoop创业公司依然如雨后春笋冒出，除了Cloudera、Datameer、DataStax和MapR等已经功成名就的 Hadoop创业公司外，最近CIO杂志评出了2014年十大最值得关注的Hadoop创业公司，了解这些公司的产品和商业模式对企业大数据技术创业者和 大数据应用用户来说都非常有参考价值：
一、Platfora
业务：所提供的大数据分析解决方案能够将Hadoop中的原始数据转换成可互动的，基于内存计算的商业智能服务。
简介：创立于2011年，迄今已募集6500万美元。
入选理由：Platfora的目标是简化复杂难用的Hadoop，推动Hadoop在企业市场的应用。Platfora的做法是简化数据采集和分析 流程，将Hadoop中的原始数据自动转化成可以互动的商业智能服务，无需ETL或者数据仓库。(参考阅读：Hadoop只是穷人的ETL)
二、Alpine Data Labs
业务：提供基于Hadoop的数据分析平台
简介：创立于2010年，迄今累计融资2350万美元。
入选理由：复杂的高级分析和机器学习应用通常都需要脚本和代码开发高手实现，这进一步推高了数据科学家的技术门槛。实际上大数据企业高管和IT经理都没时间也没兴致学习编程技术，或者去了解复杂的Hadoop。Alpine Data通过SaaS服务的方式大幅降低了预测分析的应用门槛。
三、Altiscale
业务：提供Hadoop即服务（HaaS）
简介：创立于2012年3月，迄今融资1200万美元。
入选理由：大数据正在闹人才荒，而通过云计算提供Hadoop相关服务无疑是普及Hadoo的一条捷径，根据TechNavio的估计，2016年 HaaS市场规模将高达190亿美元，是块大蛋糕。但是HaaS市场的竞争已经日趋激烈，包括亚马逊EMR、微软的Hadoop on Azure，以及Rackspace的Hortonworks云服务等都是重量级玩家，Altiscale还需要与Hortonworks、 Cloudera、Mortar Data、Qubole、Xpleny展开直接竞争。
四、Trifacta
业务：提供平台帮助用户将复杂的原始数据转化成干净的结构化格式供分析使用。
简介：创立于2012年，迄今融资1630万美元。
入选理由：大数据技术平台和分析工具之间存在一个巨大的瓶颈，那就是数据分析专家需要花费大量精力和时间转化数据，而且业务数据分析师们往往也并不 具备独立完成数据转化工作的技术能力。为了解决这个问题Trifacta开发出了“预测互动”技术，将数据操作可视化，而且Trifacta的机器学习算 法还能同时观察用户和数据属性，预测用户意图，并自动给出建议。Trifata的竞争对手是Paxata、Informatica和CirroHow。
五、Splice Machine
业务：提供面向大数据应用的，基于Hadoop的SQL兼容数据库。
简介：创立于2012年，迄今融资1900万美元。
入选理由：新的数据技术使得传统关系型数据库的一些流行功能如ACID合规、交易一致性和标准的SQL查询语言等得以在廉价可扩展的Hadoop上 延续。Splice Machine保留了NoSQL数据库所有的优点，例如auto-sharding，容错、可扩展性等，同时又保留了SQL。
六、DataTorrent
业务：提供基于Hadoop平台的实时流处理平台
简介：创立于2012年，2013年6月获得800万美元A轮融资。
入选理由：大数据的未来是快数据，而DataTorrent正是要解决快数据的问题。
七、Qubole
业务：提供大数据DaaS服务，基于“真正的自动扩展Hadoop集群”。
简介：创立于2011年，累计融资700万美元。
入选理由：大数据人才一将难求，对于大多数企业来说，像使用SaaS企业应用一样使用Hadoop是一个现实的选择。
八、Continuuity
业务：提供基于Hadoop的大数据应用托管平台
简介：创立于2011年，累计获得1250万美元融资，创始人兼CEO Todd Papaioannou曾是雅虎副总裁云架构负责人，去年夏天Todd离开Continuuity后，联合创始人CTO Jonathan Gray接替担任CEO一职。
入选理由：Continuuity的商业模式非常聪明也非常独特，他们绕过非常难缠的Hadoop专家，直接向Java开发者提供应用开发平台，其 旗舰产品Reactor是一个基于Hadoop的Java集成化数据和应用框架，Continuuity将底层基础设施进行抽象处理，通过简单的Java 和REST API提供底层基础设施服务，为用户大大简化了Hadoop基础设施的复杂性。Continuuity最新发布的服务——Loom是一个集群管理方案，通 过Loom创建的集群可以使用任意硬件和软件堆叠的模板，从单一的LAMP服务器和传统应用服务器如JBoss到包含数千个节点的大规模的Hadoop集 群。集群还可以部署在多个云服务商的环境中（例如Rackspace、Joyent、Openstack等）而且还能使用常见的SCM工具。
九、Xplenty
业务：提供HaaS服务
简介：创立于2012年，从Magma风险投资获得金额不详的融资。
入选理由：虽然Hadoop已经成了大数据的事实工业标准，但是Hadoop的开发、部署和维护对技术人员的技能依然有着极高要求。Xplenty 的技术通过无需编写代码的Hadoop开发环境提供Hadoop处理服务，企业无需投资软硬件和专业人才就能快速享受大数据技术。
十、Nuevora
业务：提供大数据分析应用
简介：创立于2011年，累计获得300万早期投资。
入选理由：Nuevora的着眼点是大数据应用最早启动的两个领域：营销和客户接触。Nuevora的nBAAP（大数据分析与应用）平台的主要功 能包括基于最佳时间预测算法的定制分析应用，nBAAP基于三个关键大数据技术：Hadoop（大数据处理）、R（预测分析）和Tableau（数据可视 化）
作为一位设计师，会经常追寻新鲜有趣的设计工具，这些工具会提高工作的效率，使得工作更有效， 最重要的是使工作变得更方便。非常肯定的说，随着日益增长的工具和应用的数量，设计和开发变得越来越简单了。其中最普遍使用的最终框架 之一是 Bootstrap，它在 2013 年特别流行。如果你是位设计师，你可能会接触过它，甚至是使用过它。如果你是 Bootstrap 的使用者或者是相关功能的用户，这篇文章非常的适合你！
这里总共列举了 12 款最好的 Bootstrap 设计工具，这些都能很好的简化大家的工作。希望大家能从这些列表中找到适合自己的，在评论跟大家分享一下使用的感想和其他类似的工具，Enjoy ：）
Bootstrap Designer 是一个在线工具，不需要下载就可以使用。用户可以使用它创建漂亮和迷人基于 Bootstrap 框架的 HTML5 模板。
如果用户想结合先进高级的 web 技术和 Bootstrap，可以尝试一下 Get Kickstrap。这款特别的工具非常高大上，可以运行数据库驱动的 web 应用程序，而且还不用任何的后台哦 ：D
这个工具拥有非常多样化的库，集成了其他 Bootstrap 基础插件，框架和库。
这个特别的工具能帮助用户轻松创建各种类型的按钮，用户只需要输入 CSS 类到新的按钮中，并且选择相应的颜色值就可以了。当需要使用的时候，只需要复制粘贴就能轻松创建漂亮的按钮了。
这个工具能在浏览器中运行，这个非常基础的工具能帮助在小团队工作的开发者和设计者建立非常真实的 web 元素。
用户只需要使用拖拽界面构建器就可以轻松创建前端代码。
这是一个开源的工具，而且非常容易安装和使用。
这是一款在线主题生成器和 Twitter Bootstrap 的 web 设计工具。用户可以在设计 webapp 时生成和预览主题。
这个特别的工具允许用户创建非常个性化的字体，通过非常舒适的命令行方式。
这是另外一个基于 CSS 的 Twitter Bootstrap，让用户能很好的在 WordPress 网站上使用 Twitter Bootstrap JavaScript 库。
这是个非常灵活和简单的框架，用户可以创建现代化和经典的 web 应用。同时，也可以定义类似 Windows 8 的风格和感觉。
这是另外一个基于 Twitter Bootstrap 的工具，可以运行一个平滑风格，组件可以包含 PSD 文件的 UI。使用这个特殊的工具可以创建出非常有创意的 UI。
摘要: 在本次教程中，我们将创建含有三个节点的群集。第一个节点是主节点，第二个节点是Failover节点，第三个节点是仲裁节点。1. 安装Mongo并设置配置文件安装3台服务器并调整配置文件/etc/mongod.conf:1#Select your replication set name2replSet=[replication_set_name]3#Selec...
阅读全文
- 下载KAFKA
wget http://apache.fayea.com/apache-mirror/kafka/0.8.1.1/kafka_2.9.2-0.8.1.1.tgz
- 解压
tar -zxf kafka_2.9.2-0.8.1.1.tgz
- 0.7之前的版本这时就要安装相应的包之类的，0.8.1之后就不用了。把命令加进PATH中
export KAFKA_HOME=/home/ubuntu/java/kafka_2.9.2-0.8.1.1
export PATH=$JAVA_HOME/bin:$STORM_HOME/bin:$KAFKA_HOME/bin:$ZOOKEEPER_HOME/bin:$BIN_HOME/bin:$MAVEN_HOME/bin:$PATH
- SOURCE一下
source /etc/profile
- 制作启动命令，start-kafka.sh，并放于kafaka_hoem/bin下
kafka-server-start.sh $KAFKA_HOME/config/server.properties &
- 安装ZOOKEEPER
wget http://mirrors.hust.edu.cn/apache/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz
tar -zxf zookeeper-3.4.6.tar.gz
cd zookeeper-3.4.6.tar.gz/conf
cp zoo_sample.cfg zoo.cfg
- 改zoo.cfg
dataDir=$ZOOKEEPER_HOME/data
#方便查LOG
dataLogDir=$ZOOKEEPER_HOME/logs
#控制客户的连接数，默认数为60，太少
maxClientCnxns=300
#如果有多个ZOOKEEPER INSTANCE时
server.1=10.120.151.223:2888:3888
server.2=10.120.151.224:2888:3888
- 启动ZOOKEEPER
zkServer.sh start
- 更改KAFKA的配置文件server.properties， 主要改几个地方
#这个是配置PRODUCER/CONSUMER连上来的时候使用的地址
advertised.host.name=54.72.4.92
#设置KAFKA LOG路径
log.dirs=$KAFKA_HOME/logs/kafka-logs
#设置ZOOKEEPER的连接地址
zookeeper.connect=54.72.4.92:2181
- 启动KAFKA
start-kafka.sh
- 新建一个TOPIC
#KAFKA有几个，replication-factor就填几个
kafka-topics.sh --create --topic kafkatopic --replication-factor 1 --partitions 1 --zookeeper localhost:2181
- 发送消息至KAFKA
kafka-console-producer.sh --broker-list localhost:9092 --sync --topic kafkatopic
- 另开一个终端，显示消息的消费
kafka-console-consumer.sh --zookeeper localhost:2181 --topic kafkatopic --from-beginning
- 在发送消息的终端输入aaa，则可以在消费消息的终端显示
http://stackoverflow.com/questions/15010420/storm-topology-rebalance-using-java-code使用Nimbus获取STORM的信息
http://www.andys-sundaypink.com/i/retrieve-storm-cluster-statistic-from-nimbus-java-mode/TSocket tsocket = new TSocket("localhost", 6627);
TFramedTransport tTransport = new TFramedTransport(tsocket);
TBinaryProtocol tBinaryProtocol = new TBinaryProtocol(tTransport);
Nimbus.Client client = new Nimbus.Client(tBinaryProtocol);
String topologyId = "test-1-234232567";
try {
tTransport.open();
ClusterSummary clusterSummary = client.getClusterInfo();
StormTopology stormTopology = client.getTopology(topologyId);
TopologyInfo topologyInfo = client.getTopologyInfo(topologyId);
List<ExecutorSummary> executorSummaries = topologyInfo.get_executors();
List<TopologySummary> topologies = clusterSummary.get_topologies();
for(ExecutorSummary executorSummary : executorSummaries){
String id = executorSummary.get_component_id();
ExecutorInfo executorInfo = executorSummary.get_executor_info();
ExecutorStats executorStats = executorSummary.get_stats();
System.out.println("executorSummary :: " + id + " emit size :: " + executorStats.get_emitted_size());
}
} catch (TTransportException e) {
e.printStackTrace();
} catch (TException e) {
e.printStackTrace();
} catch (NotAliveException e) {
e.printStackTrace();
}
STORM是一个消息处理引擎，可以处理源源不断的进来的消息，这些消息的处理是可以按步骤的。
处理的方式有各种自定义：
- 可自定义消息处理的步骤
- 可自定义每种类型的消息需要多少个进程来处理
- 每个步骤里的消息是在某个进程里的线程来做处理的
- 可自定义每个步骤里的消息的线程数
- 可以增加和删除要处理的消息类型
如果要处理某种消息了，要怎么办呢？
- 定义数据来源组件(SPOUT)
- 定义处理步骤(BOLT)
- 组合成一个消息处理流程框架TOPOLOGY
- 定义处理消息的进程的数量、定义每个步骤并发时可用的线程数
- 部署TOPOLOGY
当一个TOPOLOGY被部署到STORM时，STORM会查找配置对象的WORKER数量，根据这个数量相应的启动N个JVM，然后根据每个步骤配置的NUMTASKS生成相应个数的线程，然后每个步骤中配置的数量实例化相应个数的对象，然后就启动一个线程不断的执行SPOUT中的nextTuple()方法，如果这个方法中有输出结果，就启动另一线程，并在此线程中将这个结果作为参数传到下一个对象的excue方法中。
如果此时又有一个步骤BOLT需要执行的话，也是新取一个线程去执行BOLT中的方法启动的线程不会越过NUMTASKS的数量。