首页
学习
活动
专区
圈层
工具
发布
个人中心"kafka-3-2" 的搜索结果
来自专栏

我对支付平台架构设计的一些思考

我在前一家公司的第一个任务是开发统一支付平台,由于公司的业务需求,需要接入多个第三方支付,之前公司的支付都是散落在各个项目中,及其不利于支付的管理,于是聚合三方支付,统一支付平台的任务就落在我手上,可以说是完全从 0 开始设计,经过一翻实战总结,我得出了一些架构设计上的思考,之前就一直很想把自己的架构设计思路写出来,但一直没动手,前几天在技术群里有人问到相关问题,我觉得有必要把它写出来,以帮助到更多需要开发支付平台的开发人员。

1.3K21
来自专栏

RocketMQ源码分析之路由中心

早期的rocketmq版本的路由功能是使用zookeeper实现的,后来rocketmq为了追求性能,自己实现了一个性能更高效且实现简单的路由中心NameServer,而且可以通过部署多个路由节点实现高可用,但它们之间并不能互相通信,这也就会导致在某一个时刻各个路由节点间的数据并不完全相同,但数据某个时刻不一致并不会导致消息发送不了,这也是rocketmq追求简单高效的一个做法。

71370
来自专栏

代码即格式:你用过这些高效工具吗?

我在工作中也用到一些使用起来非常高效的工具,今天以 “代码即格式” 为主题,跟大家介绍下两个高效工具。

80360
来自专栏

Kafka 常用运维脚本

集群管理 (1)启动 broker $ bin/kafka-server-start.sh daemon <path>/server.properties (2)关闭 broker $ bin/kafka-server-stop.sh topic 管理 kafka-topics.sh 脚本 # 创建主题 $ bin/kafka-topics.sh --create --zookeeper localhost:2181 --partitions 64 --replication-factor 3 --topi

1.8K20
来自专栏

Spring Boot 2动态修改日志级别

作为程序猿,定位问题是我们的日常工作,而日志是我们定位问题非常重要的依据。传统方式定位问题时,往往是如下步骤:

1.8K20
来自专栏

RocketMQ主从如何同步消息消费进度?

如果消费者消费模式不同,也会有不同的保存方式,消费者端的消息消费进度保存到 OffsetStore 中,他有两个实现类:

1.5K40
来自专栏

Kafka消息体大小设置的一些细节

还记得前几天有个小伙伴跟我反馈发送消息时提示请求数据过大的异常吗?经过调整 max.request.size 的大小之后,又报了了如下异常:

6.4K30
来自专栏

Golang 中函数作为值与类型

在 Go 语言中,我们可以把函数作为一种变量,用 type 去定义它,那么这个函数类型就可以作为值传递,甚至可以实现方法,这一特性是在太灵活了,有时候我们甚至可以利用这一特性进行类型转换。作为值传递的条件是类型具有相同的参数以及相同的返回值。

2.2K30
来自专栏

深度解析RocketMQ Topic的创建机制

我还记得第一次使用rocketmq的时候,需要去控制台预先创建topic,我当时就想为什么要这么设计,于是我决定撸一波源码,带大家从根源上吃透rocketmq topic的创建机制。

4.5K91
来自专栏

Mybatis-spring源码分析之注册Mapper Bean

「Mybatis源码分析之Mapper注册与绑定」讲到了 Mapper 如何注册到 Configuration 类中与 MapperProxyFactory 绑定的过程,我们平时的使用场景一般都配合着 Spring,使用 Spring 意味着需要注册 Bean,也就是说需要将 Mapper 的代理实现类注册到 Spring 容器中,成为 Spring 容器中的一个 Bean。

2.3K51
来自专栏

图解 DataX 核心设计原理

DataX 是阿里巴巴开源的一个异构数据源离线同步工具,致力于实现包括关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。

5.4K20
来自专栏

深度剖析 Seata TCC 模式【图解 + 源码分析】

Seata 目前支持 AT 模式、XA 模式、TCC 模式和 SAGA 模式,之前文章更多谈及的是非侵入式的 AT 模式,今天带大家认识一下同样是二阶段提交的 TCC 模式。

3.6K20
来自专栏

中通消息平台集群突破百万主题的技术探索

