暂时未有相关云产品技术能力~
微信公众号「后端进阶」作者,技术博客(https://objcoding.com/)博主,Seata Committer,GitHub ID:objcoding。
Seata 目前支持 AT 模式、XA 模式、TCC 模式和 SAGA 模式,之前文章更多谈及的是非侵入式的 AT 模式,今天带大家认识一下同样是二阶段提交的 TCC 模式。
Seata AT 模式是一种非侵入式的分布式事务解决方案,Seata 在内部做了对数据库操作的代理层,我们使用 Seata AT 模式时,实际上用的是 Seata 自带的数据源代理 DataSourceProxy,Seata 在这层代理中加入了很多逻辑,比如插入回滚 undo_log 日志,检查全局锁等。
互联网的系统常常面临庞大的用户群体,意味着系统需要时刻面临着大量高并发请求,海量的数据存储等问题的挑战,在解决这些问题的同时还要保证系统的高可用性。同时互联网行业更新迭代快,很多互联网巨头的发展初始阶段,为了快速把产品上线发布以占据用户流量,会以最简单的应用架构形态对系统进行部署,不会过多地考虑未来的应用架构的发展,所以很多互联网公司发展到一定规模,都会进行相应的架构重构与改进,以便适应业务的发展。
上次讲到 Raft 领导者选举:「图解 Raft 共识算法:如何选举领导者?」,接着这个话题继续跟大家聊下关于 Raft 日志复制的一些细节。
“工欲善其事,必先利其器。” 我在工作中也用到一些使用起来非常高效的工具,今天以 “代码即格式” 为主题,跟大家介绍下两个高效工具。
在之前的工作经历中,我做过营销相关项目,接触过关于票券秒杀的高并发场景,秒杀场景也算是最热门的高并发场景之一了。 下面我就把我对秒杀场景的一些理解简单写下来,仅供大家参考,欢迎留言纠错或者补充。
IDEA 被越来越多的 Java 开发者所接受,我也不例外,当年刚入职场时用的是 Eclipse,后来看到有同事用 IDEA,我也跟风下载了使用了,之后再也回不去 Eclipse 了,相比 Eclipse,IDEA 简直好用到爆,无论是从界面 UI,还是智能提示,完爆 Eclipse 好吗?在我心目中,IDEA 是最好用的 IDE,没有之一!
Seata 是一款开源的分布式事务解决方案,star 高达 19200+,社区活跃度极高,致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
Raft 是通过以领导者为准实现各个节点日志一致的一种共识算法,被越来越多的分布式系统框架应用,比如 Etcd、Consul 等等,Seata 未来也会引用 Raft,即将发布的 Kafka 2.8 也引入了 Raft,在 Raft 的基础上做了一些改版,在 Kafka 2.8 中称作 KRaft。 由此看来,Raft 是目前大部分分布式系统的首选共识算法,学习 Raft 将有助于你在分布式领域中如鱼得水。 本文主要内容为我对 Raft 选举领导者的一些理解总结。
ZCache 是中通下一代缓存服务平台,实现多种缓存类型自动部署,提供 Proxy 访问层,通过 Proxy 层提供指令限制、访问权限、限流、分片处理等功能,通过自研 K8s Operator 实现自动部署与故障转移,实现集群的高可用,提供完善统计、监控、运维功能、减少运维成本和误操作,提高机器的利用率,提供灵活的伸缩性,方便用户接入缓存服务。
ZMS 脱胎于中通内部对消息引擎的实践经验总结,它屏蔽底层消息引擎具体实现,通过唯一标识动态路由消息,同时为开发运维人员提供自动化部署运维集群,主题、消费组申请与审批、实时监控、自动告警、容灾迁移等功能。
某天晚上打球打得正嗨,突然间收到运维电话,说某个 Kafka 集群 RT 值非常高,使用该集群的用户也发现了消息堆积现象,此刻我意识到问题的严重性,于是急忙跑回办公室查看这个问题。
某天临时被当成壮丁拉去参加一个非常牛逼的应用监控平台(后续会开源),然后大佬就给我派了一个任务,要将项目中的查询性能优化 50 倍以上,大佬对我如此地寄予厚望,我怎么能让大佬失望呢(虽然我内心瑟瑟发抖)?于是我就开始了这段性能优化之旅。
消息引擎最重要的工作就是将生产者生产的消息传输到消费者,消息的格式应该要怎么设计是各大消息引擎框架最核心的问题,消息格式决定了消息引擎的性能与效率,Kafka 在过去的多个版本迭代中,衍生了 3 个版本的消息格式,每个版本的消息格式之间究竟有哪些差异,它们之间的升级解决了什么样的问题呢?下面我就对 Kafka 的消息格式进行深度剖析。
消息中间件的性能好坏,它的消息存储的机制是衡量该性能的最重要指标之一,而 Kafka 具有高性能、高吞吐、低延时的特点,动不动可以上到几十上百万 TPS,离不开它优秀的消息存储设计。下面我按照自己的理解为大家讲解 Kafka 消息存储设计的那些事。
但问题又来了,每次插入一张图片,我们总是要先将图片上传到图床,获取链接之后再将链接插入到 md 文件中,这个过程过于繁琐,且每次插入都在做重复的工作,今天我就跟大家分享一下,我是如何使用 PicGo 图床工具高效地解决上面的问题。
现在我们回到标题重点没有考虑Interceptor线程安全,导致断点调试时才会出现的bug晚上下班后,突然想到调试中遇到的org.apache.ibatis.executor.ExecutorException: Executor was closed.是啥情况?
程序员总会有一些技术文章的输出总结,很多人会选择各大第三方博客平台,但某些第三方博客平台的 UI 简直惨不忍睹,广告巨多,且对 md 格式支持得不够好等等,基于这些原因,我们有足够的理由搭建一套属于我们自己的博客。
以前我们讨论的消费组,都是 group 的形式,group 可以自动地帮助消费者分配分区,且在发生异常时,还能自定地进行重平衡(Rebalance)。正常来说,group 帮助用户实现自动监听分区消费,但是在用户需要指定分区进行精确消费的场景下,由于 group 的重平衡机制,会打破这种消费方式,这不前段时间某项目就有个需求是这样的: 消息源端有若干个,每个消息源都会产生不同的消息,目标端也有若干个,每个目标端需要消费指定的消息源类型。
最近,遇到某个集群的生产端发送延迟特别高,而且吞吐量上不去,检查集群负载却很低,且集群机器配置非常好,网络带宽也很大,于是使用 Kafka 压测脚本进行了压测。
上次跟大家分享的文章「Kafka Producer 异步发送消息居然也会阻塞?」中提到了缓冲池,后面再经过一番阅读源码后,发现了这个缓冲池设计的很棒,被它的设计思想优雅到了,所以忍不住跟大家继续分享一波。
Kafka 一直以来都以高吞吐量的特性而家喻户晓,就在上周,在一个性能监控项目中,需要使用到 Kafka 传输海量消息,在这过程中遇到了一个 Kafka Producer 异步发送消息会被阻塞的问题,导致生产端发送耗时很大。 是的,你没听错,Kafka Producer 异步发送消息也会发生阻塞现象,那究竟是怎么回事呢?
某天小明处理的一些数据需要传给我这边处理,于是小明在我们的传输媒介上面新增了一个 Map 用于保存这些数据,数据结构如下:
前段时间我在 K8s 相关文章中有提到过数据同步的项目,该项目就是基于 DataX 内核构建的,由于公司数据同步的需求,还需要在 DataX 原有的基础上支持增量同步功能,同时支持分布式调度,在「使用 K8s 进行作业调度实战分享」这篇文章中已经详细描述其中的实现。
0.11 版本的 kafka 的 unclean.leader.election.enable 参数默认为 false,表示分区不可在 ISR 以外的副本选举 leader,导致了 A 主题发送消息持续报 34 分区 leader 不存在的错误,且该分区还未消费的消息不能继续消费了。接下来运维在 kafka-manager 查不到 broker0 节点了处于假死状态,但是进程依然还在,重启了好久没见反应,然后通过 kill -9 命令杀死节点进程后,接着重启失败了,导致了如下问题
最近在公司的数据同步项目(以下简称 ZDTP)中,需要使用到分布式调度数据同步执行单元,目前使用的方案是将数据同步执行单元打包成镜像,使用 K8s 进行调度。
Kafka 常用运维脚本
我第一次接触容器编排调度工具是 Docker 自家的 Docker Swarm,主要解决当时公司内部业务项目部署繁琐的问题,我记得当时项目实现容器化之后,花在项目部署运维的时间大大减少了,当时觉得这玩意还挺新鲜的,原来自动化运维可以这么玩。后面由于工作原因,很久没碰过容器方面的知识了。最近在公司的数据同步项目中,需要使用到分布式调度数据同步执行单元,目前使用的方案是将数据同步执行单元打包成镜像,使用 K8s 进行调度,正好趁这个机会了解一下 K8s,下面我就用图解的形式将我所理解的 K8s 分享给大家。
最近项目中有个需求,需要用到有界队列对访问请求量进行流量削峰请求,同时作为一个缓冲层对请求处理进行后续处理,Java 内置有界队列 ArrayBlockingQueue 可以满足这方面的需求,但是性能上并不满足,于是使用了 Disruptor,它是英国外汇交易公司 LMAX 开发的一个高性能队列,了解到它内部解决伪共享问题,今天就和大家一起学习缓存行与伪共享相关的知识。
RPC 模块是我最初研究 Seata 源码开始的地方,因此我对 Seata 的 RPC 模块有过一些深刻研究,在我研究了一番后,发现 RPC 模块中的代码需要进行优化,使得代码更加优雅,交互逻辑更加清晰易懂,本着 “让天下没有难懂的 RPC 通信代码” 的初衷,我开始了 RPC 模块的重构之路。
Kafka 的消费类 KafkaConsumer 是非线程安全的,意味着无法在多个线程中共享 KafkaConsumer 对象,因此创建 Kafka 消费对象时,需要用户自行实现消费线程模型
对 Kafka 来说,它提供了手动位移提交的机制,可以暴露出来让用户自行实现位移的提交,也就意味着你可以对分区的位移有控制权,这完全取决于你本身的实现逻辑。
全链路压测项目的宗旨就是不让用户感知这个项目的存在,因此我们不可能让用户去对其线程池进行改造的,我们需要主动去适配用户自定义的线程池。 在适配过程的过程中无非就是将线程池替换成 ttl 去解决,可通过代理或者替换 Bean 的方式实现,这方面不是本文的内容,本文主要是深入 Spring 异步实现的原理,让大家对 Spring 异步编程不再陌生!
Kafka 消息大小的设置还是挺复杂的一件事,而且还分版本,需要注意的参数巨多,而且每个都长得差不多,不但分版本,还需要注意生产端、broker、消费端的设置,而且还要区分 broker 级别还是 topic 级别的设置,而且还需要清楚知道每个配置的含义。 本文通过相关参数的解析说明,再结合实战测试,帮助你快速搞明白这些参数的含义以及规则。
Docker Swarm 集群的内部会为容器的各个节点之间负责负载均衡的管理,现在我们来验证一下 Docker Swarm 的负载均衡特性。
单机容器内的通信是通过 docker 自带的网桥连接互通的,如果是集群,那么做这些单机网络模型就行不通了,因为集群必然会将一个服务的多个任务需要分布到不同的机器上进行部署,因为如果把所有的任务都分配到一台机器部署了,这台服务器有故障,就会导致这个服务不能正常运行了,而且一个集群内,不同主机之间的容器是怎么进行通信的呢,这里我们就涉及到 docker 网络模型。
Docker Swarm 集群部署笔记
kafka 的消费类 KafkaConsumer 是非线程安全的,因此用户无法在多线程中共享一个 KafkaConsumer 实例,且 KafkaConsumer 本身并没有实现多线程消费逻辑,如需多线程消费,还需要用户自行实现,在这里我会讲到 Kafka 两种多线程消费模型。
上一篇文章「保证严格的消息顺序消费究竟有多难?」简单描述了对消息顺序消费的一些理解,上一篇文章中的第二个故障问题,感觉没描述清楚,现在我以 Kafka 为例子,继续分析一波。 从上一篇文章中分析可知,想要保证消息顺序消费,只需要保证生产端消息发送处在同一分区即可,但现实情况往往会遇到很多意外情况,下面我就盘点一下 Kafka 集群中有哪些意外情况会打乱消息的顺序。
我们都知道无论是 Kafka 还是 RocketMQ,每个主题下面都有若干分区(RocketMQ 叫队列),如果消息被分配到不同的分区中,那么 Kafka 是不能保证消息的消费顺序的,因为每个分区都分配到一个消费者,此时无法保证消费者的消费先后,因此如果需要进行消息具有消费顺序性,可以在生产端指定这一类消息的 key,这类消息都用相同的 key 进行消息发送,kafka 就会根据 key 哈希取模选取其中一个分区进行存储,由于一个分区只能由一个消费者进行监听消费,因此这时候消息就具有消息消费的顺序性了。
最近都在看小马哥的 Spring 视频教程,通过这个视频去系统梳理一下 Spring 的相关知识点,就在一个晚上,躺床上看着视频快睡着的时候,突然想到当我们在使用 SpringMVC 时,Spring 容器是如何与 Servlet 容器进行交互的?虽然在我的博客上还有几年前写的一些 SpringMVC 相关源码分析,其中关于 Spring 容器如何与 Servlet 容器进行交互并没有交代清楚,于是趁着这个机会,再撸一次 SpringMVC 源码。
经过上次 Kafka 日志集群某节点重启失败导致某个主题分区不可用的事故之后,这篇文章专门对分区不可用进行故障重现,并给出我的一些骚操作来尽量减少数据的丢失。
由于 A 主题 34 分区的 leader 副本在 broker0,另外一个副本由于速度跟不上 leader,已被踢出 ISR,0.11 版本的 kafka 的 unclean.leader.election.enable 参数默认为 false,表示分区不可在 ISR 以外的副本选举 leader,导致了 A 主题发送消息持续报 34 分区 leader 不存在的错误,且该分区还未消费的消息不能继续消费了。
上次的 Kafka 重启失败事件,对为什么重启失败的原因似乎并没有解释清楚,那么我就在这里按照我对 Kafka 的认识,从源码和日志文件结构去尝试寻找原因。
最近你们有没有发现,GitHub 明显变慢了,如果没有 fanqiang,拉取代码的速度简直惨不忍睹,如果拉取的量少还可以勉强拉下来,但是遇到数据量大的时候,2 KiB/s 的速度你能忍?拉到中途超时就让你痛不欲生。 最近我就遇到这个问题,seata 社区的 seata.github.io 仓库有阵子突然增加了好多数据,我发现我已经拉不下来了,这时可以利用 Gitee 作为中间代理,下面详细说说具体操作过程。
收到某业务组的小伙伴发来的反馈,具体问题如下: 项目中某 kafka 消息组消费特别慢,有时候在 kafka-manager 控制台看到有些消费者已被踢出消费组。
Seata 的动态降级需要结合配置中心的动态配置订阅功能。动态配置订阅,即通过配置中心监听订阅,根据需要读取已更新的缓存值,ZK、Apollo、Nacos 等第三方配置中心都有现成的监听器可实现动态刷新配置;动态降级,即通过动态更新指定配置参数值,使得 Seata 能够在运行过程中动态控制全局事务失效(目前只有 AT 模式有这个功能)。 那么 Seata 支持的多个配置中心是如何适配不同的动态配置订阅以及如何实现降级的呢?下面从源码的层面详细给大家讲解一番。
Seata 可以支持多个第三方配置中心,那么 Seata 是如何同时兼容那么多个配置中心的呢?下面我给大家详细介绍下 Seata 配置中心的实现原理
在分析启动部分源码时,我发现 GlobalTransactionScanner 会同时启动 RM 和 TM client,但根据 Seata 的设计来看,TM 负责全局事务的操作,如果一个服务中不需要开启全局事务,此时是不需要启动 TM client的,也就是说项目中如果没有全局事务注解,此时是不是就不需要初始化 TM client 了,因为不是每个微服务,都需要 GlobalTransactional,它此时仅仅作为一个 RM client 而已。
从上一篇文章「分布式事务中间件Seata的设计原理」讲了下 Seata AT 模式的一些设计原理,从中也知道了 AT 模式的三个角色(RM、TM、TC),接下来我会更新 Seata 源码分析系列文章。今天就来分析 Seata AT 模式在启动的时候都做了哪些操作。