kafka相比mysql的优点_Kafka-spark-kafka-spark架构有什么优势吗，为何两次使用kafka？...

谢邀。

首先我比较同意 @Alex 的观点。另外如果方便的话可以把这张图的出处发一下~~

关于exactly-once语义(下称EOS)，有太多的误解甚至是“歪曲”了，很多框架(也包括Kafka Streams:-)都宣称自己实现了与Kafka的exactly once语义。实际上，在KIP-98引入之前，这几乎是不可能的。KIP-98正式引入了幂等性producer和事务才使得流处理框架+Kafka有可能实现端到端(End-to-End, E2E)的精确一次处理语义。回到题主的问题，我的猜测是：它引入第二个Kafka是为了使用其事务特性来保证EOS，当然这只是我的猜测了~~

事实上，Apache Spark的官网上明确指出了用户若要实现与Kafka的EOS，则必须自己实现幂等输出+位移保存要在同一个事务中。如果用户不能自行提供这套机制，那么显然这要依托于Kafka提供的事务机制才能实现。

Apache Flink在KIP-98之前也宣称实现了EOS，不过是有前提条件的：即每条消息对于Flink应用状态的影响有且只有一次，而非单纯的action output。举个例子，假设你使用Flink从Kafka读取消息然后不加任何处理直接写入到MySQL，那么这件事情是无法保证EOS的，因为这是无状态应用。因此在KIP-98之前Flink只是保证这种程度的EOS而已，而不能做到E2E的EOS。当然，Flink社区在1.4版本时正式实现了基于Kafka 0.11幂等producer的E2E EOS支持，采用的机制类似于数据库领域中的两阶段提交。详细信息参见：https://data-artisans.com/blog/end-to-end-exactly-once-processing-apache-flink-apache-kafka。 具体的效果我们拭目以待~~

这里想说明的是，当我们看到框架在宣称支持EOS时一定要明确这里面的具体含义，某些是有限定条件的。如果不显式地明确这些条件，那么就可能造成一定的误解。比如下面这条推特：https://twitter.com/gwenshap/status/829385997032919040

Spark峰会上Spark团队"公正“地比较自家流处理Structured Streaming与其他流处理框架时所作的论断。有意思的是，这张表格引起了包括Kafka committer以及Flink掌门人等人的些许不满。有兴趣的话可以看一下他们的回复。

最后言明一下，以上使用例子皆是为了说明观点之用，无针对某一框架的意思。事实上， 本人对Spark框架充满敬意：)