Kafka

导读 9月最新产品动态简报： 1. 腾讯微服务平台TSF：新增不健康实例的监控信息；新增“屏蔽实例”的新功能。 2.消息队列CKafka：访问白名单配置可使用IP网段；支持在Partition维度设置offset；监控支持按带宽百分比进行监控；支持控制台查询消息。 3.分布式事务DTF：用户可在本地调试分布式事务。 4.分布式任务调度TCT：支持分片任务断点续跑能力；开放任务调度API；分片任务支持可选分片参数告警选项；分片任务支持参数传递。 ● 产品最新动态 ● 腾讯微服务平台TSF 产品介绍：稳定、高性能的微服务技术中台。 新功能特性 1. 更完善的服务监控能力：新增不健康实例的监控信息 在服务治理详情页，服务实例列表上增加离线的实例展示，同时显示实例的注册时间和上一次心跳时间。帮助用户查看由于异常而下线的实例信息，当服务实例和注册中心的连接断开时，用户能了解上一次心跳的时间和注册时间。 2. 更灵活的服务治理：新增屏蔽实例操作 在服务治理详情页，服务实例增加【屏蔽实例】操作，启用该功能后，实例不会被其他服务发现，避免流量发送到问题实例上。例如：当服务实例不可用但仍连接到注册中心时，为了避免流量发送到问题实例上可手动下线实例。 扫码了解更多相关信息 消息队列CKafka 产品介绍：分布式、高吞吐量、高可扩展性的消息服务，具备 数据压缩 、同时 支持离线和实时数据处理 等优点。

