这更像是根据您的经验类型来选择您的大脑，因为我找不到能够帮助我决定一种或另一种方式的资源。
我有一个kafka消息队列，每天大约有7-8百万个事件流式传输。消息最终需要保留在mysql数据库中。
方法1：
我可以编写微服务，对其进行容器化，并使容器应用程序的多个实例与不同的kafka使用者组和每个实例中的kafka侦听器一起运行，以使用事件并将它们推入mysql。
方法2：
我正在考虑的另一种方法是只使用spark作业，并使其处理事件流并将其持久保存在mysql db中。这样，我不必担心管理容器应用程序并降低运营成本等。
鉴于数据量，我不确定spark是否会被过度淘汰，而spark的成本是否会超过我在容器式应用程序上产生的资本和运营支出（比如在托管kubernetes环境等）
有人可以指导我如何去做他的人吗？
答案 0 :(得分：1)
您仍然可以使用JDBC连接器。
方法1：您可以根据分区派生许多微服务，并可以根据负载轻松调整分区和实例。它适用于简单的应用程序，还可以控制消耗消息的速率和更多的手动干预，但是它没有状态数据存储，没有分析实时操作，没有很多手动编码。
方法2：：Spark Stream需要额外的Spark集群来管理负载。我的理解Spark适用于实时分析和机器学习，因此，如果您正在执行复杂的操作，则可以使用聚合并将聚合消息推送到DB（聚合消息而不是原始的百万数据）。
方法3：：Kafka Stream-易于使用，仅具有一次语义和更好的故障转移功能，同时具有状态分析能力。您可以通过基于分区调整实例来管理负载。
您可以根据需要选择上述任何一种方法，但是可以从多个并行实例将所需的手动ACID管理加载到数据库中，在数据库上进行故障转移，进行事务管理等。
因此，我建议不要直接将其发布到一个主题中，并从主题到您的数据库创建JDBC接收器连接器
这是我的想法：
使用Kafka Stream（或微服务，消费者组）-您可以根据负载很好地优化实例和分区。我建议使用Kafka Stream，因为您可以利用一次精确的语义，更好的容错能力，并且还可以在需要时使用有状态操作。
进行转换并将输出消息发布到Kafka一个主题。
创建从主题到数据库的JDBC接收器连接器：这只是一个您可以使用不同参数进行控制的连接器。Kafka JDBC Connector
答案 1 :(得分：0)
您提到了两种方法，正如评论中所建议的那样，Kafka Connect是另一种方法。
使用微服务API：即使您遵循这种方法，您仍需要某种服务（例如基于主题的Supervisor始终在后台运行）（根据主题/分区进行负载均衡） Kafka Topic中的数据并调用rest api，将避免这种方法。
Spark流：维护一个Spark集群以将数据从Kafka接收到DB是过大的，并且还请记住，默认情况下，Spark仅支持向表添加（大容量插入），如果您需要更新一行左右的数据，您需要使用Jdbc样式的方法进行迭代并自己进行操作，以避免这种方法
Kafka Connect：是Kafka框架的开源版本的一部分，可以根据您为部署的每个作业添加的任务数量（可以为该主题的每个分区创建一个任务，以实现最大性能）进行扩展，并保留偏移量回到Kafka，让您可以直观地看到Kafka监控工具上的滞后，肯定会遵循这种方法