消息中间件之Kafka(二)

1.Kafka线上常见问题

1.1 为什么要对topic下数据进行分区存储?

• 1.commit log文件会受到所在机器的文件系统大小的限制，分区之后可以将不同的分区放在不同的机器上，
  相当于对数据做了分布式存储，理论上一个topic可以处理任意数量的数据
• 2.提高并行度

1.2 如何在多个partition中保证顺序消费?

• 方案一:首先将需要保证顺序的消息收集起来，然后交给一个consumer去进行处理，然后内部维护一个线程池，让其中某一个线程去顺序执行这些消息eg:用户下单流程，支付成功消息 -> 库存消息
• 方案二:让多个消息构造一个特殊结构的顺序消息,当consumer收到时，在一个线程中依次进行消费

1.3 消息丢失

以上4个步骤都有可能会造成消息丢失
Producer

• acks=0,表示producer不需要等待任何broker确认收到消息的回复，就可以发送下一条消息，性能最高，但是最容易丢消息,大数据统计报表场景，对性能要求很高，对数据丢失不敏感的情况可以用这种
• acks=1,表示至少要等待leader已经成功将数据写入本地log,但是不需要等待所有follower是否成功写入，就可以继续发送,下一条消息，这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失
• ack=-1或者all,这意味着leader需要等待所有备份(min.insync.replicas配置的备份个数)都成功写入日志，
  这种策略会保证只要由一个备份存活就不会丢失数据，这是最强的数据保证，一般除非是金融级别，或跟钱打交道的场景才会使用这种配置，当然如果min.insync.replicas配置的是1则也可能丢消息，跟acks=1情况类似

Consumer

• 如果消费这边配置的是自动提交