精华内容
下载资源
问答
  • 在我们的开发过程中,会经常遇到kafka消费能力低,导致消费堆积的问题,kafka默认的消息保存有效期是7天,7天后消息自动过期(无论是否消费),此时我们可以通 1)加大处理线程数量 或者起多节点去消费 2 )优化处理...

    引子

    • 在我们的开发过程中,会经常遇到kafka消费能力低,导致消费堆积的问题,kafka默认的消息保存有效期是7天,7天后消息自动过期(无论是否消费),此时我们可以通
      1)加大处理线程数量 或者起多节点去消费 2 )优化处理逻辑,提高处理效率
      这个提高kafka消费能力的方法,百度上已有很多博客有讲,我就不在写出来了。 但我要说的是另一个方面:kafka消费降速

    需要降速缘由

    # 需要降速缘由

    • 缘由:公司的kafka消费工程一直在消费,但是业务时不时更新用户数据,导致在用户高峰期突然丢过来千万基本kafka消息,导致kafka消费,影响到了正常用户的用户体验,如接口影响超时,导致用户体验不好。

      当然业务操作避免用户高峰期,这个是可以解决的,但是这次我是想从技术的层面上进行解决问题。

    解决方案

    解决方案
    1)减少节点数量,高峰期消费节点由原来的6个减少为2个,已降低消费速率(注:这个需要系统管理员进行手工操作,长期操作并不可取)
    2)调整线程池中线程的数量。
    3)kafka层面上:
    可以通过适当减小
    max.poll.records,max.poll.interval.ms,max.partition.fetch.bytes的值来降低kafka的消费速率。

    减少节点数量

    • 在减小节点的数量时,要认真观察生产区上kafak消息的生产速率和消费的速率,要保证减小节点后,堆积的消费量很少,或者最起码堆积的消费要在7天内能被消费完(注:7天)

    调整线程池中线程的数量

    • 通过压测确定业务系统消费kafka消息的瓶颈。从而设置合理的线程数量。例如我公司在启用了线程 最小的线程数是5 最大是10,
      其了6个节点去消费数据,在不减小节点的情况下,经过压测发现最大7个线程的情况下,在业务高峰期不影响到用户的操作,故调整最大线程调整为7。

    调整kafka消费端参数

    我们看下较官方的对三个字段的解释:

    • max.poll.records:这个参数用来配置 Consumer
      在一次拉取请求中拉取的最大消息数,默认值为500(条)。如果消息的大小都比较小,*则可以适当调大这个参数值来提升一定的消费速度。(既然调大可以提升消费速度,那么适当减小就可以降低消费速度,注:这个调整前,一定要计算业务的生产消费的速度,避免产生消息堆积)。

    关于:max. poll. interval. ms

    • max. poll. interval. ms <= 处理逻辑最大时间
      这个参数是0.10.1.0版本后新增的,可能很多地方看不到喔。这个参数需要根据实际业务处理时间进行设置,一旦Consumer处理不过来,就会被踢出Consumer
      Group 注意:如果业务平均处理逻辑为1分钟,那么max. poll. interval.
      ms需要设置稍微大于1分钟即可,但是session. timeout. ms可以设置小一点(如10s),用于快速检测Consumer崩溃。

    max.partition.fetch.bytes:

    • 这个参数用来配置从每个分区里返回给 Consumer 的最大数据量,默认值为1048576(B),即1MB。这个参数与
      fetch.max.bytes
      参数相似,只不过前者用来限制一次拉取中每个分区的消息大小,而后者用来限制一次拉取中整体消息的大小。同样,如果这个参数设定的值比消息的大小要小,那么也不会造成无法消费,Kafka
      为了保持消费逻辑的正常运转不会对此做强硬的限制。

    参考博文:https://juejin.im/post/5bec10ca6fb9a049b13dc1e4

    展开全文
  • 在说到消息中间件时候,我们通常都会谈到一个特性:消息顺序消费问题。这个问题看起来很简单:Producer发送消息1, 2, 3。。。 Consumer按1, 2, 3。。。顺序消费。 但实际情况却是:无论RocketMQ,还是Kafka,...

    在说到消息中间件的时候,我们通常都会谈到一个特性:消息的顺序消费问题。这个问题看起来很简单:Producer发送消息1, 2, 3。。。 Consumer按1, 2, 3。。。顺序消费。

    但实际情况却是:无论RocketMQ,还是Kafka,缺省都不保证消息的严格有序消费!

    这个特性看起来很简单,但为什么缺省他们都不保证呢?

     

    “严格的顺序消费”有多么困难

    下面就从3个方面来分析一下,对于一个消息中间件来说,”严格的顺序消费”有多么困难,或者说不可能。

    发送端

    发送端不能异步发送,异步发送在发送失败的情况下,就没办法保证消息顺序。

    比如你连续发了1,2,3。 过了一会,返回结果1失败,2, 3成功。你把1再重新发送1遍,这个时候顺序就乱掉了。

    存储端

    对于存储端,要保证消息顺序,会有以下几个问题: 
    (1)消息不能分区。也就是1个topic,只能有1个队列。在Kafka中,它叫做partition;在RocketMQ中,它叫做queue。 如果你有多个队列,那同1个topic的消息,会分散到多个分区里面,自然不能保证顺序。

    (2)即使只有1个队列的情况下,会有第2个问题。该机器挂了之后,能否切换到其他机器?也就是高可用问题。

    比如你当前的机器挂了,上面还有消息没有消费完。此时切换到其他机器,可用性保证了。但消息顺序就乱掉了。

    要想保证,一方面要同步复制,不能异步复制;另1方面得保证,切机器之前,挂掉的机器上面,所有消息必须消费完了,不能有残留。很明显,这个很难!!!

    接收端

    对于接收端,不能并行消费,也即不能开多线程或者多个客户端消费同1个队列。

    总结

    从上面的分析可以看出,要保证消息的严格有序,有多么困难!

    发送端和接收端的问题,还好解决一点,限制异步发送,限制并行消费。但对于存储端,机器挂了之后,切换的问题,就很难解决了。

    你切换了,可能消息就会乱;你不切换,那就暂时不可用。这2者之间,就需要权衡了。

    业务需要全局有序吗?

    通过上面分析可以看出,要保证一个topic内部,消息严格的有序,是很困难的,或者说条件是很苛刻的。

    那怎么办呢?我们一定要使出所有力气、用尽所有办法,来保证消息的严格有序吗?

    这里就需要从另外一个角度去考虑这个问题:业务角度。正如在下面这篇博客中所说的: 
    http://www.jianshu.com/p/453c6e7ff81c

    实际情况中: 
    (1)不关注顺序的业务大量存在; 
    (2) 队列无序不代表消息无序。

    第(2)条的意思是说:我们不保证队列的全局有序,但可以保证消息的局部有序。

    举个例子:保证来自同1个order id的消息,是有序的!

    下面就看一下在Kafka和RocketMQ中,分别是如何对待这个问题的:

    Kafka中:发送1条消息的时候,可以指定(topic, partition, key) 3个参数。partiton和key是可选的。

    如果你指定了partition,那就是所有消息发往同1个partition,就是有序的。并且在消费端,Kafka保证,1个partition只能被1个consumer消费。

    或者你指定key(比如order id),具有同1个key的所有消息,会发往同1个partition。也是有序的。

    RocketMQ: RocketMQ在Kafka的基础上,把这个限制更放宽了一步。只指定(topic, key),不指定具体发往哪个队列。也就是说,它更加不希望业务方,非要去要一个全局的严格有序。

    关键点:这个放开,其实牵涉到一个更大的问题。就是RocketMQ和Kafka在底层存储上面的重大差异。这个我在上1篇,”拨乱反正“”续篇中,有过介绍。后面在源码分析序列中,会进一步分析这个问题。

    转自 https://blog.csdn.net/chunlongyu/article/details/53977819

    展开全文
  • 我正在实现从MongoDB获取数据日常工作(大约300K...一切都在运作,但没有我想象那么多,特别是关于消费表现 .这就是我声明队列方式:rabbitMQ.getChannel().queueDeclare(QUEUE_NAME, true, false, false...

    我正在实现从MongoDB获取数据的日常工作(大约300K文档),并且每个工作都在RabbitMQ队列上发布消息 . 另一方面,我有一些消费者在同一个队列中,理想情况下应该并行工作 .

    一切都在运作,但没有我想象的那么多,特别是关于消费者的表现 .

    这就是我声明队列的方式:

    rabbitMQ.getChannel().queueDeclare(QUEUE_NAME, true, false, false, null);

    这就是发布的方式:

    rabbitMQ.getChannel().basicPublish("", QUEUE_NAME, null, body.getBytes());

    因此,用于声明队列的通道用于发布所有消息 .

    这就是消费者在for循环中实例化的方式(总共10个,但可以是任意数字):

    Channel channel = rabbitMQ.getConnection().createChannel();

    MyConsumer consumer = new MyConsumer(customMapper, channel, subscriptionUpdater);

    channel.basicQos(1); // also tried with 0, 10, 100, ...

    channel.basicConsume(QUEUE_NAME, false, consumer);

    因此,对于每个消费者,我创建了一个新 Channels ,这由日志确认:

    ...

    com.rabbitmq.client.impl.recovery.AutorecoveringChannel@bdd2027

    com.rabbitmq.client.impl.recovery.AutorecoveringChannel@5d1b9c3d

    com.rabbitmq.client.impl.recovery.AutorecoveringChannel@49a26d19

    ...

    据我所知,我非常简短的RabbitMQ体验,这应该保证所有消费者都被召唤 . 顺便说一下,消费者需要0.5到1.2秒才能完成任务 . 我刚发现很少3秒钟 .

    我有两个独立的队列,我重复上面所说的两次(使用相同的RabbitMQ连接) .

    所以,我测试了为每个队列发布100条消息 . 他们两个都有10个消费者,qos = 1 .

    我没想到的确有一个10 / s的交付/消费性能,而是我注意到:

    实际值约为0.4和1.0 .

    至少绑定到队列的所有使用者都收到了一条消息,但它看起来不像"fair dispatching" .

    花了大约3分30秒消耗两个队列上的所有消息 .

    1bcd071d150eff61eceeddb80a6f7dcf.png

    438e8baebbcfbc7641448c8ac8e30c5c.png

    我是否错过了RabbitMQ中线程的主要概念?或者任何可能仍处于默认值的特定配置?我很少见,所以这可能是可能的 .

    请注意,我处于幸运的位置,我可以控制发布和消费部分:)

    我在本地使用RabbitMQ 3.7.3,因此它不会出现任何网络延迟问题 .

    谢谢你的帮助!

    展开全文
  •  系统稳定性取决于两方面:硬件和软件,软件有操作系统和录像软件两部分,不管是Windows98,WindowsNT,Windows2000,还是WindowsXP,都是全世界通用非常优秀软件,而作为硬盘录像机仅仅使用了操作系统很小...
  • 在说到消息中间件时候,我们通常都会谈到一个特性:消息顺序消费问题。这个问题看起来很简单:Producer发送消息1, 2, 3。...“严格顺序消费”有多么困难下面就从3个方面来分析一下,对于一个消息中间件来说...

    在说到消息中间件的时候,我们通常都会谈到一个特性:消息的顺序消费问题。这个问题看起来很简单:Producer发送消息1, 2, 3。。。 Consumer按1, 2, 3。。。顺序消费。

    但实际情况却是:无论RocketMQ,还是Kafka,缺省都不保证消息的严格有序消费!

    这个特性看起来很简单,但为什么缺省他们都不保证呢?


    “严格的顺序消费”有多么困难

    下面就从3个方面来分析一下,对于一个消息中间件来说,”严格的顺序消费”有多么困难,或者说不可能。

    发送端

    发送端不能异步发送,异步发送在发送失败的情况下,就没办法保证消息顺序。

    比如你连续发了1,2,3。 过了一会,返回结果1失败,2, 3成功。你把1再重新发送1遍,这个时候顺序就乱掉了。

    存储端

    对于存储端,要保证消息顺序,会有以下几个问题: 
    (1)消息不能分区。也就是1个topic,只能有1个队列。在Kafka中,它叫做partition;在RocketMQ中,它叫做queue。 如果你有多个队列,那同1个topic的消息,会分散到多个分区里面,自然不能保证顺序。

    (2)即使只有1个队列的情况下,会有第2个问题。该机器挂了之后,能否切换到其他机器?也就是高可用问题。

    比如你当前的机器挂了,上面还有消息没有消费完。此时切换到其他机器,可用性保证了。但消息顺序就乱掉了。

    要想保证,一方面要同步复制,不能异步复制;另1方面得保证,切机器之前,挂掉的机器上面,所有消息必须消费完了,不能有残留。很明显,这个很难!!!

    接收端

    对于接收端,不能并行消费,也即不能开多线程或者多个客户端消费同1个队列。

    总结

    从上面的分析可以看出,要保证消息的严格有序,有多么困难!

    发送端和接收端的问题,还好解决一点,限制异步发送,限制并行消费。但对于存储端,机器挂了之后,切换的问题,就很难解决了。

    你切换了,可能消息就会乱;你不切换,那就暂时不可用。这2者之间,就需要权衡了。

    业务需要全局有序吗?

    通过上面分析可以看出,要保证一个topic内部,消息严格的有序,是很困难的,或者说条件是很苛刻的。

    那怎么办呢?我们一定要使出所有力气、用尽所有办法,来保证消息的严格有序吗?

    这里就需要从另外一个角度去考虑这个问题:业务角度。正如在下面这篇博客中所说的: 
    http://www.jianshu.com/p/453c6e7ff81c

    实际情况中: 
    (1)不关注顺序的业务大量存在; 
    (2) 队列无序不代表消息无序。

    第(2)条的意思是说:我们不保证队列的全局有序,但可以保证消息的局部有序。

    举个例子:保证来自同1个order id的消息,是有序的!

    下面就看一下在Kafka和RocketMQ中,分别是如何对待这个问题的:

    Kafka中:发送1条消息的时候,可以指定(topic, partition, key) 3个参数。partiton和key是可选的。

    如果你指定了partition,那就是所有消息发往同1个partition,就是有序的。并且在消费端,Kafka保证,1个partition只能被1个consumer消费。

    或者你指定key(比如order id),具有同1个key的所有消息,会发往同1个partition。也是有序的。

    RocketMQ: RocketMQ在Kafka的基础上,把这个限制更放宽了一步。只指定(topic, key),不指定具体发往哪个队列。也就是说,它更加不希望业务方,非要去要一个全局的严格有序。

    关键点:这个放开,其实牵涉到一个更大的问题。就是RocketMQ和Kafka在底层存储上面的重大差异。这个我在上1篇,”拨乱反正“”续篇中,有过介绍。后面在源码分析序列中,会进一步分析这个问题。


    转自 https://blog.csdn.net/chunlongyu/article/details/53977819

    展开全文
  • 关于多线程的理解这是初学者在面试过程中经常被问到的问题,从以下4个方面谈a、程序,进程,线程b、Java的多线程通过继承Thread和实现Runable中的run方法c、多线程的状态:新建状态,就绪状态,运行状态,阻塞状态...
  • 如何平衡保护和消费以维持资源和自然的可持续性的问题,不仅是保护生态学的主要挑战,而且还是一个国际政治和经济问题,常常导致国家之间的对抗。 例如在鲸鱼方面,长期以来,日本一直受到美国和澳大利亚等反鲸鱼...
  • 方面关于数据丢失和重复消费问题 1.数据丢失问题 receiver模式: (该部分比较简单,可以跳过) 丢失原因: 首先,receiver task 接收 kafka 中数据,并备份到其他 executor 中blockmanager里,然后将偏移量...
  • 生产者消费问题也是一个典型的线程问题,我们举一个这方面的实例来说明:在一个果园里,有农民和小孩子,农夫会不停的摘水果放入一个篮子里直到水果筐子满了,而小孩子会不停的从水果筐里边拿来水果吃,直到把水果...
  • 企业在开发和维护网站方面准备投入多少预算?谁负责开发和维护网站,...如何采取措施避免消费高峰时段网页无法打开或浏览速度变慢等问题?网络数据如何存储并整理?如何整合公司全部信息系统?网站成功如何测量?
  • 现在基本的任务完成了,来做一个自己关于java方面的一些总结吧。   1:java虚拟机。首先要理解java虚拟机。Java虚拟机是编译和运行Java程序等的各种命令及其运行环境的总称,这是比较正规的定义。我们可以把Java...
  • 但是在工作中一直没机会用到线程,由于最近换了一家公司,面试了一些线程问题,虽然勉强靠着模糊的记忆回答上来了,但是始终觉着理解的并不深刻,这两天整理了一下这方面的知识,写一遍关于Java的多线程安全问题。...
  • 在社会背景下,有更多关于社会不友好方面的研究,例如社会排斥,但忽视了社会友好情况-社会温暖。 因此,本研究将探索社会温暖对绿色消费的影响机制。 研究结论是,社会温暖对购买绿色产品的意愿有重大影响,而环境...
  • 自己也想积累一下这方面的知识。其中他说了在面试某赞公司时面试官问他关于热点Key的的解决方案。于是针对这次谈话以及上网查的一些资料后的思考进行一下总结。方便后续自己查阅。 什么是热点Key 其实对于热点Key...
  • 同样,还是一次工作上遇到的问题的记录,当时也是搞了挺久才搞出来的,虽然不太完美,但是误差方面在我的项目里还算可以接受,哪位老哥有更好的办法还请指导下,哪怕评论里留个网页链接我去看也好,多谢了。...
  • 关于这个问题,笔者想和不了解申请CCC认证好处企业,谈下面五个方面关于申请CCC认证优势之处。 第一点肯定是大家最直观通过CCC认证产品可以有CCC证书作为产品品质背书,消费者在选购时可以增加其购买...
  •  电磁兼容性(EMC)包含系统的发射和敏感度两方面的问题。如果一个单片机系统符合下面三个条件,则该系统是电磁兼容的: ① 对其它系统不产生干扰; ② 对其它系统的发射不敏感; ③ 对系统本身不产生干扰。 假若...
  • 电磁兼容性(EMC)包含系统的发射和敏感度两方面的问题。如果一个单片机系统符合下面三个条件,则该系统是电磁兼容的:  ① 对其它系统不产生干扰;  ② 对其它系统的发射不敏感;  ③ 对系统本身不产生干扰。 ...
  • 电磁兼容性(EMC)包含系统的发射和敏感度两方面的问题。如果一个单片机系统符合下面三个条件,则该系统是电磁兼容的:  ① 对其它系统不产生干扰;  ② 对其它系统的发射不敏感;  ③ 对系统本身不产生干扰。 ...
  • 在上一篇,我们通过一个简单案例,分享了怎么利用redis设计并实现一个秒杀抢购功能,关于秒杀功能中,需要注意比较关键有两个问题 高并发场景下,怎么确保不会超卖 高并发场景下,如何确保一人一单 具体在...
  • 与国内其它经济开发区、高新技术开发区相比,保税区除“保税”外,同时具有其它方面的税收优惠政策,如企业所得税的依法减免、出口企业的出口退税等,这使保税区在其他方面的税收优惠也不逊于其他地方。   二、...
  • 今天,美工铺子为各位讲讲关于小程序开发用户体验问题。 一、贴合用户市场 我们在开发小程序之前,一定要做市场调查,就是要对用户市场发展做详细调查分析,全面了解用户实际需求和问题,根据用户调查...
  • 最近在项目中使用了多线程生产者消费者模型来模拟消息队列处理问题,但是发现在要求线程退出时,由于没能处理好退出线程的操作造成了Tomcat进程无法停止的问题。经过一番折腾后想总结一下这方面的经验。 线程中断的...

空空如也

空空如也

1 2 3 4 5 ... 11
收藏数 206
精华内容 82
关键字:

关于消费方面的问题