消息队列之Kafka

1、消息队列之KafkaKafka是 LinkedIn公司的一款开源MQ 。在没有Kafka之前，大部分的业务与业务之间都是通过端对端的连接，错综复杂。试想用一种极为简单的Pipeline将这些数据进行一次Aggregate 。将上面产生数据的作为生产者，下面对数据处理的作为消费者，就自然而然的形成了消费者和生产者，中间的Pipeline就是一个消息队列。Kafka在数据库的Replicate场景在此构架上面，主要需要保证如下几个方面：message integrity:no message loss in order deliveryexactlyoncemessage schema messa

2、ge schema registry messageseri/desrperfomance:high throughputlow latencyhandlelarge messagemessage integrityguaranteesproducer :bathing the messagesend messageasync在 Sender Thread中，从Record Accumulator里面的Message Buffer Poll Message发送到Broker为了Fail Over ，需要将数据进行Replicate ，将所有在ISR中的Broker都回应Ack ，再返回ISR

3、在 Producer 中，将 Ack 设置为 0，那么不行的 Replicate 就可以返回，这点类似于 UDP 协议。如果设置为 1，即使将Leader Commit，也可以返回Ack 。但是如果 Leader 在没有 Replicate 之前宕机，那么该条消息就会丢失，最后设置为 -1，消息是不会丢失， 但是对于之前的延迟是加强。为了保证In Order Delivery需要将。因为当消息为0，发送到Broker过后，由于种种原因Broker没有接受成功，就需要Retry ，然而如果此时此刻消息1 已经成功Send到 Broker ，就导致原本应该先看Message0结果变成了Messag

4、e1 。以及还需要在Producer的 Callback之中将Timeout设为0，将其close掉。为了数据存在多份，需要将min.isr = 2 。将ISR 至少保证两个Broker ，在这两个Broker里面保存最新的成功提交消息。Exactly Once Delivery 在 Consumer端进行处理，因为它是一个 Distribution Data System 。同时也会有一个Election ，所以才会有一个全局递增的Epoch 。以及根据业务的一个 Transition Sequence Number，所以这两个都是全局唯一的，当Consumer Poll对比自己最后一条消息

5、的ETS ，小的数据就直接扔掉。Performance Ack All里面会Increase Latency由于需要依赖外部存储，所以不是那么方便。最后在Producer和 Consumer做了Split和 Assembly 。在Consumer进行Assembly过程中要保证In OrderDelivery，需要对Message进行Buffer，在进行存储的过程中可以分为两种，一种去Offset的头，一种去Offset的尾部。每个人需对消息格式有一个固定的标准，而不是每人自定消息格式。如果这样的话，发出去的消息其他人没办法使用。我们要求所有经过Kafka的消息都必须用固定的Format ，加入一个集中式的Schema管理部件，每次发送消息的时候，它做的过程就是把我们的消息通过Schema序列化成Var Bytes ，我们不会把Schema随消息一起发出去，它做的事情是把Schema注册到Schema Registry拿到一个Schema ID ，把这个ID 随着消息一起发送到Kafka ，当Consumer拿到这个消息的时候，会先去看Schema ID ，然后到Schema Registry把 Schema拿回来，就