继上周的《Kafka生产者的使用和原理》，这周我们学习下消费者，仍然还是先从一个消费者的Hello World学起： public class Consumer { public static void main(String[] args) { // 1. 配置参数 Properties properties = new Properties(); properties.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); properties.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); properties.put("bootstrap.servers", "localhost:9092"); properties.put("group.id", "group.demo"); // 2. 根据参数创建KafkaConsumer实例（消费者） KafkaConsumer<String, String> consumer = new KafkaConsumer<>(properties); // 3. 订阅主题 consumer

大家都知道程序员涨薪主要还是要靠跳槽来完成！但是我们都知道，无论是考试，还是求职，这个难度，参加人数是影响难度的一个很大因数，最近和不少出去面试的朋友闲聊，都发现，两年前面试高级开发，会 JUC 、 JVM 相关的知识点都是加分项，现在反而成了基本要求，不会这些，面试都是被吊起来打！ 哎~~也不想多说什么了，说多都是泪。下面是我这两个月以来去几个厂子面试的经历总结。有兴趣的可以观摩下。 华为三面（消费者BG通用软件开发）-(差一点） 一面 9月15号 40分钟左右 四点面试结果三点半电话通知可以上线面试了 聊了聊实习期间做的项目 进程间的通讯方式 操作系统的虚拟内存 因为实习是做android的，聊了两道android的问题 两道算法： 1.判断IPV4地址的合法性 2.leetcode上原题根据身高体重对数组进行重新排序 二面 9月17号 40分钟左右 五点面试结果五点十五才开始 聊了聊实习做的项目25分钟左右 leetcode上原题：例如：3[ab2[cd]]还原为abcdcdabcdcdabcdcd 例如 2[a3[d]]还原为 adddaddd 反问问了问部门做什么的 三面 9月18号 15分钟左右 三点面试结果2点40电话通知可以面试了 十分钟介绍了下实习做的项目，有什么难点，怎么去解决，有什么收获 为什么今年华为遇到危机还是选择要加入华为（谨慎回答） 反问

最近用了用kafka，踩了各种各样的坑（一口老血）。其中最让人头疼的是消费失败后的重发问题，目前我自己的解决办法是消费该分区的某批数据时，如果该批数据有消费失败的，就不提交该批数据的偏移量，从而让生产者重发数据。然而只有在重启生产者时，消费失败的数据才能重新消费，非常谜，打算以后抽出时间看看这是为啥（如果有解决办法请 大力评论 。。我的kafka版本是0.10你懂的）。 然后我在找kafka相关解决办法的时候，发现rocketmq的重发机制十分好，于是决定再踩踩rocketmq的坑。 单机部署 单机部署rocketmq4.2.0尝尝鲜（三口老血），到rocketmq的官网里找到quick start（我现在理解的quick大约得有一百万年的时间），有个单机部署教程（http://rocketmq.apache.org/docs/quick-start/），然而里面的坑很多。所以在此记录一下我的安装历程： 1.安装环境要遵循官方的建议（环境的安装在此不赘述） 64bit OS, Linux/Unix/Mac is recommended; 64bit JDK 1.8+; Maven 3.2.x Git 2.下载安装包，并解压： unzip rocketmq-all-4.2.0-source-release.zip 3.进入解压后的文件的根目录，编译： mvn -Prelease

Kafka网络模型 摘要：很多人喜欢把RocketMQ与 Kafka 做对比，其实这两款消息队列的网络通信层还是比较相似的，本文就为大家简要地介绍下Kafka的NIO网络通信模型，通过对Kafka源码的分析来简述其Reactor的多线程网络通信模型和总体框架结构，同时简要介绍Kafka网络通信层的设计与具体实现。 一、Kafka网络通信模型的整体框架概述 Kafka的网络通信模型是基于NIO的Reactor多线程模型来设计的。这里先引用Kafka源码中注释的一段话： 相信大家看了上面的这段引文注释后，大致可以了解到Kafka的网络通信层模型，主要采用了 1（1个Acceptor线程）+N（N个Processor线程）+M（M个业务处理线程） 。下面的表格简要的列举了下（这里先简单的看下后面还会详细说明）： 线程数线程名线程具体说明1kafka-socket-acceptor_%xAcceptor线程，负责监听Client端发起的请求Nkafka-network-thread_%dProcessor线程，负责对Socket进行读写Mkafka-request-handler-_%dWorker线程，处理具体的业务逻辑并生成Response返回 Kafka网络通信层的完整框架图如下图所示： Kafka消息队列的通信层模型—1+N+M模型.png

一、消息队列(MQ)概述 消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为： 当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。 消息队列主要解决了应用耦合、异步处理、流量削锋等问题。 当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。 二、消息队列使用场景 消息队列在实际应用中包括如下四个场景： 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败； 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间； 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况； 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理； 下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用： 2.1 异步处理 具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。 （1）串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信； 在这种方式下

相关推荐： kafka集群扩容后的数据均衡 kafka数据存储目录间迁移 kafka分区数过多引发的弊端 戳原文，点在看！ 本文分享自微信公众号 - 极客运维（hypernetworker）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“ OSC源创计划 ”，欢迎正在阅读的你也加入，一起分享。 来源： oschina 链接： https://my.oschina.net/u/4525966/blog/4481555

每个时代，都不会亏待会学习的人。 大家好，我是 yes。 今天我们来谈一谈消息队列的事务消息，一说起事务相信大家都不陌生，脑海里蹦出来的就是 ACID。 通常我们理解的事务就是为了一些更新操作要么都成功，要么都失败，不会有中间状态的产生，而 ACID 是一个严格的事务实现的定义，不过在单体系统时候一般都不会严格的遵循 ACID 的约束来实现事务，更别说分布式系统了。 分布式系统往往只能妥协到最终一致性 ，保证数据最终的完整性和一致性，主要原因就是实力不允许...因为可用性为王。 而且要保证完全版的事务实现代价很大，你想想要维护这么多系统的数据，不允许有中间状态数据可以被读取，所有的操作必须不可分割，这意味着一个事务的执行是阻塞的，资源是被长时间锁定的。 在高并发情况下资源被长时间的占用，就是致命的伤害，举一个有味道的例子，如厕高峰期，好了懂得都懂。 对了， ACID 是什么还不太清楚的同学，赶紧去查一查，这里我就不展开说了。 分布式事务 那说到分布式事务，常见的有 2PC、TCC 和事务消息，这篇文章重点就是事务消息，不过 2PC 和 TCC 我稍微提一下。 2PC 2PC 就是二阶段提交，分别有协调者和参与者两个角色，二阶段分别是准备阶段和提交阶段。 准备阶段就是协调者向各参与者发送准备命令，这个阶段参与者除了事务的提交啥都做了，而提交阶段就是协调者看看各个参与者准备阶段都 o

一说起事务相信大家都不陌生，脑海里蹦出来的就是 ACID。 通常我们理解的事务就是为了一些更新操作要么都成功，要么都失败，不会有中间状态的产生，而 ACID 是一个严格的事务实现的定义，不过在单体系统时候一般都不会严格的遵循 ACID 的约束来实现事务，更别说分布式系统了。 分布式系统往往只能妥协到最终一致性 ，保证数据最终的完整性和一致性，主要原因就是实力不允许...因为可用性为王。 而且要保证完全版的事务实现代价很大，你想想要维护这么多系统的数据，不允许有中间状态数据可以被读取，所有的操作必须不可分割，这意味着一个事务的执行是阻塞的，资源是被长时间锁定的。 在高并发情况下资源被长时间的占用，就是致命的伤害，举一个有味道的例子，如厕高峰期，好了懂得都懂。 对了， ACID 是什么还不太清楚的同学，赶紧去查一查，这里我就不展开说了。 分布式事务 那说到分布式事务，常见的有 2PC、TCC 和事务消息，这篇文章重点就是事务消息，不过 2PC 和 TCC 我稍微提一下。 2PC 2PC 就是二阶段提交，分别有协调者和参与者两个角色，二阶段分别是准备阶段和提交阶段。 准备阶段就是协调者向各参与者发送准备命令，这个阶段参与者除了事务的提交啥都做了，而提交阶段就是协调者看看各个参与者准备阶段都 o 不 ok，如果有 ok 那么就向各个参与者发送提交命令，如果有一个不 ok 那么就发送回滚命令

关于 MQ 的定义 Message Queue （ MQ ）消息队列中间件，通常我们在网上看到的对其定义是将消息的发送和接受分离来实现应用程序的异步和解耦，给人的直觉是 MQ 是异步的，用来解耦的。但这个只是 MQ 的效果，而不是目的。 MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层上更加简单的通讯协议。 一套分布式系统中两个模块之间通讯要么是 HTTP ，要么是 TCP ，但这两种协议其实都是原始的协议。前者实现通讯就必须要做到各客户端都有 WebServer ，而且不支持长连接；后者就更加原始了 — 粘包、心跳、私有的协议。 而 MQ 所要做就是在基于这些现有的协议之上构建一个更简单的通讯（生产者/消费者）模型。它定义了两个对象 —发送数据的叫生产者，接受数据的叫消费者，提供一个 SDK 给我们自己定义生产者和消费者实现消息通讯，且无视底层通讯协议。 带 Broker 的流派 这个流派通常有一台服务器作为 Broker ，所有的消息都通过它进行中转。生产者把消息发送给它就结束自己的任务了，最后 Broker 则把消息主动推送给消费者（或者消费者主动轮询）。 重 Topic 的 MQ Kafka 、 Active MQ 就属于这个流派：生产者发送 key 和数据到 Broker ，由 Broker 比较 key 之后决定给哪个消费者。 在这种模式下，