暂时未有相关云产品技术能力~
微信公众号「后端进阶」作者,技术博客(https://objcoding.com/)博主,Seata Committer,GitHub ID:objcoding。
上周客串了一下面试官,在这里就简单记录一下期间我问到的一些关于 Kafka 的面试题目,这些都是我平时在学习 Kafka 的一些总结要点。
之前有个 Kafka 集群的每个节点的挂载磁盘多达 20+ 个,平均每个磁盘约 1T,每个节点的分区日志被平均分配到这些磁盘中,但由于每个分区的数据不一致,而集群节点 log.retention.bytes 这个参数的默认值是 -1,也就是没有任何限制,因此 Kafka 的日志删除日志依赖 log.retention.hours 参数来删除,因此会出现日志未过期,磁盘写满的情况。 针对该集群双十一会遇到某些挂载磁盘被写满的情况,需要手动对主题进行删除以清空磁盘的操作,现在分析删除主题对集群以及客户端会有什么影响,以及 Kafka 都做了哪些动作。
这是很早以前在我的博客上写的关于 SpringCloud 的一些实战笔记,现在我把这些实战笔记集合起来贴到这里,可能会对一些刚刚接触 SpringCloud 微服务的小伙伴有帮助。
ISR(in-sync replica) 就是 Kafka 为某个分区维护的一组同步集合,即每个分区都有自己的一个 ISR 集合,处于 ISR 集合中的副本,意味着 follower 副本与 leader 副本保持同步状态,只有处于 ISR 集合中的副本才有资格被选举为 leader。一条 Kafka 消息,只有被 ISR 中的副本都接收到,才被视为“已同步”状态。这跟 zk 的同步机制不一样,zk 只需要超过半数节点写入,就可被视为已写入成功。
RocketMQ 消息消费进度是如何提交的,并发消费的时候,一次从 一个队列拉 32 条消息,这 32 条消息会提交到线程池中处理,如果偏移量 m5 比 m4 先执行完成,消息消费后,提交的消费进度是哪个?是提交消息 m5 的偏移量?
纯粹是为了记录搭建的过程。忘了就翻来看看
纯粹是为了记录搭建的过程。忘了就翻来看看。
最近在 RocketMQ 钉钉官方群中看到有人反馈说 broker 主从部署,在发布消息的时候会报 SLAVE_NOT_AVAILABLE 异常,报这个异常的前提 master 的模式一定为 SYNC_MASTER(同步复制),从 异常码可以直接判断的一种原因就是因为 slave 挂掉了,导致 slave 不可用,但是他说 slave 一切正常。 于是我决定撸一波源码。
在选为新的 leader 副本时,会导致消息丢失或者离散吗?Kafka 是如何解决 leader 副本变更时消息不会出错?以及 leader 与 follower 副本之间的数据同步是如何进行的?带着这几个问题,我们接着往下看,一起揭开 Kafka 水印备份的神秘面纱。
上一篇跟大家描述了 Kafka 集群扩容的方案与过程,这次就跟大家详细描述 Kafka 分区重分配的实现细节。
前段时间收到某个 Kafka 集群的生产客户端反馈发送消息耗时很高,于是花了一段时间去排查这个问题,最后该集群进行扩容,由于某些主题的当前数据量实在太大,在对这些主题迁移过程中花费了很长一段时间,不过这个过程还算顺利,因为在迁移过程中也做足了各方面的调研,包括分区重平衡过程中对客户端的影响,以及对整个集群的性能影响等,特此将这个过程总结一下,也为双十一打了一剂强心剂。
其实最好的学习方式就是互相交流,最近也有跟网友讨论了一些关于 RocketMQ 消息拉取与重平衡的问题,我姑且在这里写下我的一些总结。
当集群中有新成员加入,或者某些主题增加了分区之后,消费者是怎么进行重新分配分区再进行消费的?这里就涉及到重平衡(Rebalance)的概念,下面我就给大家讲解一下什么是 Kafka 重平衡机制,我尽量做到图文并茂通俗易懂。
还记得前几天有个小伙伴跟我反馈发送消息时提示请求数据过大的异常吗?经过调整 max.request.size 的大小之后,又报了了如下异常
前面我也跟大家讲述了 RocketMQ 读写分离的规则,但是你可能会问,主从服务器之间的消费进度是如何保持同步的?下面我来给大家解答一下。
一般来说,选择主从备份实现高可用的架构中,都会具备读写分离机制,比如 MySql 读写分离,客户端可以向主从服务器读取数据,但客户写数据只能通过主服务器。 RocketMQ 的读写分离机制又跟上述描写的不太一致,RocketMQ 有属于自己的一套读写分离逻辑,它会判断主服务器的消息堆积量来决定消费者是否向从服务器拉取消息消费。
之前写了一篇关于 RocketMQ 队列与 Kafka 分区副本的区别文章,里面提到了 RocketMQ 的消息冗余主要是通过主备同步机制实现的,这跟 Kafka 分区副本的 Leader-Follower 模型不同,HA(High Available) 指的是高可用性,而 RocketMQ 是通过主备同步(HA 机制)实现消息的高可用。
今天有个小伙伴跟我反馈,在 Kafka 客户端他明明设置了 batch.size 参数,以提高 producer 的吞吐量,但他发现报了如下错误
RocketMQ Broker启动流程梳理
最近在学习 Kafka,发现其核心概念与 RocketMQ 还是存在一定的差别,下面我来说下 Kafka 分区 与 RocketMQ 队列之间的区别。
Go 语言中 new 和 make 都是内置函数,用于内存的分配,本文主要简述两者使用上的异同与特性。
前段时间有个朋友向我提了一个问题,他说在搭建 RocketMQ 集群过程中遇到了关于消费订阅的问题
因为待过的几家公司,用的都是微服务架构,但是在解决分布式事务的问题上都不太优雅,所以我也在一直关注 Seata 的发展,今天就简要说说它的一些设计上的原理,后续我将会对它的各个模块进行深入源码分析,感兴趣的可以持续关注我的公众号或者博客,不要跟丢。
随着 Go1.11 的发布,Golang 给我们带来了 module 全新特性,这是 Golang 新的一套依赖管理系统。现在 Go1.12 已经发布了,go modules 进一步稳定,但官方还是没有将其设为默认机制,所以踩坑之路是必须的,本篇文章除了详细说明 go modules 的特性以及使用之外,还总结了我在这个过程中遇到的一些“坑”。
以下,我会从时区的概念来跟你们解释一下,为什么用数值保存时间戳是最好的方案,同时也为了分享出来,让更多开发小伙伴留意这些细节性的东西。 相信时区对于很多人来说的很熟悉,因为地球是圆的,在地球上不同角落看到的太阳上升的角度都是不同的,即每个人对于时间的显示都是不一样的,
我们都知道如果用 docker hub 来做仓库会很慢,因为docker hub 服务器在国外,那么现在有必要讲一下如何搭建一个 docker 私有仓库,并进行快速部署。
制作镜像一般有三种方法,第一种是 run 一个基础容器,在里面下载好我们需要的东西,然后通过 docker commit 命令生成一个新的镜像,第二种方法是基于本地模版导入,第三种就是这篇文章说的基于 Dockerfile 创建。
Docker 也是作为我的第二技能栈之一,除了 Go 语言,Docker 是我最喜欢的第二技能栈了,值得一提的是,Docker 是 Go 语言编写的。现在很多公司已经全面实现项目部署的容器化,这也是未来发展的一个方向,所以我也会在这里推一些关于 Docker 的文章。
SSH 可分为客户端和服务端,服务端是一个守护进程,一般是 sshd 进程,在后台运行并响应来自客户端的请求,提供了对远程请求的处理,一般包括公共密钥认证、密钥交换、对称密钥加密和非安全连接;客户端一般是 SSH 进程,另外还包含 scp、slogin、sftp 等其他进程。 这篇文章主要讲如何 SSH 连接远程终端,以此记录一下整个配置过程。
我在前一家公司的第一个任务是开发统一支付平台,由于公司的业务需求,需要接入多个第三方支付,之前公司的支付都是散落在各个项目中,及其不利于支付的管理,于是聚合三方支付,统一支付平台的任务就落在我手上,可以说是完全从 0 开始设计,经过一翻实战总结,我得出了一些架构设计上的思考,之前就一直很想把自己的架构设计思路写出来,但一直没动手,前几天在技术群里有人问到相关问题,我觉得有必要把它写出来,以帮助到更多需要开发支付平台的开发人员。
Tomcat 里面藏着很多值得我们每个 Java WEB 开发者学习的知识,可以这么说,当你弄懂了 Tomcat 的设计原理,Java WEB 开发对你来说已经没有什么秘密可言了。本篇文章主要是跟大家聊聊 Tomcat 的内部架构体系,让大家对 Tomcat 有个整体的认知。
这篇文章主要是说一下 Go 的工作目录与编译的规则,初步体验一下 Go 的大道至简的魅力。
公司的某些业务用到了数据库的悲观锁 for update,但有些同事没有把 for update 放在 Spring 事务中执行,在并发场景下发生了严重的线程阻塞问题,为了把这个问题吃透,秉承着老司机的职业素养,我决定要给同事们一个交代。
SpringBoot 项目就是由一个一个 Starter 组成的,一个 Starter 代表该项目的 SpringBoot 起步依赖,除了官方已有的 Starter,如果你需要将自己的项目支持 SpringBoot,那么就需要把它制作成一个 Starter。
我在 Java并发之AQS源码分析(一)这篇文章中,从源码的角度深度剖析了 AQS 独占锁模式下的获取锁与释放锁的逻辑,如果你把这部分搞明白了,再看共享锁的实现原理,思路就会清晰很多。下面我们继续从源码中窥探共享锁的实现原理。
AQS 全称是 AbstractQueuedSynchronizer,顾名思义,是一个用来构建锁和同步器的框架,它底层用了 CAS 技术来保证操作的原子性,同时利用 FIFO 队列实现线程间的锁竞争,将基础的同步相关抽象细节放在 AQS,这也是 ReentrantLock、CountDownLatch 等同步工具实现同步的底层实现机制。它能够成为实现大部分同步需求的基础,也是 J.U.C 并发包同步的核心基础组件。
在讲解完线程池的构造参数和一些不常用的设置之后,有些同学还是想继续深入地了解线程池的原理,所以这篇文章科代表会带大家深入源码,从底层吃透线程池的运行原理。
初始化线程池时可以预先创建线程吗?线程池的核心线程可以被回收吗?为什么?
现有一个线程池,参数corePoolSize = 5,maximumPoolSize = 10,BlockingQueue阻塞队列长度为5,此时有4个任务同时进来,问:线程池会创建几条线程? 如果4个任务还没处理完,这时又同时进来2个任务,问:线程池又会创建几条线程还是不会创建? 如果前面6个任务还是没有处理完,这时又同时进来5个任务,问:线程池又会创建几条线程还是不会创建?
从rocketmq topic的创建机制可知,一个topic对应有多个消息队列,那么我们在发送消息时,是如何选择消息队列进行发送的?假如这时有broker宕机了,rocketmq是如何规避故障broker的?看完这篇文章,相信你会从文中找到答案。
在撸完RocketMQ Topic的创建机制后,我似乎还有一些意犹未尽的感觉,总觉得还缺一些什么。于是我就趁热打铁,提出以下两点我自己的一些思考。 当集群新增master节点后,如何保证队列负载?如何在集群中固定队列数量?
我还记得第一次使用rocketmq的时候,需要去控制台预先创建topic,我当时就想为什么要这么设计,于是我决定撸一波源码,带大家从根源上吃透rocketmq topic的创建机制。
我们都知道docker logs -f会将所有对应的服务日志输出到终端,无论服务的部署在哪个节点上,那么我现在提出一个问题,是否每个节点对应的容器文件,都会保存该服务的完整日志备份,还是只保存该节点服务对应容器产生的日志?
坐在我旁边的钟同学听说我精通Mybatis源码(我就想不通,是谁透漏了风声),就顺带问了我一个问题:在同一个方法中,Mybatis多次请求数据库,是否要创建多个SqlSession会话?
mybatis-plus是完全基于mybatis开发的一个增强工具,它的设计理念是在mybatis的基础上只做增强不做改变,为简化开发、提高效率而生,它在mybatis的基础上增加了很多实用性的功能,比如增加了乐观锁插件、字段自动填充功能、分页插件、条件构造器、sql注入器等等,这些在开发过程中都是非常实用的功能,mybatis-plus可谓是站在巨人的肩膀上进行了一系列的创新,我个人极力推荐。下面我会详细地从源码的角度分析mybatis-plus(下文简写成mp)是如何实现sql自动注入的原理。
「Mybatis源码分析之Mapper注册与绑定」讲到了 Mapper 如何注册到 Configuration 类中与 MapperProxyFactory 绑定的过程,我们平时的使用场景一般都配合着 Spring,使用 Spring 意味着需要注册 Bean,也就是说需要将 Mapper 的代理实现类注册到 Spring 容器中,成为 Spring 容器中的一个 Bean。
Mybatis 是一个「面向 sql」的持久层框架,它可实现动态拼装 sql,极其灵活,同时避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集,其插件机制允许在已映射语句执行过程中的某一点进行拦截调用等等,让我忍不住想要撸一撸它的源码。
SpringBoot 的自动化配置让我们的开发彻底远离了 Spring 繁琐的各种配置,让我们专注于开发,但是SpringBoot 的自动化配置是怎么实现的呢?下面为你揭开 SpringBoot 自动化配置的神秘面纱。
在早期的docker版本中,是不支持跨主机通信网络驱动的,也就是说如果容器部署在不同的节点上面,只能通过暴露端口到宿主机上,再通过宿主机之间进行通信。随着docker swarm集群的推广,docker也有了自家的跨主机通信网络驱动,名叫overlay,overlay网络模型是swarm集群容器间通信的载体,将服务加入到同一个网段上的Overlay网络上,服务与服务之间就能够通信。
最近在公司推行Docker Swarm集群的过程中,需要用到Jenkins来做自动化部署,Jenkins实现自动化部署有很多种方案,可以直接在jenkins页面写Job,把一些操作和脚本都通过页面设置,也可以在每个项目中直接写Pipeline脚本,但像我那么追求极致的程序员来说,这些方案都打动不了我那颗骚动的心,下面我会跟你们讲讲我是如何通过Pipeline脚本实现自动化部署方案的,并且实现多分支构建,还实现了所有项目共享一个Pipeline脚本