2019-08-06批量消费有意义的场景要求：1.要么消费端对消息的处理支持批量处理，比如批量入库 2. 要么消费端支持多线程/协程并发处理，业务上也允许消息无序。3. 或者网络带宽在考虑因素内，需要减少消息的overhead。
批量消费的局限性：1. 需要一个整体ack的机制，一旦一条靠前的消息消费失败，可能会引起很多消息重试。2. 多线程下批量消费速度受限于最慢的那个线程。
但其实以上局限并没有影响主流MQ的实现了批量功能。 3 28
2019-08-061、要求消费端能够批量处理或者开启多线程进行单条处理
2、批量消费一旦某一条数据消费失败会导致整批数据重复消费
3、对实时性要求不能太高，批量消费需要Broker积累到一定消费数据才会发送到Consumer作者回复: 👍👍👍
16
2019-08-06老师好，我一直理解，消息积压不是一种正常的现象吗？来不及处理的消息先在消息队列中存着，缓解下游系统的压力，让上下游系统在时间上解偶，，听了今天的课，感觉理解的不太一样，希望老师解答一下作者回复: 消息积压是正常现象，积压越来越多就需要处理了。
就像一个水库，日常蓄水是正常的，但下游泄洪能力太差，导致水库水位一直不停的上涨，这个就不正常了。 1 16
2019-08-08一、如何预防消息积压？
1、发送端提高并发及批量大小；
2、消费端增加实例且同步宽容分区；
二、如何处理消息积压？
1、消费端扩容；
2、服务降级；
3、异常监控。展开 12
2019-08-06尝试回答下课后习题，老师有空帮忙看下哦
消费端进行批量操作，感觉和上面的先将消息放在内存队列中，然后在并发消费消息，如果机器宕机，这些批量消息都会丢失，如果在数据库层面，批量操作在大事务，会导致锁的竞争，并且也会导致主备的不一致。如果是一些不重要的消息如对日志进行备份，就可以使用批量操作之类的提高消费性能，因为一些日志消息丢失也是可以接受的。作者回复: 非常好！
8
2019-08-06消费端通过丢入队列，并使用多线程来提高并发，老师讲到可能丢消息，但也要是某种条件成立，比如开启了自动提交，如果改为手动提交完全可以避免丢消息，只是可能出现重复消费问题，至少不会丢 3 3
2019-08-061.无法提升消费业务效率（仅受消费业务自身逻辑影响），但可以提高mq中堆积消息消费的整体吞吐量（批推比单推mq耗时较短）。
2.数据增量同步，监控信息采集。（非核心业务的稳定大数据流操作）。
3.批处理意味数据积累和大数据传输，这会让单次消费的最长时延变长。同时批量操作为了保证当前批量操作一致性，在个别失败的情况下会引发批量操作重试。作者回复: 总结的非常好！
3
2019-09-06一开始不理解为啥Producer发得慢了会导致消息积压，明明是发得少了Broker端的消息应该更少啊
后来想到前面章节有提到消息事务，Producer首先会开启事务并发送一个半消息，再执行业务逻辑，最后提交事务，如果发得慢了会导致半消息在Broker中的时间增长，导致积压 1 2
2019-08-16消息积压处理：
1、发送端优化，增加批量和线程并发两种方式处理
2、消费端优化，优化业务逻辑代码、水平扩容增加并发并同步扩容分区数量
查看消息积压的方法：
1、消息队列内置监控，查看发送端发送消息与消费端消费消息的速度变化
2、查看日志是否有大量的消费错误
3、打印堆栈信息，查看消费线程卡点信息展开作者回复: 👍👍👍
2
2019-08-09消息本来就有限流或者削峰填谷，这个也是使用消息队列的作用，老师您讲的不严谨。 2
2019-09-02老师，如果onMessage方法中，收到消息后不确认，等真正处理完消息再确认，就可以了吧，这样就可以用内存队列了作者回复: 理论上是可以的，但你要注意，像RocketMQ，采用默认配置的时候，onMessage方法结束后，如果没抛异常，默认就会自动确认了。
1
2019-08-26发送端如果多线程，如何实现之前您在《确保消息不会丢失》这篇文章中说的：
发送端 把发送消息标识为每次增加1的效果？作者回复: 可以使用一个自增的原子变量，比如Java中的AtomicLong。
1
2019-08-211：请教几个小问题
1-1：目前那些消息队列产品实现了批量消费？
1-2：批量消费的实现原理是怎用的？类似文中的例子直接放入一个内存队列中，然后再开启多线程批量消费嘛？
2：课后思考
2-1：在消费端是否可以通过批量消费的方式来提升消费性能？
可以
2-2：在什么样场景下，适合使用这种方法？
不担心重复消费，网络环境比较稳定，消费者端机器比较稳定
2-3：这种方法有什么局限性？
首先，使用的消息队列产品支持批量消费
然后，一次取多条消息，性能节省在连接建立上，消息量大在传输时会多耗一点，且消息者只能消费完一批消息，才能返回确认，会耽误点时间取下一批消息
最后，如果一批消息的消费过程中有一个失败了，假如一次消费1000条消息，消费第1000条时失败了，则整批消息都算失败了，那会重试，则前面999条消息都会重复消费，如果都有幂等控制也没什么，不过这种情况会使单台消息消费成功的时间加长许多。
3：本节小结
3-1：消息积压怎么产生的？
要么生产者太快了，要么消费者太慢了，这是相对的，但无论如何根本就是消费者的消费速度＜生产者的生产速度。
3-2：消息积压咋弄？
3-2-1：就让他积压，不管
3-2-2：有时为了缓解消费者的压力，还会故意让他积压
3-2-3：优化消费者逻辑，比如：将慢逻辑移出去，再将消息倒一道手
3-2-4：扩容，消费者扩容，broker也扩容，保持同一个主题下的分区和消费者实例一一对应，充分发挥消费者的性能
3-2-5：某些情况可以使消费者侧批量消费消息的方式，来提高性能展开作者回复: 第一个问题，主流的消息队列都有实现，区别是，Kafka它是自动异步批量发送，而其它消息队列会提供一个类似batchSend(Msg [] messages)的批量发送的方法，由使用者决定是否批量发送以及批量大小。
第二个问题我们后面的课程会有专门的讲解。 1
2019-08-06在消费端需要注意的是，增加并发需要同步扩容分区数量，否则是起不到效果的。
这一点非常需要注意，其实有些公司在这个地方用错了。 1
2020-01-10其实还有一种处理消息积压的方法，设置消费速度，让消费者慢慢消费。当然这种也有局限性，那就是业务对延迟不敏感，实时性要求高的业务就不适合了。所以，很多时候还是看场景，做好权衡和取舍
2020-01-06批量消费的问题有三点：
1. 单个消息的消费。批量消费往往配合多线程消费，最好没有大量的临界资源，否则性能将不如单个消息消费，因为批量消费增加了消息管理成本，例如消费线程间上下文切换、临界资源锁定和解锁等。
2.消费顺序的保证。如果场景对消费顺序强要求，那么不太适合多线程批量消费，因为无法保证线程间的消费顺序。
3.消费失败的处理成本。某一条消息的消费失败不能影响其他消息的消费，如发短信就比较适合，而资金流水日志入库就不适合(要保证顺序)。
2019-12-02我没读过这篇文章之前我看过别人面试的解决消息积压的方法：
（1）临时扩容，增加消费端，用硬件提升消费速度。
（2）服务降级，关闭一些非核心业务，减少消息生产。
（3）通过日志分析，监控等找到挤压原因，消息队列三部分，上游生产者是否异常生产大量数据，中游消息队列存储层是否出现问题，下游消费速度是否变慢，就能确定哪个环节出了问题
（4）根据排查解决异常部分。
（5）等待积压的消息被消费，恢复到正常状态，撤掉扩容服务器。
到此，问题解决展开
2019-12-02可以，在消费消息量特别大，且消费速度特别快的情况下。需要控制批量数量，太大，太小都不好。
2019-11-20老师好 消费端 比如kafka增加机器 不能起到增加消费能力的作用 如果按照多线程来进行消费 在一定量处理完毕之后进行统一的位点提交 这么做可以避免重启后消息丢失的问题 是不是就可以解决消费端的能力扩容问题了作者回复: 是的，这个方法理论上是没问题的。实现起来稍微有点儿复杂，只要能正确的实现出来是可以解决问题的。
1
2019-11-14在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区（也叫队列）数量，确保 Consumer 的实例数和分区数量是相等的。------------请问在不同主题下，队列数量怎么 设置尼，是某个参数么作者回复: 队列的数量一般是在创建主题的时候指定的。