kafka的应用场景-kafka解决了什么问题

快进>>

消息传递面临的问题

公司可能从一个简单的数据分发系统开始——一个单一的源系统与一个单一的目标系统交换数据。随着时间的推移，随着新的源系统和目标系统被添加到组合中，这变得更加复杂。此外，集成越来越多的源系统会增加连接的负载。

随着系统越来越多的集成变得越来越复杂，公司面临着一些问题，例如：

• 使用什么协议来传输数据
• 数据应该如何解析数据
• 数据应该如何创建
• …

很多公司采用传统的方法暂时克服了困难

1. 数据库复制
   • 仅 RDBMS 到 RDBMS，仅关系数据库到关系数据库
   • 特定于数据库，不适用于供应商
   • 紧耦合，源和目标之间的紧密集成。架构的任何更改都会对复制产生直接影响
2. 日志传送
   • 性能挑战，取决于传送的日志大小及其频率
   • 管理繁琐，维护困难，只适用于某一类数据存储。
3. 提取、转换和加载 (ETL)
   • 用于在多个源和目标之间集成数据
   • 成本高
   • 自定义应用程序。需要进行大量的开发工作实现处理程序
   • 可扩展性挑战。由于管理自定义应用程序的复杂性，可扩展性受到限制。
4. 消息传递
   • 对于大规模，传统的消息传递系统举步维艰。
   • 依赖message broker，可能是性能瓶颈
   • 消息体较小，较大的消息会对消息传递代理造成严重压力
   • 取决于消费者的消费速度，存在快速消费
   • 容错，如果消息丢失或处理存在错误
5. 自定义中间件
   • 这是需要对数据存储有深入了解的地方
   • 越来越复杂，您很可能会处理分布式协调、错误处理、重复提交
   • 随着应用程序的每次更改，您都必须始终如一地重新测试代码
   • 一致性问题，数据一致性的挑战，尤其是当不同的速度处理多个数据源时
   • 可能很昂贵，考虑到必须编写自己的中间件并且管理整个代码库的维护
     

kafka背景

由于始终需要干净、可靠、快速和自主地移动数据，Linkedin在 2010 年提出了一种更好的方法来处理数据，而不会减慢或限制系统，即通过Kafka。
Apache Kafka通过分离数据流和系统来实现这一点。一旦你的数据在Kafka中，你就可以把它放在数据库、分析系统或审计中。

kafka消息传递目标

作为一个消息系统，Kafka 是由 Linkedin 构想的，其目标如下：

• 高吞吐量- 可以处理TB级的数据，甚至更大
• 高度可扩展- 可以通过集群的方式分摊负载
• 可靠耐用-在发生故障时传输数据不丢失
• 可复制-消息可以跨集群复制，支持多个订阅者
• 松散耦合- 应用程序的条件不应级联或影响其他应用程序
• 灵活的 发布-订阅-生产者和消费者模型

自 2009 年推出以来，Kafka 已被许多公司采用，2010 年 Linkedin 推出该解决方案，并于 2012 年在 Apache 软件基金会下开源。

应用场景

消息系统

• 应用程序可以生成消息而无需关心消息格式
• 内置分区
• 容错性和持久性
  

活动追踪

• Kafka 最初是在 Linkedin 设计的，用于跟踪用户活动
• 网站活动以每个活动类型一个主题发布
  

指标和日志记录

• 收集应用程序和系统日志指标
• 从分布式应用程序中积累数据
• 生成运营数据的集中提要
  

日志聚合

• 从服务器收集物理日志文件并将它们放在中心位置进行处理
• 通过将日志/事件数据生成为消息流来抽象文件的详细信息
  

流处理

• 实时操作数据，收到消息后立即处理
• 从 Kafka 主题消费原始输入数据，然后聚合、丰富，然后可以将其发送到另一个主题以供进一步消费
  

事件溯源(顺序性)

• 状态变化被记录为时间顺序的记录
  

系统解耦

大数据整合