MQ消息队列（二）

接第一篇MQ

补充谈谈kafka数据丢失的情况

• 消费端弄丢了数据
  唯一可能导致消费者弄丢数据的情况，就是说你消费到这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费到这个消息了，但是你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢了。

这个是RabbitMQ差不多的，但是因为kafka会自动提交offset，那么只要关闭自动提交offset，在处理完自己手动提交offset，就可以保证数据不是丢失。但是此时可能会有消息重复消费，比如你刚刚处理完，还没来得及提交offset，自己就挂了，此时消息肯定会被重复消费一次，自己保证幂等性就好了。

生产环境碰到的一个问题，就是说我们的 Kafka 消费者消费到了数据之后是写到一个内存的queue 里先缓冲一下，结果有的时候，你刚把消息写入内存 queue，然后消费者会自动提交ow set。然后此时我们重启了系统，就会导致内存 queue 里还没来得及处理的数据就丢失了。

• Kafka 弄丢了数据
  这块比较常见的一个场景，就是 Kafka 某个 broker 宕机，然后重新选举 partition 的 leader。大家想想，要是此时其他的 follower 刚好还有些数据没有同步，结果此时 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切换时，数据就会丢失了。

• 生产者会不会弄丢数据？

如果按照上诉的死了设置了 acks=all ， 一定不会丢失，要求是你的leader就收到消息，所有的follower都同步到了消息之后。才认为本次写成功了。如果没满足这个条件，生产这会自动不断的重试，重试无限次。

如何保证MQ消息的顺序性

我举个例子，我们以前做过一个 mysql binlog 同步的系统，压力还是非常大的，日同步数据
要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（mysql ->
mysql）。常见的一点在于说比如大数据 team，就需要同步一个 mysql 库过来，对公司的业务
系统的数据做各种复杂的操作。

你在 mysql 里增删改一条数据，对应出来了增删改 3 条 binlog 日志，接着这三条 binlog
发送到 MQ 里面，再消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增
加、修改、删除；你愣是换了顺序给执行成删除、修改、增加，不全错了么。

本来这个数据同步过来，应该最后这个数据被删除了；结果你搞错了这个顺序，最后这个数据
保留下来了，数据同步就出错了。

RabbitMQ方案

拆分多个queue，每个queue都一个consumer，就是多了一些queue而已，确实是麻烦点；或者
就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发
给底层不同的 worker 来处理。

Kafka 方案

• 一个topic，一个partition，一个consumer，内部单线程消费，但是内部单线程吞吐量太低，一般不会用这个。
• 写N个内存queue，具有相同的key的数据都存到一个内存queue；然后对于N个线程，每个线程分别消费一个内存queue即可，这样就能保证顺序性。
  

如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

（未完后续…）