设为首页 收藏本站
云服务器等爆品抢先购,低至4.2元/月
查看: 940|回复: 0

[经验分享] kafka 学习点滴<一>

[复制链接]

尚未签到

发表于 2017-5-23 16:49:21 | 显示全部楼层 |阅读模式
处理机制:

首先我要分为以下几点来描述一下我对kafka运行机制的了解:

1.连接kafka: kafka是一个分布式消息分发系统,建议连接servers中指定大于2个的“host:port,host:port”. 可以降低kafka server失联。
    例如: 张一和张二是好朋友, 他们在不同的城市上班,如果张一的手机被偷了。那么张二就没办法联系到张一(连接出现异常), 如果把张一的朋友圈当作
    是一个集群的话,张二拥有1个或多个张一朋友的电话号码,这样张一就不容易失联了。

2.kafka Client端: 在kafka的官方文档中有提出如何配置client的缓存策略、与server的确认策略等等,有很多
   client与servier的配置,例如kafka并不是100%保证消息不丢失的, 除非你的配置很严格(例如 acks=all),
   但是那样会严重影响client端的处理能力,同时也极大增加kafka server node之间通信及负载压力(这个也与你的备份策略有关),
   Client 发送数据的流程是:首先存储在本地的缓存当中,本地的缓存信息会被一次一次批量的发送到kafka server中 ,
        相关配置可以有buffer.memory  compression.type等等。
              buffer.memory: producer 会用  buffer.memory 大小的缓存来缓存数据,当数据发送到server的速度小于 客户端send的速度时,
                                          会产生两种可能: 阻塞、抛出异常, 这两种可能是由 block.on.buffer.full 配置决定,如果block.on.buffer.full=true, 代表阻塞,否者就是抛出异常。
                                         
                                这里提出2个值得测试的问题:
                                         (1).直接调用的kafka Client的客户端机器也会被缓存数据,如果因为kafka server异常导致大量阻塞的话,那就会导致当前程序死掉、挂起、内存泄露
                                          
                                          (2).从代码设计的角度分析, 我觉得任何采集日志代码直接调用kafka client是不合理的。因为kafka Client 和 kafka server就好比是两道缓冲区。
                                                彼此相互影响。你的代码影响了kafka Client, 就一定会影响kafka server。

              compression.type:压缩类型, 用来压缩所有由producer产生的数据(The compression type for all data generated by the producer ),默认是none

3.kafka server接收数据
        当kafka server接收到消息之后,会根据partition计算策略,将消息分割为多个partition, partition是replicated一个单位。且一个partition会被完整的存储在一个节点上。
        partition的另一个作用是起到:balancing load。(我会4.中提到),还有一个作用是,它也是多个consumers顺序消费的独立单位。
        之后,kafka 会直接将数据写入磁盘, 看了kafka作者对“写入磁盘,就一定影响效率吗?”分析描述。所以大可放心, 现在的文件系统IO已经相当成熟,并且性能也已经得到很大的提高。
        例如:传统的IO方式是要经历4个过程才能入盘。kafka的IO解决方案只需要1步就可以入盘(我记得好像是1步)。在加上kafka的消息订阅都是顺序读取,所以速度相当快。
        所以kafka几乎不会将消息数据存入内存。kafka是以log日志的方式存放消息数据的。
      kafka的消息是有过期时间的(记得文档上说是默认两天,我记不起来了)。过期的消息就会被自动删除。
         关于这点我想提出两个问题
          1、什么叫过期消息?
               我的理解是:
                 超过指定的时间,就一定会变成过期数据,接着就会被自动删除
          2、什么才会导致消息过期?
              我的理解是:
                我这里不关心已经消费的数据。我们谈谈未消费的数据可不可能变成过期数据,这在我们的业务当中叫做消息丢失!举个例子,当我们的consumers调用端
                端程序发生异常、阻塞、消费太慢等等条件,kafka就会重复发送(应该是可配的)。可是kafka server的接收消息很快,这样很有可能会导致大量的未读消息过期
                    
4.Consumers 消费数据
           之前我们提过:“消息是以partition为单位存储的,一个partition会被完整的存储在一个集群节点上。而且发送消息也是基于topic发送的”。
     以下是我对consumers的理解:
             kafka可以保证Consumers接收消息的顺序,例如producer连续发了两个消息:message1、message2,那么不管是queuing模式 还是 publish-subscribe模式,     
              Consumers接收到的消息顺序都是message1、message2(这一点让我想到了zookeeper的一些机制)。那具体是怎么做到的呢? 首先kafka会记录
              每一个partition的位置,一个消  
息可以有多个partition。在单个
消息完整性方面,kafka可以保证每一个相关partition位置的准确性、一致性。当一个或多个Consumers去订阅一个topic时。Kafka is able to provide both ordering guarantees and
load balancing over a pool of consumer processes(这句英文仿佛更能描述问题)。接下来顺序的将每一个消息的所有partition传递给every one of consumer processes。
读完之后、且Consumers满意之后(也就是调用Consumers的代码未发生异常、或超时),当前的topic下的partition位置都会移动到下一个消息位置(我在3中有提到顺序读取)
  这里提出2个值的测试问题:
            (1).在 publish-subscribe模式下,如果其中一个Consumers发生问题,那么partition位置就会“回滚”, 但是其他的Consumers都成功,这样会不会导致其他的Consumers
                 重复接收

            (2).当Consumers的处理很耗时,那么会不会影响客户端send的速度。如果影响的话,那就会影响producer的吞吐量
、或者Client数据丢失(除非你对异常进行处理)

能做什么
   这里列出了官网的应用场景:
         1、Commit Log / Log Aggregation: 例如 集中 对分布式环境下的 日志收集
         2、Event Sourcing:可以作为一种事件发生源。该应用场景很多:下发通知、flume日志源、分布式交互、实时顺序队列(sequence)等等
         3、Stream Processing:流式处理,Consumers可以当做是流式处理中的一个处理单元(或者叫做节点)。可以当做storm使用。例如可以将从一个topic获取的消息处理完之后传递给另一个topic,这样另外一个Consumers或多个Consumers就可以继续处理。处理失败之后还会重新处理。
         4、Metrics: 例如分布式环境下,可以将 各个applications的实时监控、或者状态实时统计、汇总数据实时的发送到kafka server上,之后可以供任何应用系统订阅。
      
     等等。个人觉得它的应用场景非常广泛

如何提高高可用性、稳定性
   在大数据情况下,以下仅是我个人的观点:
     
     1、掌握kafka与我们实际应用相关的一些具体指标参数(例如在某某环境下,它的处理速度、效率到底什么样的),我觉得这些参数很重要,他会影响我们的架构设计。严重时
        会导致我们对基础服务代码的大量重构。
     2、以下是我对大数据情况下,个人理解中的kafka具体架构设计与部署图(如下图):
              kafka client 单独提出来的目的是:
                     (1)、充分应用kafka Client的缓存能力,平衡kafka集群的服务压力
                     (2)、提高“消息发送者" 的吞吐量.  因为kafka Client本身是异步的
                     (3)、提高可扩展性、配置灵活性:在适应环境的过程中,可以灵活方便的微调kafka Client 相关参数

DSC0000.jpg

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-379852-1-1.html 上篇帖子: kafka获得最新partition offset 下篇帖子: 消息系统kafka介绍
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表