#
传统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的数量。
The configuration is used to tune various aspects of the running topology. The two configurations specified here are very common:
- TOPOLOGY_WORKERS (set with
setNumWorkers) specifies how many processes you want allocated around the cluster to execute the topology. Each component in the topology will execute as many threads. The number of threads allocated to a given component is configured through the setBolt and setSpout methods. Those threadsexist within worker processes. Each worker process contains within it some number of threads for some number of components. For instance, you may have 300 threads specified across all your components and 50 worker processes specified in your config. Each worker process will execute 6 threads, each of which of could belong to a different component. You tune the performance of Storm topologies by tweaking the parallelism for each component and the number of worker processes those threads should run within.
- TOPOLOGY_DEBUG (set with
setDebug), when set to true, tells Storm to log every message every emitted by a component. This is useful in local mode when testing topologies, but you probably want to keep this turned off when running topologies on the cluster.
There's many other configurations you can set for the topology. The various configurations are detailed on the Javadoc for Config.
Common configurations
There are a variety of configurations you can set per topology. A list of all the configurations you can set can be found here. The ones prefixed with "TOPOLOGY" can be overridden on a topology-specific basis (the other ones are cluster configurations and cannot be overridden). Here are some common ones that are set for a topology:
- Config.TOPOLOGY_WORKERS: This sets the number of worker processes to use to execute the topology. For example, if you set this to 25, there will be 25 Java processes across the cluster executing all the tasks. If you had a combined 150 parallelism across all components in the topology, each worker process will have 6 tasks running within it as threads.
- Config.TOPOLOGY_ACKERS: This sets the number of tasks that will track tuple trees and detect when a spout tuple has been fully processed. Ackers are an integral part of Storm's reliability model and you can read more about them onGuaranteeing message processing.
- Config.TOPOLOGY_MAX_SPOUT_PENDING: This sets the maximum number of spout tuples that can be pending on a single spout task at once (pending means the tuple has not been acked or failed yet). It is highly recommended you set this config to prevent queue explosion.
- Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS: This is the maximum amount of time a spout tuple has to be fully completed before it is considered failed. This value defaults to 30 seconds, which is sufficient for most topologies. SeeGuaranteeing message processing for more information on how Storm's reliability model works.
- Config.TOPOLOGY_SERIALIZATIONS: You can register more serializers to Storm using this config so that you can use custom types within tuples.
Reference:
http://storm.incubator.apache.org/documentation/Running-topologies-on-a-production-cluster.htmlstorm rebalance 命令调整topology并行数及问题分析
http://blog.csdn.net/jmppok/article/details/17243857flume+kafka+storm+mysql 数据流
http://blog.csdn.net/jmppok/article/details/17259145http://storm.incubator.apache.org/documentation/Tutorial.html