标签：安全 文件中 map 大数 系统 场景 生态 kafka 消息
1. 使用同步模式的时候，有3中状态保证消息被安全生产， 在配置为1（只保证写入leader成功）的话，如果刚好leader partition挂了，数据就是丢失。
2. 还有一种情况可能会丢失小时， 就是使用异步模式的时候，当缓冲区满了，如果配置为0（还没有收到确认的情况下，缓冲池一满，就清空缓冲池里消息）， 数据就会被立即丢弃掉。
在数据生产时避免数据丢失的方法：
只要能避免上述两种情况， 那么就可以保证消息不会被丢失。
1. 就是说在同步模式的时候，确认机制设置为-1， 也就是让消息写入leader和所有的副本。
2. 还有， 在异步模式下， 如果消息发出去了， 但还没有收到确认的时候，缓冲池满了， 在配置文件中设置成不限制阻塞超时的时间，也就是让生产端一直阻塞， 这样也就能保证数据不会丢失。
在数据消费时，避免数据丢失的方法： 如果使用了storm， 要开启storm的ackfail机制； 如果没有使用storm ， 确认数据被完成处理之后， 再更新offset 值。 低级API中需要手动控制offset值。
数据重复消费的情况，如果处理：
1. 去重： 将消息的唯一标识保存到外部介质中， 每次消费处理时判断是否处理过。
2. 不管： 大数据场景中， 报表系统或者日志信息丢失几条都无所谓， 不会影响最终的统计分析结果。
顺序写入： 因为硬盘是机械结构， 每次读写都会寻址 ->写入， 其中寻址是一个“机械动作”， 它是最耗时的。 所以硬盘最“讨厌”随机 I/O， 最喜欢顺序 I/O, 为了提高读写硬盘的速度， Kafka就是使用顺序 I/O。
Kafka速度的秘诀在于， 它把所有的消息都变成一个的文件。 通过map提高 I/O 速度， 写入数据的时候它是末尾添加所以速度最优； 读取数据的时候配合sendfile 直接暴力输出。 阿里的RocketMQ也是这种模式， 只不过是用Java写的。
对于storm来讲：
1. 建议在那种需要纯实时， 不能忍受一秒以上延迟的场景下使用， 比如实时金融系统， 要求纯实时进行金融交易和分析
2. 此外， 如果对于实时计算的功能中， 要求可靠的事物机制和可靠性机制， 即数据的处理完全精确， 一条也不多，一条也不能少， 也可以考虑使用storm
3. 如果还需要针对高峰低峰时间段， 动态调整实时计算程序的并行度， 以最大限制利用集群资源（通常是在小型公司，集群资源紧张的情况），也可以考虑用storm。
4. 如果一个大数据应用系统，它就是纯粹的实时计算， 不需要在执行SQL交互式查询， 复杂的transformation算子等，那么用storm是比较好的选择。
对于sparkStreaming来讲：
1. 如果上述适用于Storm的三点， 一条也不满足实时场景，即不要求纯实时，不要求强大的事物机制， 不要求动态调整并行度， 那么可以考虑使用Spark Streaming
2. 考虑使用Spark Streaming 最主要的一个因素， 应该是针对整个项目进行宏观的考虑， 即， 如果一个项目除了实时计算之外， 还包括了离线批处理、交互式查询等业务功能， 而且实时计算中， 可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选spark生态， 用Spark Core开发离线批处理，用Spark SQL‘开发交互式查询， 用Spark Streaming开发实时计算，三者可以无缝整合， 给系统提供非常高的可扩展性。
四、Spark Streaming和 Storm的优劣分析
1. 事实上， spark Streaming 绝对谈不上比Storm优秀。 这两个框架在实时计算领域中，都很优秀， 只是擅长的细分场景并不相同。
2. Spark Streaming 仅仅在吞吐量上比Storm要优秀， 而吞吐量这一点， 也是历来挺Spark Streaming， 贬Storm的人着重强调的。 但是问题是， 是不是所有的实时计算场景下， 都那么注重吞吐量呢？ 因此通过说吞吐量将Spark Streaming强于Storm，不靠谱。
3. 事实上， Storm在实时延迟度上， 比Spark Streaming就好多了，前者是纯实时， 后者是准实时， 而且， Storm的事物机制，健壮性/ 容错性、动态调整并行度等特性， 都要比Spark Streaming更加优秀。
4. Spark Streaming， 有一点， Storm绝对比不上的， 就是： 它位于Spark生态技术栈中， 因此Spark Streaming可以和Spark Core 、Spark SQL无缝连接， 也就意味着， 我们可以对实时处理出来的中间数据， 立即在程序中无缝进行延迟批处理、交互式查询等操作， 这个特点大大增强了Spark Streaming 的优势和功能。
五、kafka阻塞如何排查
1、首先获取所有的topic列表
bin/kafka-topic.sh --list --zookeeper localhost:2181
2、查看某一个topic下的log文件和offset是不是一样（下一次单之后再次查看有没有变化， 应该是log文件和offset同时加1猜对， 如果不是同时加1 说明阻塞）
bin/kafka-run-class.sh
kafka.tools.consumerOffsetCheker --zookeeper localhost:2181 --group cxx.system --topic cxx.sub.topic
3、如果发生阻塞可以通过重启kafka来解决
首先关闭zookeeper， 再关闭kafka， 然后开启zookeeper， 再开启kafka
标签：安全 文件中 map 大数 系统 场景 生态 kafka 消息
原文地址：https://www.cnblogs.com/fjdsj/p/10095586.html