随着业务上的增长与迭代,业务使用的消息集群会创建越来越多主题,在业务流量不断增长的情况下,还需要不断增加主题的分区数量,Kafka 由于本身的存储机制特点,随着主题和分区数的增加,性能会不断下降,无法满足业务上的发展。通常我们的做法是扩容集群,但随着集群的不断扩大,又会伴随着很多问题,随着集群的扩容节点,创建主题和分区数不断增多,存储在 zk 上的元数据就会越来越多,每当需要全量同步元数据到 Broker 节点时,会是一笔很大的网络开销,由于当 contrller 切换时往往需要全量同步元数据到每个 Broker 上,因此,元数据越多,controller 的切换时长会越长,而且由于 Kafka 会独立一个复制线程进行分区副本的复制,多个分区共享该线程,因此 Broker上的分区不断增多后会造成复制线程负载增大,严重时会会造成某些分区副本复制跟不上,导致 ISR 频繁变化。

61510
来自专栏

深度剖析分布式事务,轻松掌握实现原理与应用技巧!

大家好,今天我们来一起探讨分布式事务的相关知识。相信大家都有多多少少接触过分布式事务,因为我们现在写的代码可是服务于亿级用户量级的,那么大的请求量级不可能全部写在一台服务器上面对吧。如果你还没有研究过分布式事务,也没关系,我们今天再一起来探讨一番。我曾经接触过分布式事务相关的中间件框架,比如现在很火的阿里开源的一款分布式事务中间件Seata。目前我在Seata社区主要做一些RPC以及性能优化的相关工作,所以我可能会对分布式事务具体实现比较了解。以Seata为契机,我们一起来探讨分布式事务。

1.1K20
来自专栏

分布式事务中间件Seata的设计原理

在微服务架构体系下,我们可以按照业务模块分层设计,单独部署,减轻了服务部署压力,也解耦了业务的耦合,避免了应用逐渐变成一个庞然怪物,从而可以轻松扩展,在某些服务出现故障时也不会影响其它服务的正常运行。总之,微服务在业务的高速发展中带给我们越来越多的优势,但是微服务并不是十全十美,因此不能盲目过度滥用,它有很多不足,而且会给系统带来一定的复杂度,其中伴随而来的分布式事务问题,是微服务架构体系下必然需要处理的一个痛点,也是业界一直关注的一个领域,因此也出现了诸如 CAP 和 BASE 等理论。

1.6K50
来自专栏

从源码的角度解析Mybatis的会话机制

坐在我旁边的钟同学听说我精通Mybatis源码(我就想不通,是谁透漏了风声),就顺带问了我一个问题:在同一个方法中,Mybatis多次请求数据库,是否要创建多个SqlSession会话?

2.1K21
来自专栏

Kafka发送消息时提示请求数据过大是怎么回事?

然后我去服务器查看了下 producer 的配置,发现没有配置 max.request.size,默认值为 1048576,而他发送的消息大小为 1575543,因此报了这个异常。

4.1K20
来自专栏

Golang 环境配置与应用编译

Go 语言现在是越来越火了,出现在各个领域中,称它为 21 世纪的 C 语言一点都不为过,而且 Go 语言是 2009 年才发布的新语言,可以说它的特性是完全基于现代计算机来设计的,尤其是它的看家本领 goroutine 协程,在高并发场景下使用简直不要太爽,非常适合写一些高性能中间件。

1K20
来自专栏

Raft: 寻找一种易于理解的一致性算法

Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能,但是它的算法结构和 Paxos 不同,使得 Raft 算法更加容易理解并且更容易构建实际的系统。为了提升可理解性,Raft 将一致性算法分解成了几个关键模块,例如领导人选举、日志复制和安全性。同时它通过实施一个更强的一致性来减少需要考虑的状态的数量。一项用户研究的结果表明,对于学生而言,Raft 算法比 Paxos 算法更加容易学习。Raft 算法还包括一个新的机制来允许集群成员的动态改变,它利用重叠的大多数来保证安全性。

1.1K10
来自专栏

Kafka ISR 副本同步机制

ISR(in-sync replica) 就是 Kafka 为某个分区维护的一组同步集合,即每个分区都有自己的一个 ISR 集合,处于 ISR 集合中的副本,意味着 follower 副本与 leader 副本保持同步状态,只有处于 ISR 集合中的副本才有资格被选举为 leader。一条 Kafka 消息,只有被 ISR 中的副本都接收到,才被视为“已同步”状态。这跟 zk 的同步机制不一样,zk 只需要超过半数节点写入,就可被视为已写入成功。

4.1K10
领券