1、消息引擎系统：系统A发送消息给消息引擎系统，系统B从消息引擎系统中读取A发送的消息。
①消息引擎传输的对象是消息。
②如何传输消息是消息引擎设计机制的一部分。
2、既然是在不同系统之间传输消息，那么如何设计传输消息的编码格式，使得消息能够表达业务语义而没有歧义就显得尤为重要。
已熟知的解决方案：CSV、XML、JSON或者Google 的Protocol Buffer、Facebook 的 Thrift。
Kafka的解决方案：纯二进制的字节序列。
3、消息传输模型（Kafka都支持）：
①点对点模型：A系统发送的消息只能被B系统读取到。
②发布/订阅模型：多个发布者向同一个Topic主题中发送消息，多个订阅者亦可从这个Topic中读取消息。
4、最重要的：消息引擎系统最重要的特点是：削峰填谷。缓冲上下游瞬时突发的流量，使其平滑。
5、Kafka是消息引擎系统，也是分布式流式处理平台。
6、Kafka早期版本将其定位为是一个分布式、分区化且带有备份功能的提交日志的服务。
7、Kafka在设计之初就旨在提供三个方面的特性：①提供一套API实现生产者和消费者。②降低网络传输和磁盘存储开销。③实现高伸缩性架构。
8、Kafka在推出流处理组件Kafka Streams后，它将不仅仅是消息引擎系统，至此，Apache Kafka 是和 Apache Storm、Apache Spark 和 Apache Flink 同等级的实时流处理平台。
9、作为流处理平台，Kafka对比其他流处理平台的优势：更容易实现端到端的正确性（流处理如果要替代批处理，必须保证端到端的正确性。如果你搭建了一套环境使得 Spark 或 Flink 从 Kafka 读取消息之后进行有状态的数据计算，最后再写回 Kafka，那么你只能保证在 Spark 或 Flink内部，这条消息对于状态的影响只有一次。但是计算结果有可能多次写入到 Kafka，因为它们不能控制 Kafka 的语义处理。相反地，Kafka则不是这样，因为所有的数据流转和计算都在 Kafka 内部完成，故 Kafka 可以实现端到端的精确一次处理语义。）。
例：我们就说一个普通的producer程序：producer需要接收到broker发送的response才能认为发送成功，如果response在传输过程中因为网络抖动丢失了或超时了（这种情况非常常见）而broker实际上已经写入了该消息，那么producer就会认为发送失败从而尝试重新发送，这就可能造成同一条消息被发送了多次。
10、Kafka 从 0.7 版本时代演进到 0.8 之后正式引入了副本机制，至此 Kafka 成为了一个真正意义上完备的分布式高可靠消息队列解决方案。有了副本备份机制，Kafka就能够比较好地做到消息无丢失。那时候生产和消费消息使用的还是老版本的客户端 API，所谓的老版本是指当你用它们的 API开发生产者和消费者应用时，你需要指定 ZooKeeper 的地址而非 Broker 的地址。
