笔记速览：消息队列的问题

总结自：中华石衫

如何保证消息队列的高可用啊？

缺点：
	* 导致系统可用性降低
	
就Kafka来说：
	* HA机制，就是replica副本机制
	* isr
	* leader 挂了咋办？ broker挂了咋办？  controller挂了咋办？

---

消息队列重复消费？如何保证消息不被重复消费啊（如何保证消息消费时的幂等性）

* 原因 ：任务重启，offset提交有间隔，导致部分数据被重复消费
* 措施 ：消息队列不保证重复数据，所以要开发一套 幂等性 机制
	* 如果 是 redis，不用考虑，因为 redis 天然幂等性
	* 业务上 每条数据 都生成唯一的id，每次处理数据的时候去缓存（内存、redis）中查，看有没有处理过

---

如何保证消息的可靠性传输（如何处理消息丢失的问题）？

* 生产者弄丢了数据
	ack=all，一定不会丢
	
* Kafka 服务端丢数据（crash）

	kafka的leader机器宕机了，将follower切换为leader之后，发现数据丢了
	
	下面四个参数必须保证：
		kafka服务端 	replication.factor ：这个值必须大于1，要求每个partition必须有至少2个副本
		kafka服务端		min.insync.replicas ：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower
		producer端		acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
		producer端		retries=MAX：这个是要求一旦写入失败，就无限重试，卡在这里了

* 消费端弄丢了数据
	原因：kafka只有一种可能：offset自动提交，但是处理数据的时候Consumer挂了，那消息就丢了
	解决：关闭 kafka offset 自动提交，在处理完数据的时候提交。针对此时 Consumer 挂了会出现重复消费的情况，用幂等性保证

---

如果保证从队列里拿到的数据按顺序执行？就Kafka来说

* partition 里的数据肯定有序，kafka 不保证 多个 partition 里数据的有序性
* partition - consumer 一一对应，如果 Kafka Consumer 单线程 消费 + 处理，可能会影响 消费速度
* 当 Consumer 只负责 取数据，取完数据丢 queue 里面，处理线程从 queue 里面取数据处理，可加快速度（queue可以有多个，queue - 处理线程 一一对应）
* 此时 要将 需要 有序的数据，放在 同一个queue 里面

---

大量消息在mq里积压了几个小时了还没解决？

-- 临时紧急扩容

数据会大量积压在mq里，而是大量的数据会直接搞丢？

-- TTL 尽量不要设
-- 手动写程序，补数据

走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？

-- 消费到的数据就扔，达到快速消费目的
-- 消费到的数据就存（数据迁移系统），后期补数据

---

如果让你写一个消息队列，该如何进行架构设计啊？思路是什么？

关键点：
	* 基本功能
	
		生产者消费者，维护队列
		
	* 支持伸缩性：在需要的时候进行扩容
	
		参照 Kafka 分布式系统，broker -> topic -> partition，每个 partition 分布在不同的机器上，只存一部分数据。
		
		资源不够则 增加 partition，增加机器
		
	* 数据持久化
		
		顺序落盘，提高磁盘读写性能； index 和 log 文件，加快 速度
		
	* 可用性，HA
		
		replication , leader 挂了咋办？ broker挂了咋办？  controller挂了咋办？
		
	* 支持数据零丢失方案