分区策略决定 producer 将消息怎么分发到 partition 中， 分区策略不合适可能导致数据倾斜， 有些时候我们需要实现顺序消息， 也需要将同一业务的消息都发送到同一个 partition 上。生产端将消息发送给 broker 之前主要经过拦截、序列化、分区(Partitioner)几个步骤。分区器主要读取 partition 配置(生产端配置partitioner.class, 默认值是 DefaultPartitioner)
接上篇 SDL 播放 PCM 音频文件，已经实现了 推 的模式去播放，接下来看看 拉 的模式如何实现。
使用kafka可以对系统解耦、流量削峰、缓冲，可以实现系统间的异步通信等。在活动追踪、消息传递、度量指标、日志记录和流式处理等场景中非常适合使用kafka。这篇文章主要介绍下kafka中的基本概念。
我们在做Android平台GB28181设备接入侧模块的时候，特别是执法记录仪或类似场景，系统除了对常规的录像有要求，还需要能和GB28181平台侧交互，比如实现设备侧视音频文件检索、下载或回放。本文假定记录仪或相关设备已经完成录像，主要来探讨下设备视音频文件检索相关。
应用从Kafka中读取数据需要使用KafkaConsumer订阅主题，然后接收这些主题的消息。在我们深入这些API之前，先来看下几个比较重要的概念。
Kafka 中默认的消费位移的提交方式为自动提交，这个由消费者客户端参数 enable.auto.commit 配置，默认值为 true 。这个默认的自动提交不是每消费一条消息就提交一次，而是定期提交，这个定期的周期时间由客户端 auto.commit.interval.ms 配置，默认值为 5 秒，此参数生效的前提是 enable.auto.commit 参数为 true；
对于推流端，经过releaseStream，createStream消息之后，得到了_result消息之后，接下来客户端就可以发起publish消息。推流端使用publish消息向rtmp服务器端发布一个命名的流，发布之后，任意客户端都可以以该名称请求视频、音频和数据。我们首先来看一下publish消息的组织结构：
点对点消息系统：生产者发送一条消息到queue，一个queue可以有很多消费者，但是一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有 一个可用的消费者，所以Queue实现了一个可靠的负载均衡。
多分区原子写入： 事务能够保证Kafka topic下每个分区的原⼦写⼊。事务中所有的消息都将被成功写⼊或者丢弃。 ⾸先，我们来考虑⼀下原⼦读取-处理-写⼊周期是什么意思。简⽽⾔之，这意味着如果某个应⽤程序在某个topic tp0的偏移量X处读取到了消息A，并且在对消息A进⾏了⼀些处理（如B = F（A）），之后将消息B写⼊topic tp1，则只有当消息A和B被认为被成功地消费并⼀起发布，或者完全不发布时，整个读取过程写⼊操作是原⼦的。 现在，只有当消息A的偏移量X被标记为已消费，消息A才从topic tp0消费，消费到的数据偏移量（record offset）将被标记为提交偏移量（Committing offset）。在Kafka中，我们通过写⼊⼀个名为offsets topic的内部Kafka topic来记录offset commit。消息仅在其offset被提交给offsets topic时才被认为成功消费。 由于offset commit只是对Kafka topic的另⼀次写⼊，并且由于消息仅在提交偏移量时被视为成功消费，所以跨多个主题和分区的原⼦写⼊也启⽤原⼦读取-处理-写⼊循环：提交偏移量X到offset topic和消息B到tp1的写⼊将是单个事务的⼀部分，所以整个步骤都是原⼦的。
客户端先将消息写入内存缓存， 多个消息形成一个个Batch， 然后send线程将多个Batch打包成一个request发送到kafka服务器上。
最简单的提交方式是让消费者自动提交偏移量。如果 enable.auto.commit 被设为 true，那么每过 5s，消费者会自动把从 poll() 方法接收到的最大偏移量提交上去。提交时间间隔由 auto.commit.interval.ms 控制，默认值是5s。消费者每次获取新数据时都会先把上一次poll()方法返回的最大偏移量提交上去。
导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与广泛开发者打造的分享交流窗口。栏目邀约腾讯技术人分享原创的技术积淀，与广泛开发者互启迪共成长。本文作者是腾讯后端开发工程师刘国强。 使用kafka可以对系统解耦、流量削峰、缓冲，可以实现系统间的异步通信等。在活动追踪、消息传递、度量指标、日志记录和流式处理等场景中非常适合使用kafka。这篇文章主要介绍下kafka中的基本概念。 kafka的整体结构 下图展示了很多关于kafka的细节，暂时
应用程序通过KafkaConsumer订阅一个topic之后收取数据来完成从kafka的数据读取。从kafka读取数据与从其他消息系统读取数据只有少许不同，几乎没用什么独特的概念。如果不理解这些概念，你将很难使用消费者API。我们首先对一些重要的概念进行解释，然后介绍一些示例，这些示例展示了使用消费者API在不同需求的应用程序中的不同方式。
Kafka 的 Producer 发送消息采用的是异步发送的方式。在消息发送的过程中，涉及到了两个线程——main 线程和 Sender 线程，以及一个线程共享变量——RecordAccumulator。main 线程将消息发送给 RecordAccumulator，Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka broker。
（1）Android：SDK 默认会将 log 写到 /sdcard/Android/data/应用包名/files/log/tencent/liteav/ 下。
在 Kafka 中，消费者通常是消费者群组的一部分，多个消费者群组共同读取同一个主题时，彼此之间互不影响。Kafka 之所以要引入消费者群组这个概念是因为 Kafka 消费者经常会做一些高延迟的操作，比如把数据写到数据库或 HDFS ，或者进行耗时的计算，在这些情况下，单个消费者无法跟上数据生成的速度。此时可以增加更多的消费者，让它们分担负载，分别处理部分分区的消息，这就是 Kafka 实现横向伸缩的主要手段。
Kafka 里消费者从属于消费者群组，一个群组里的消费者订阅的都是同一个主题，每个消费者接收主题一部分分区的消息。
消费者读取消息。在其他基于发布与订阅的消息系统中，消费者可能被称为订阅者 或 读者。
前两步和生产者类似，配置参数然后根据参数创建实例，区别在于消费者使用的是反序列化器，以及多了一个必填参数group.id，用于指定消费者所属的消费组。关于消费组的概念在《图解Kafka中的基本概念》中介绍过了，消费组使得消费者的消费能力可横向扩展，这次再介绍一个新的概念“再均衡”，其意思是将分区的所属权进行重新分配，发生于消费者中有新的消费者加入或者有消费者宕机的时候。我们先了解再均衡的概念，至于如何再均衡不在此深究。
新建一个 ConsumerAwareListenerErrorHandler 类型的异常处理方法，用@Bean注入，BeanName默认就是方法名，然后我们将这个异常处理器的BeanName放到@KafkaListener注解的errorHandler属性里面，当监听抛出异常的时候，则会自动调用异常处理器，
有一天，卡尔维护的购买系统发生了一个奇怪的异常，从日志里看到，购买后的任务处理竟然先于购买任务执行了。“不可能啊，按照代码的顺序，一定是先执行购买流程，再发送消息到kafka，最后消费端接收到消息后执行购买后的一些善后任务。从A到B到C，顺序清清楚楚。” 于是，他请教了马克，马克眯着眼睛细看了一会，道:"问题是不是出在这段@Transaction注解上？"
技术栈：React+recorder-tool.js +recorder.js + Express + Baidu语音识别API
Kafka存在丢消息的问题，消息丢失会发生在Broker，Producer和Consumer三种。
Broker丢失消息是由于Kafka本身的原因造成的，kafka为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。消息的刷盘过程，为了提高性能，减少刷盘次数，kafka采用了批量刷盘的做法。即，按照一定的消息量，和时间间隔进行刷盘。这种机制也是由于linux操作系统决定的。将数据存储到linux操作系统种，会先存储到页缓存（Page cache）中，按照时间或者其他条件进行刷盘（从page cache到file），或者通过fsync命令强制刷盘。数据在page cache中时，如果系统挂掉，数据会丢失。
Kafka存在丢消息的问题，消息丢失会发生在Broker，Producer和Consumer三种。Java面试宝典PDF完整版
在上文中介绍了Producer API的使用，现在我们已经知道如何将消息通过API发送到Kafka中了，那么现在的生产者/消费者模型就还差一位扮演消费者的角色了。因此，本文将介绍Consumer API的使用，使用API从Kafka中消费消息，让应用成为一个消费者角色。
一，KafkaConsumer使用要点解释 1，基本介绍 该客户端用户透明的处理kafka Broker的失败，透明的适应topic在集群中的迁移。这种客户端也可以使用消费者组的概念与kafka cluster进行交互，来进行均衡消费负载。 消费者维护着到必要的Broker上的TCP链接，用以获取data。使用之后未关闭消费者的话会导致链接泄漏。该消费者不是线程安全的，具体详见下文的多线程版本。 2，跨版本的兼容性 该版本的适用于kafka0.10+版本。老版本或者过新的版本会导致一些特征失效。比如，0.1
消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。适用于需要可靠的数据传送的分布式环境。
在N久之前，曾写过kafka 生产者使用详解， 今天补上关于 offset 相关的内容。 那么本文主要涉及：
使用MCI（媒体控制接口）播放音频文件，MCI为程序员提供了两种方式访问MCI设备或文件：一种是基于消息的命令接口函数；另一种是使用字符串接口函数。两者的区别在于基本命令结构和发送信息到设备的原理。 A.基于消息的MCI 消息命令控制接口使用消息控制MCI设备，将消息和控制信息以数据结构的形式作为函数参数发送，并接收返回的数据，MCI直接把设备消息和控制消息发送到设备。一条基于MCI的命令包含以下3个部分。 数据结构：该结构包含可传递给MCI驱动程序的信息和从驱动程序返回的值，指定要执行的MC
现在比较流行的分布式架构而言，它虽然带来一系列好处，比如支持高并发，高可用集群。同时它也带来一系列的挑战，今天我们将的就是其中一种挑战 - 分布式事务。
Android常用的录音工具有两种，分别是MediaRecorder和AudioRecord，前者用于录制普通音频，后者用于录制原始音频。然而无论是普通音频的amr和aac格式，还是原始音频的pcm格式，都不能在电脑上直接播放，也不能在苹果手机上播放，因为它们属于安卓手机的定制格式，并非通用的音频格式。若想让录音文件放之四海而皆能播放，就得事先将其转为通用的MP3格式，虽然Android官方的开发包不支持MP3转换，不过借助第三方的LAME库，能够将原始音频转存为MP3文件。 LAME是一个高质量的MP3编码器，它采用C/C++代码开发，需要通过JNI技术引入到App工程。LAME源码的下载页面为https://lame.sourceforge.io/download.php，笔者找到的最新版本是3.100，先解压下载完成的源码包，再按照下列步骤依次调整源码细节： 1、把源码包里面的libmp3lame目录整个复制到App模块的jni目录下； 2、把include目录下的lame.h头文件复制到jni\libmp3lame目录下； 3、打开jni\libmp3lame下面的set_get.h，把这行代码
在开发小程序过程中，有一个实现录音功能并播放录音，将录音上传至服务器的需求。开发过程中使用了Taro框架，录音功能通过Taro.getRecorderManager()接口实现，上传录音至服务器通过Taro.uploadFile接口实现，播放录音使用Taro.createInnerAudioContext()接口实现。下面就详细介绍整个流程是如何实现的。
Kafka是一个分布式的消息队列系统，它的出现解决了传统消息队列系统的吞吐量瓶颈问题。
概述 Apache Kafka-消息丢失分析 及 ACK机制探究 我们这里配了个manual, 为啥子嘛 AckMode源码解读 我们来看下 Spring Kafka封装的ACK Containe
每个消费者对应一个消费组，当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。如下图所示：
那在上一篇文章中我们了解了 消费者偏移量__consumer_offsets_,知道了 消费者在消费了消息之后会把消费的offset 更新到以 名称为__consumer_offsets_的内置Topic中; 每个消费组都有维护一个当前消费组的offset; 那么就会有以下疑问
Kafka只对“已提交”的消息（committed message）做有限度的持久化保证。
互动白板提供了云端实时录制功能，可以录下白板画面。同时也支持混流录制，将实时音视频与白板画面混流录制，也支持白板与音频或视频混流录制。
上面两篇聊了Kafka概况和Kafka生产者，包含了Kafka的基本概念、设计原理、设计核心以及生产者的核心原理。本篇单独聊聊Kafka的消费者，包括如下内容：
这几天很忙，但是我现在给我的要求是一周至少要出一篇文章，所以先拿这篇笔记来做开胃菜，源码分析估计明后两天应该能写一篇。给自己加油~，即使没什么人看。
许多数字音频系统正被引入消费者音频市场，包括CD，磁带，数字声音处理器和数字电视声音。在这些系统中的数字音频信号需要由许许多多(Very-large-scale integration)的IC组成，处理。在音频系统中常见的IC芯片有:
只管发送， 不管结果： 只调用接口发送消息到 Kafka 服务器， 但不管成功写入与否。 由于 Kafka 是高可用的， 因此大部分情 况下消息都会写入， 但在异常情况下会丢消息。
本文是SpringBoot+Kafka的实战讲解，如果对kafka的架构原理还不了解的读者，建议先看一下《大白话kafka架构原理》、《秒懂kafka HA（高可用）》两篇文章。
在 Kafka 中，每当消费者组内的消费者查找不到所记录的消费位移或发生位移越界时，就会根据消费者客户端参数 auto.offset.reset 的配置来决定从何处开始进行消费，这个参数的默认值为 “latest” 。
高可用是很多分布式系统中必备的特征之一，Kafka 日志的高可用是通过基于 leader-follower 的多副本同步实现的，每个分区下有多个副本，其中只有一个是 leader 副本，提供发送和消费消息，其余都是 follower 副本，不断地发送 fetch 请求给 leader 副本以同步消息，如果 leader 在整个集群运行过程中不发生故障，follower 副本不会起到任何作用，问题就在于任何系统都不能保证其稳定运行，当 leader 副本所在的 broker 崩溃之后，其中一个 follower 副本就会成为该分区下新的 leader 副本，那么问题来了，在选为新的 leader 副本时，会导致消息丢失或者离散吗？Kafka 是如何解决 leader 副本变更时消息不会出错？以及 leader 与 follower 副本之间的数据同步是如何进行的？带着这几个问题，我们接着往下看，一起揭开 Kafka 水印备份的神秘面纱。
分布式事务是微服务实践中一个比较棘手的问题，在笔者所实施的微服务实践方案中，都采用了折中或者规避强一致性的方案。参考Ebay多年前提出的本地消息表方案，基于RabbitMQ和MySQL（JDBC）做了轻量级的封装，实现了低入侵性的事务消息模块。本文的内容就是详细分析整个方案的设计思路和实施。环境依赖如下：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
