kafka应用场景

kafka应用场景

• 活动跟踪：Kafka 可以用来跟踪用户行为，比如我们经常回去淘宝购物，你打开淘宝的那一刻，你的登陆信息，登陆次数都会作为消息传输到Kafka ，当你浏览购物的时候，你的浏览信息，你的搜索指数，你的购物爱好都会作为一个个消息传递给 Kafka
  ，这样就可以生成报告，可以做智能推荐，购买喜好等。

• 传递消息：Kafka另外一个基本用途是传递消息，应用程序向用户发送通知就是通过传递消息来实现的，这些应用组件可以生成消息，而不需要关心消息的格式，也不需要关心消息是如何发送的。

• 度量指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

• 日志记录：Kafka 的基本概念来源于提交日志，比如我们可以把数据库的更新发送到 Kafka上，用来记录数据库的更新时间，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

• 流式处理：流式处理是有一个能够提供多种应用程序的领域。

• 限流削峰：Kafka多用于互联网领域某一时刻请求特别多的情况下，可以把请求写入Kafka 中，避免直接请求后端程序导致服务崩溃。

用户订单处理

用户通过浏览器浏览商品并进行下单的动作。用户下单之后，应用程序通常会做如下的一些操作：

• 订单管理：为用户生成订单
• 库存管理：商品库存减1
• 积分管理：为用户增加积分

同步处理

请求处理：

• 在用户量大、并发度高的情况下请求同步处理需要等待，可能出现页面超长等待的问题：“哎呀，怎么这么慢，是不是没成功啊，再点几下，欸欸，电脑怎么卡死了。”

异步处理

为了有效地提升用户的体验，可以在用户下单之后，将订购消息发送至消息队列(kafka的延时可以做到毫秒级)，之后生成订单，返回给用户一个订购成功的消息。用户直接跳转到订单支付页面。大家看到这里的就涉及到同步和异步。

• 同步：推送消息和订单管理是同步进行的，为什么？因为订单的生成是不允许延时操作的，必须先有订单用户才能进行支付操作。
• 异步：库存管理和积分管理是异步操作？因为用户下单之后并不会关心商品库存是不是减少了；对于自己购买商品的积分，用户通常也不会特别关注时效性。所以采用异步处理方式。

解耦

• 在同步处理模型下，将生成订单、用户加积分、减库存操作写在一个单体应用中。修改订单可能影响用户积分，修改用户积分代码可能影响减库存。修改应用程序中的任何一部分代码，都需要将应用整体打包重新部署。这比较适合小团队、用户量小项目的开发模型。
• 在异步的处理模型下，可以将订单管理、积分管理、库存管理都单独拆分为一个服务独立运行、独立代码、独立部署，彼此之间通过消息队列或RPC进行交互。便于小团队知识聚合、专业度增强，代码质量的提升，单个服务测试难度的下降。当服务耦合度下降的时候，也意味着扩展能力的增强，面对更复杂的业务需求也更有的放矢。

数据缓冲

当我们使用到消息队列，一定意味着“单体应用”的方式已经无法满足我们的用户并发度需求，无法满足高速增长的业务量。

高并发的处理，通常有两种方式来缓解：

• 集群部署，增加应用实例部署规模，比如一个应用实例处理不过来的请求，通过部署多个实例来完成，配合有效的负载均衡处理高并发需求。也就是：“一个好汉三个帮”，自己干不过来就找人来一起干。
• 增加集群应用实例规模的方式固然有效，但是要考虑的一件事是：服务器资源是有限的，那么怎么在有限的生产力条件下，既能满足用户需求，又能合理的安排生产，这是“架构师”需要思考的事情。所以架构师将消息处理按照时效性分成两类：
  • 对于高时效性的消息数据进行实时同步处理，如：生成订单。
  • 对于低时效性、并发度又很高的数据，先缓冲起来。
    • 消息队列就是缓冲队列，缓冲的目的是降低后端服务处理瓶颈，根据消息队列后端消费服务的处理能力来拉取数据进行处理，而不是一下子把所有的数据全交给后端消费服务，把后端消费服务压死。如：增加积分、减少库存。

提升数据处理性能

消息队列已经缓冲了数据，就为我们进行消息的批处理创造了条件。
数据批量接收、批量处理、批量入库的操作，一定是比我们一条一条数据的处理操作性能更高的。

总结：

• 通过异步操作，减少同步操作的步骤 （将操作拆分出来，哪些需要异步操作，哪些可以同步操作），缩短用户浏览等待时间，提升了用户体验
• 有效地进行系统功能解耦，采用异步处理模型，能够有效的进行服务解耦。
• 高时效性的消息数据进行实时同步处理，低时效性、并发度又很高的数据，先缓冲起来，降低后端服务处理瓶颈，根据消息队列后端消费服务的处理能力来拉取数据进行处理
• 缓冲队列为进行消息的批处理创造了条件，提升数据处理性能