receiver方式 sparkStream启动一个单独的线程receiver定时使用kafka高阶API向kafka拉取数据，并自动地更新zk的offsets。

优点：用户专注于业务，不需要关心偏移量的维护，代码简洁。

缺点：定时拉取数据可能造成sparkStream处理速度跟不上，导致数据丢失。 启动wal预写日志后，receiver会额外将数据写一份到本地，数据丢失的情况可以自动到日志中恢复，但是这种方式会重复写数据造成性能大幅浪费。此外，receiver与业务不在同一线程，但两者却又相互依赖，这导致我们在对业务进行高并发高吞吐的优化时不得不受制于receiver。

direct方式sparkStream在业务代码中使用kafka低阶API直接连接kafka拉取数据进行消费。

优点： 简化并行：kafka分区与RDD分区一致，可以一对一并行消费; 

高效：数据的拉取与消费是顺序关系，不存在数据丢失问题，避免wal预写日志

稳定：处理完才拉取下一批数据，不会造成任务积压导致程序崩溃,强一致语义：可以通过手动维护偏移量的方式自定义实现一致性。

：需要采用checkpoint或第三方平台维护偏移量，开发成本较高;实现监视需要额外人工开发。