构建数据管道
Kafka最主要的作用：解耦，异步，当做一个非常的大，可靠的buffer。因此构建数据管道时需要考虑的有：
- 时间性
- 可靠性
- 高吞吐量，尤其是高峰低谷交错
- 数据格式
- 安全
- 耦合：没有一个通用的数据管道，只是单纯的不断添加各种integration，数据元信息，表结构，一定要可以不断兼容进化。
- 数据管道本身不能含有密集计算，而是应该让下游app自己来计算
Kafka Connect/Producer/Consumer 的定位
Kafka Connect本身的定位是连接数据源和kafka，数据的搬运工，提供了已知的众多的数据库，用于批量导入导出数据。方便，但是没有Producer、Consumer提供api灵活。Producer、Consumer多用于自己实现数据的收集和处理。Convertor需要用来转换数据，源数据到kafka，或者kafka到目标数据，都需要转换。Connect本身的offset管理也会根据source和sink的不同来实现。
跨集群数据镜像
跨区域数据中心，主从备份迁移，都需要跨集群的数据复制，多个kafka集群的运行。跨地域的数据复制速度慢，有延迟，代价高。producer的设计不适合跨集群写数据，不然重试的次数和错误率会明显上升。如何处理：多个kafka集群运行在不同的区域的数据中心？
1 hub-and-spkoes模式：一个中心kafka汇集所有数据，多个本地kafka处理本地的数据，本地kafka把数据镜像给中心kafka。2 active-active模式：类似于主主互备，两个数据中心的kafka互为备份，但是缺点也明显：得自己处理数据的不一致。3 active-standby模式：主人替身模式，多出来一个kafka做备份，master出故障后直接转到替身。平时没事的时候，替身kafka就是浪费资源。
而出了事故之后如何故障恢复？集群之间的数据复制总会有滞后，滞后就会引起数据的丢失和不一致。集群恢复后，从哪里开始消化数据？
流式处理
流式数据处理需要注意的点：时间时间，处理时间，时区，状态。因此官方总结了一些常见的流式处理设计模式：
单一事件处理：每个事件是单独的处理的，类似于map/reduce模式。
本地状态处理：每个事件都有一个状态，如何维护这个状态，做到可恢复。
多阶段处理：这简直就是给dmp平台设计的，有一个kafka集群，然后自己编写每一步的逻辑，处理完后放回kafka。
利用KafkaStream API，和spark stream很相似，比较容易scale up，利用本身的高可靠性，可以做到很容易的故障恢复，比如一个consumer挂掉了，可以自动协调别的consumer来继续工作。
流式数据处理有不同应用场景：如果只是ingest问题，那么选取合适的connect就可以了；如果强调低延迟，那么就必须选取event-per-event低延迟的处理；如果强调微服务的消息传递，那么就必须优先考虑的是数据的exactly-once的传递；如果是专注于数据的聚合操作，那么得优先考虑聚合计算，window时间，join类型等操作；
个人总结
这本书的特点是：范围广。不单介绍了kafka的基本用法，还涵盖了开发，运维，内部实现机制，监控，应用场景的选取，系统设计的考虑。是一本可以在整个技术组里面推荐给每个技术人员阅读的书，可以帮助架构师设计开发时作为参考。但是，这本书的广度之宽泛，也决定了如果要深度的了解kafka系统，那么官方的文档，一定是最佳的选择。
