一.kafka
Apache Kafka是一个开源消息系统，由Scala写成
Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。
l 无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性
kafka具有高的吞吐量内部采用消息的批量处理消息处理的效率很高。
kafka的组件介绍
Topic ：消息根据Topic进行归类
Producer：发送消息者
Consumer：消息接受者
broker：每个kafka实例(server)
Zookeeper：依赖集群保存meta信息。
Topics组件介绍
Topic：一类消息，每个topic将被分成多个partition(区)，在集群的配置文件中配置。
partition：在存储层面是逻辑append log文件，包含多个segment文件。
Segement：消息存储的真实文件，会不断生成新的。
offset：每条消息在文件中的位置（偏移量）。offset为一个long型数字，它是唯一标记一条消息。
partition
1、 在存储层面是逻辑append log文件，每个partition有多个segment组成。
2、 任何发布到此partition的消息都会被直接追加到log文件的尾部。
3、 每个partition在内存中对应一个index列表，记录每个segment中的第一条消息偏移。这样查找消息的时候，先在index列表中定位消息位置，再读取文件，速度块。
发布者发到某个topic的消息会被均匀的分布到多个part上，broker收到发布消息往对应part的最后一个segment上添加该消息。
partition分布
1、 partitions分区到不同的server上，一个partition保存在一个server上，避免一个server上的文件过大，同时可以容纳更多的consumer消费,有效提升并发消费的能力。
2、 这个server(如果保存的是partition的leader)负责partition的读写。可以配置备份。
3、 每个partition都有一个server为"leader"，负责读写，其余的相对备份机为follower，follower同步leader数据，负责leader死了之后的接管。n个leader均衡的分散在每个server上。
4、 partition的leader和follower之间监控通过zookeeper完成。
segment
1、 每个segment中存储多条消息，消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。
2、 当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到
3、 segment达到一定的大小（可以通过配置文件设定,默认1G）后将不会再往该segment写数据，broker会创建新的segment。
offset
offset是每条消息的偏移量。
segment日志文件中保存了一系列"log entries"(日志条目),每个log entry格式为"4个字节的数字N表示消息的长度" + "N个字节的消息内容";
每个日志文件都有一个offset来唯一的标记一条消息,offset的值为8个字节的数字,表示此消息在此partition中所处的起始位置.
每个partition在物理存储层面,有多个log file组成(称为segment).
segment file的命名为"最小offset".log.例如"00000000000.log";其中"最小offset"表示此segment中起始消息的offset.
配置文件
consumer端
partion buffer中，消息的条数达到阈值，将触发flush到磁盘
log.flush.interval.messages=10000
#消息buffer的时间，达到阈值，将触发flush到磁盘
log.flush.interval.ms=3000
#删除topic需要server.properties中设置delete.topic.enable=true否则只是标记删除
delete.topic.enable=true
producer端
设置发送数据是否需要服务端的反馈,有三个值0,1,-1
# 0: producer不会等待broker发送ack
# 1: 当leader接收到消息之后发送ack
同步还是异步发送消息，默认“sync”表同步，"async"表异步。异步可以提高发送吞吐量,
也意味着消息将会在本地buffer中,并适时批量发送，但是也可能导致丢失未发送过去的消息
producer.type=sync
# 在async模式下,当message被缓存的时间超过此值后,将会批量发送给broker,默认为5000ms
# 此值和batch.num.messages协同工作.
queue.buffering.max.ms = 5000
# 在async模式下,producer端允许buffer的最大消息量
# 无论如何,producer都无法尽快的将消息发送给broker,从而导致消息在producer端大量沉积
# 此时,如果消息的条数达到阀值,将会导致producer端阻塞或者消息被抛弃，默认为10000
queue.buffering.max.messages=20000
# 如果是异步，指定每次批量发送数据量，默认为200
batch.num.messages=500
# 当消息在producer端沉积的条数达到"queue.buffering.max.meesages"后
# 阻塞一定时间后,队列仍然没有enqueue(producer仍然没有发送出任何消息)
# 此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制"阻塞"的时间
# -1: 无阻塞超时限制,消息不会被抛弃
# 0:立即清空队列,消息被抛弃
queue.enqueue.timeout.ms=-1
kafka如何保证数据的不丢失
生产者如何保证数据的不丢失
kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到
如果是同步模式：ack机制能够保证数据的不丢失，如果ack设置为0，风险很大，一般不建议设置为0
producer.type=sync
request.required.acks=1
# -1: 当所有的follower都同步消息成功后发送ack.
request.required.acks=0
如果是异步模式：通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，如果设置的是立即清理模式，风险很大，一定要设置为阻塞模式
结论：producer有丢数据的可能，但是可以通过配置保证消息的不丢失
producer.type=async 异步模式
request.required.acks=1 需要ack校验机制
queue.buffering.max.ms=5000 队列最大缓存时间大一些5秒
queue.buffering.max.messages=10000 队列最大缓存消息数量大些10000
queue.enqueue.timeout.ms = -1 进入队列超时时间设置为永不超时
batch.num.messages=200 每一批处理消息的数量设置小些200
消费者如何保证数据的不丢失
通过offset commit 来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，接着上次的offset进行消费即可
集群监控工具
ganglia
二.storm
Storm是一个开源的分布式实时计算系统，可以简单、可靠的处理大量的数据流
storm的架构
1. Nimbus：负责资源分配和任务调度。新版本中的nimbus节点可以有多个，做主备
2. Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程。
3. Worker：运行具体处理组件逻辑的进程。
4. Task：worker中每一个spout/bolt的线程称为一个task. 在storm0.8之后，task不再与物理线程对应，同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor。最新版本的Jstorm已经废除了task的概念
N台机器启动storm服务
nohup bin/storm nimbus >/dev/null 2>&1 &
storm的编程模型
DataSource：外部数据源
Spout：接受外部数据源的组件，将外部数据源转化成Storm内部的数据，以Tuple为基本的传输单元下发给Bolt
Bolt:接受Spout发送的数据，或上游的bolt的发送的数据。根据业务逻辑进行处理。发送给下一个Bolt或者是存储到某种介质上。介质可以是mongodb或mysql，或者其他。
Tuple：Storm内部中数据传输的基本单元，里面封装了一个List对象，用来保存数据。
StreamGrouping:数据分组策略
7种：shuffleGrouping(Random函数),
Non Grouping(Random函数),
FieldGrouping(Hash取模)、
Local or ShuffleGrouping 本地或随机，优先本地。
其中Local or ShuffleGrouping 是如果分组的时候接收bolt的线程和发送者在一个JVM中默认优先选择一个JVM中的bolt就是local，否则和ShuffleGrouping效果一样。
storm的并行度
Storm当中的worker，executor，task之间的相互关系
Worker：表示一个进程
Executor：表示由worker启动的线程
一个worker只会负责一个topology任务，不会出现一个worker负责多个topology任务的情况。
一个worker进程当中，可以启动多个线程executor，也就是说，一个worker进程可以对应多个executor线程
task 是实际执行数据处理的最小工作单元（注意，task 并不是线程）默认情况下 Storm 会在每个线程上运行一个 task
调整task的数量，并不能够实际上提高storm的并行度，因为storm不管是spout还是bolt当中的代码都是串行执行的，就算一个executor对应多个task，这多个task也是串行去执行executor当中的代码，所以这个调整task的个数，实际上并不能提高storm的并行度
在实际工作当中，由于spout与bolt的数量不能够精准确定，所以需要随时调整spout与bolt的数量，所以在storm当中，我们可以通过命令来动态的进行调整
storm rebalance mytopo -n 3 -e mySpout=5 -e splitBolt=6 -e countBolt=8
一定要注意：重新调整的时候=号两边不要有空格
实时看板案例
支付系统+kafka+storm/Jstorm集群+redis集群
redis key value型基于内存的nosql数据库
常用5种数据类型
一：字符串类型string
二：散列类型hash
三：列表类型（list）
内部使用双向链表实现，所以获取越接近两端的元素速度越快，但通过索引访问时会比较慢
四：集合类型（set）
集合类型值具有唯一性，常用操作是向集合添加、删除、判断某个值是否存在，集合内部是使用值为空的散列表实现的。
五：有序集合类型
storm原理
Storm启动流程分析
1、客户端运行storm nimbus时，会调用storm的python脚本，该脚本中为每个命令编写一个方法
2、nibums启动之后，接受客户端提交任务
3、nimbus接受到任务之后，会将任务进行分配，分配会产生一个assignment对象，该对象会保存到zk中
4、supervisor通过watch机制，感知到nimbus在zk上的任务分配信息，从zk上拉取任务信息，分辨出属于自己任务。
5、supervisor 根据自己的任务信息，启动自己的worker，并分配一个端口。
6、worker启动之后，连接zk，拉取任务
7、worker根据任务类型，分别执行spout任务或者bolt任务。
消息不丢失机制
通过Ack机制，很容易做到保证所有数据均被处理，一条都不漏。
另外需要注意的，当spout触发fail动作时，不会自动重发失败的tuple，需要spout自己重新获取数据，手动重新再发送一次
ack机制即， spout发送的每一条消息，
l 在规定的时间内，spout收到Acker的ack响应，即认为该tuple 被后续bolt成功处理
l 在规定的时间内，没有收到Acker的ack响应tuple，就触发fail动作，即认为该tuple处理失败，
l 或者收到Acker发送的fail响应tuple，也认为失败，触发fail动作
另外Ack机制还常用于限流作用： 为了避免spout发送数据太快，而bolt处理太慢，常常设置pending数，当spout有等于或超过pending数的tuple没有收到ack或fail响应时，跳过执行nextTuple， 从而限制spout发送数据。
通过conf.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, pending);设置spout pend数。
这个timeout时间可以通过Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS来设定。Timeout的默认时长为30秒
如何使用Ack机制
spout 在发送数据的时候带上msgid
设置acker数至少大于0；Config.setNumAckers(conf, ackerParal);
在bolt中完成处理tuple时，执行OutputCollector.ack(tuple), 当失败处理时，执行OutputCollector.fail(tuple);
推荐使用IBasicBolt， 因为IBasicBolt 自动封装了OutputCollector.ack(tuple), 处理失败时，抛出FailedException，则自动执行OutputCollector.fail(tuple)
对于spout，有ISpout，IRichSpout，BaseRichSpout
对于bolt，有IBolt，IRichBolt，BaseRichBolt，IBasicBolt，BaseBasicBolt
IBasicBolt，BaseBasicBolt不用每次execute完成都写ack/fail，因为已经帮你实现好了
storm的定时器以及与mysql的整合使用
日志监控告警系统
getComponentConfiguration()
第一步：导入jar包
第二步：创建数据库表
第三步：开发我们的定时任务
第四步：开发我们的规则匹配bolt
第五步：开发我们的短信与邮件通知bolt
第六步：开发我们的数据库保存bolt
第七步：程序入口主函数
路由器数据监控
数据类型梳理
扫一扫
1147
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
