Kafka

消息队列之堆积问题分析及各种解决方案 问题描述 在高并发的场景中，消息积压问题，可以说如影随形，真的没办法从根本上解决。表面上看，已经解决了，但后面不知道什么时候，就会冒出一次，比如这次： 有天下午，

确保消息可靠传递 如何知道消息丢失 解决思路： 利用消息队列的有序性来验证是否有消息丢失。 在消息生产端，给每个发出的消息都指定一个附加一个连续底层的版本号，然后在消费端检验序号的连续性。 落地方案：

分布式事务 分布式事务产生的原因 在实际的开发当中，分布式事务产生的原因主要是来源于存储、服务的拆分。 存储层拆分 存储层拆分，最典型的就是数据库分库分表。（一般单表数据达到千万级就要进行拆分） 服务

消息队列的应用场景 从秒杀开始说起 类似于秒杀的场景，短时间内需要处理大量的请求的，需要涉及两个东西，一个是缓存，一个是MQ。 首先从头来分析整个的流程到底是什么样的。 假如说我想举行一个秒杀活动，我

幂等性 幂等性要点 Kafka 0.11.0.0 版本开始引入了幂等性与事务这两个特性，以此来实现 EOS ( exactly once semantics ，精确一次处理语义） 生产者在进行发送失败

消息的精准消费 在前面学到的手动提交位移的时机选择的时候 数据处理完成之前先提交偏移量 可能会发生漏处理的现象（数据丢失） 反过来说，这种方式实现了： at most once 的数据处理（传递）语义

Kafka系统基本架构 自我推导设计： kafka 是用来存数据 现实世界数据有分类，所以存储系统也应有数据分类管理功能，如 mysql 的表；kafka 有 topic； 如一个 topic 的数据

练习 需求： 写一个生产者，不断地去生成“用户行为事件” 并写入kafka {“guid”:1,"eventId":"pageview","timestamp":163786834789} {“gui

API 开发：producer 生产者 生产者 api 示例 一个正常的生产逻辑需要具备以下几个步骤 （1）配置生产者参数及创建相应的生产者实例 （2）构建待发送的消息 （3）发送消息 （4）关闭生产

安装部署 安装 zookeeper 集群 配置zookeeper集群的核心就是，以下每个zookeeper都要有 安装 kafka 集群 核心操作如下： 查看框架兼容的版本：查看依赖的pom / 要去

基本概念 什么是kafka？ Kafka 最初是由 LinkedIn 即领英公司基于 Scala 和 Java 语言开发的分布式消息发布-订阅系统，现 已捐献给 Apache 软件基金会。其具有高吞吐