1 面试题
如何保证讯息的可靠性传输(如何处理讯息的丢失)?
2 考点分析
用mq有个基本原则，就是资料不能多一条，也不能少一条
不能多，就是刚才说的重复消费和幂等性问题
不能少，就是说这资料别搞丢了
如果说你这个是用mq来传递非常核心的讯息，比如说计费，扣费的一些讯息，计费系统是很重的一个业务，操作是很耗时的。所以说广告系统整体的架构里面，实际上是将计费做成异步化的，然后中间就是加了一个MQ
为了确保说这个MQ传递过程中绝对不会把计费讯息给弄丢，花了很多的精力。广告主投放了一个广告，明明说好了，使用者点选一次扣费1块钱。结果要是使用者动不动点选了一次，扣费的时候搞的讯息丢了，我们公司就会不断的少几块钱，几块钱，积少成多，这个就对公司是一个很大的损失。
3 详解
丢资料，mq一般分为两种
mq自己弄丢
消费的时候弄丢
咱们从rabbitmq和kafka分别来分析一下吧
rabbitmq这种mq，一般来说都是承载公司的核心业务的，资料是绝对不能弄丢的
3.1 rabbitmq
3.1.1 生产者丢资料
生产者将资料传送到rabbitmq的时候，可能资料就在半路给搞丢了，因为网络啥的问题，都有可能。
此时可以选择用rabbitmq提供的事务功能，就是生产者传送资料之前开启rabbitmq事务(channel.txSelect)，然后传送讯息
如果讯息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务(channel.txRollback)，然后重试传送讯息;
如果收到了讯息，那么可以提交事务(channel.txCommit)
但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗效能。
所以一般来说，如果你要确保说写rabbitmq的讯息别丢，可以开启confirm模式，在生产者那里设定开启confirm模式之后，你每次写的讯息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack讯息，告诉你说这个讯息ok了。如果rabbitmq没能处理这个讯息，会回拨你一个nack界面，告诉你这个讯息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个讯息id的状态，如果超过一定时间还没接收到这个讯息的回拨，那么你可以重发。
事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你传送个讯息之后就可以传送下一个讯息，然后那个讯息rabbitmq接收了之后会异步回拨你一个界面通知你这个讯息接收到了。
所以一般在生产者这块避免资料丢失，都是用confirm机制的。
3.1.2 rabbitmq丢资料
就是rabbitmq自己弄丢了资料，这个你必须开启rabbitmq的持久化，就是讯息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前储存的资料，一般资料不会丢。除非极其罕见的是，rabbitmq还没持久化，自己就挂了，可能导致少量资料会丢失的，但是这个概率较小。
设定持久化有两个步骤，第一个是建立queue的时候将其设定为持久化的，这样就可以保证rabbitmq持久化queue的元资料，但是不会持久化queue里的资料;第二个是传送讯息的时候将讯息的deliveryMode设定为2，就是将讯息设定为持久化的，此时rabbitmq就会将讯息持久化到磁盘上去。必须要同时设定这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的资料。
而且持久化可以跟生产者那边的confirm机制配合起来，只有讯息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，资料丢了，生产者收不到ack，你也是可以自己重发的。
哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个讯息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点资料会丢失。
3.1.3 消费端弄丢了资料
rabbitmq如果丢失了资料，主要是因为你消费的时候，刚消费到，还没处理，结果程序挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这资料就丢了。
这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来呼叫就行，然后每次你自己程式码里确保处理完的时候，再程式里ack一把。
这样的话，如果你还没处理完，不就没有ack?那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，讯息是不会丢的。
3.2 Kafka
3.2.1 消费端丢资料
唯一可能导致消费者弄丢资料的情况，你那个消费到了这个讯息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个讯息，其实你刚准备处理这个讯息，你还没处理，你自己就挂了，此时这条讯息就丢咯。
这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证资料不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
生产环境碰到的一个问题，就是说我们的kafka消费者消费到了资料之后是写到一个内存的queue里先缓冲一下，结果有的时候，你刚把讯息写入内存queue，然后消费者会自动提交offset。
然后此时我们重启了系统，就会导致内存queue里还没来得及处理的资料就丢失了
3.2.2 kafka弄丢了资料
这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些资料没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些资料?这就丢了一些资料啊。
生产环境也遇到过，我们也是，之前kafka的leader机器宕机了，将follower切换为leader之后，就会发现说这个资料就丢了
所以此时一般是要求起码设定如下4个引数：
给这个topic设定replication.factor引数：这个值必须大于1，要求每个partition必须有至少2个副本
在kafka服务端设定min.insync.replicas引数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联络，没掉队，这样才能确保leader挂了还有一个follower吧
在producer端设定acks=all：这个是要求每条资料，必须是写入所有replica之后，才能认为是写成功了
在producer端设定retries=MAX(很大很大很大的一个值，无限次重试的意思)：这个是要求一旦写入失败，就无限重试，卡在这里了
我们生产环境就是按照上述要求配置的，这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，资料不会丢失
3.2.3 生产者会不会弄丢资料
如果按照上述的思路设定了ack=all，一定不会丢，要求是，你的leader接收到讯息，所有的follower都同步到了讯息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
