如何获取 topic 主题的列表
bin/Kafka-topics. sh -list --zookeeper localhost:2181
生产者和消费者的命令行是什么?
生产者在主题上发布消息：
1、bin/Kafka-console-producer. sh --broker-list 192.168.43.49:9092--topic Hello-Kafka
2、注意这里的 IP 是 server. properties 中的 listeners 的配置。接下来每个新行就是输入一条新消息。
3、消费者接受消息：
4、bin/Kafka-console-consumer. sh --zookeeper localhost:2181 -topic Hello-Kafka--from-beginning
consumer 是推还是拉?
1、Kafka 最初考虑的问题是,customer 应该从 brokes 拉取消息还是 brokers 将消息推送到 consumer,
也就是 pull 还 push。在这方面,Kafka 遵循了一种大部分消息系统共同的传统的设计:producer 将消
息推送到 broker,consumer 从 broker 拉取消息。
2、一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式,将消息推送到下游的 consumer。这
样做有好处也有坏处：由 broker 决定消息推送的速率，对于不同消费速率的 consumer 就不太好处
理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息，但不幸的是，push 模式下，
当 broker 推送的速率远大于 consumer 消费的速率时,consumer 恐怕就要崩溃了。最终 Kafka 还是选
取了传统的 pull 模式。
3、Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据。Push 模式必
须在不知道下游 consumer 消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批
量推送。如果为了避免 consumer 崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息
而造成浪费。Pull 模式下，consumer 就可以根据自己的消费能力去决定这些策略。
4. Pull 有个缺点是,如果 broker 没有可供消费的消息,将导致 consumer 不断在循环中轮询，直到新消
息到 t 达。为了避免这点，Kafka 有个参数可以让 consumer 阻塞知道新消息到达(当然也可以阻塞知
道消息的数量达到某个特定的量这样就可以批量发送)。
讲讲 Kafka 维护消费状态跟踪的方法
1、大部分消息系统在 broker 端的维护消息被消费的记录：一个消息被分发到 consumer 后 broker
就马上进行标记或者等待 customer 的通知后进行标记。这样也可以在消息在消费后立马就删除以
减少空间占用。
2、但是这样会不会有什么问题呢?如果一条消息发送出去之后就立即被标记为消费过的，一旦
consumer 处理消息时失败了(比如程序崩溃)消息就丢失了。为了解决这个问题，很多消息系统提供
了另外一个个功能：当消息被发送出去之后仅仅被标记为已发送状态，当接到 consumer 已经消费
成功的通知后才标记为已被消费的状态。这虽然解决了消息丢失的问题，但产生了新问题，首先如
果
