努力找工作呀

如何解决消息队列堆积几百万消息怎么办？这个造成的原因就是消费端出现了问题，不消费了或者消费速度变慢了。消息堆积几小时在队列先修复consumer的问题，确保其恢复消费速度，然后将现在的comsumer停掉 新建一个topic,partition是原来的10倍，临时建好原先10倍的queue数量 然后写一个临时的分发数据的consumer程序，这个程序部署消费积压的消息，消费之后不做耗时处理，直接均匀轮询写入临时建立好的10倍的queue中 接着临时征用10倍机器来部署consumer，每一

一.消费端丢失消息我们知道消息在被追加到Partition的时候会被分配一个offset。offset表示当前消费的Partition的所在位置，Kafka通过offset可以保证消息在分区内的顺序性。当消费者拉取到分区的某个消息之后，消费者会自动提交offset。但是会出现一个问题：当消费者刚拿到这个消息准备的时候，突然挂掉了，消息实际上没有被消费，但是offset已经被自动提交了。解决方法：关闭自动提交offset，每次在真正消费完消息之后再自己手动提交offset，每次在真正消费完消息后再自己

一.Exactly OnceAt Least Once：将服务器的ACK级别设置为-1，可以保证Producer到Server之间不会丢失数据At Most Once：将服务器的ACK级别设置为0，可以保证生产者每条消息zh

一.高可用的由来1.1 为什么需要Replication在Kafka在0.8之前的版本中，是没有Replication，一旦某个broker宕机，则其上的所有Partition数据都不可被消费，这与Kafka的数据持久化和Delivery Guarantee设计原则相违背。如果Producer使用同步模式则Producer则会在尝试重新发送message.send.max.retries（默认值是3）次后抛出异常，用户可以选择停止发送后续数据或者继续发送。而前者会造成数据的阻塞，后者会造成发送.

一.概述1.1 Kafka简介Kafka是一个分布式，分区，多副本，多订阅者，基于Zookeeper协调的分布式日志系统，也可以是消息系统。常见可以用于web/nginx日志，访问日志，消息服务等。主要设计目标有： 以时间复杂度为o(1)的方式提供消息持久化能力，即使对TB级以上的数据也能保证常数时间的访问性能 高吞吐率。即使在廉价的机器上也能做到支持每秒100K消息的传输 只是Kafka Server间的消息分区，及分布式消费，同时保证每个partition 内消息顺