Category Archives: Programme

Kafka中再均衡的发生过程

Kafka中消费者以消费组的形式存在,消费组来消费每个主题中分区的数据,因为主题中的分区数和消费者数量并不一一对应,这时候就涉及到如何为每个消费者分配分区,而当有消费者在中途退出时,就会触发再均衡的发生,再重新为剩余的消费者分配分区。每个消费组在服务端对应一个GroupCoordinator对其进行管理,而消费者客户端中的ConsumerCoordinator组件负责与GroupCoordinator进行交互,它们负责执行分区的分配,以及消费者再均衡的操作。

浅析微服务注册中心的注册与发现

注册中心是用来集中管理微服务,实现服务的注册,发现,检查等功能,目前比较成熟的注册中心组件有很多,如Consul,eureka,zookeeper,etcd,nacos,不同组件之间性能,并发,高可用都会有差距。但对于用户来说基本的功能实现都是透明的。其实如果我们自己开发一套注册中心也可以,能够满足基本的功能即可。

Kafka实现订单超时取消的两种模拟策略

在业务场景中有一个需要定时15分钟后取消用户订单的功能,可以使用Java的任务调度框架来实现,但还需要引入框架依赖和设置数据表等,对业务的侵入性很大,有点大材小用的感觉,所以这里使用延时队列就可以,Kafka本身是不支持延时队列的,需要在生产消息和消费时进行一些二次开发,以下是我对该业务具体实现的思考。

对于mysql,redis,Kafka,zookeeper磁盘缓存技术使用分析

大部分组件是基于磁盘存储的,但由于CPU速度和磁盘速度之间的鸿沟,都会使用缓存技术来提高性能,缓存简单来说就是一块内存区域,首先将从磁盘读到的数据放在缓存中,之后查询或修改时直接操作缓存,对于缓存中的数据则以一定的频率刷新到磁盘上,怎样缓存,缓存多少,何时刷新,这些影响着整个组件的性能。在看过一些关于mysql等组件的架构原理后,会发现不论是基于磁盘的mysql数据库和Kafka消息中间件zookeeper分布式协调框架,还是基于内存的redis数据库,它们都设计了完善的内存和磁盘之间数据交互实现。

分布式锁的锁优化

在去除原有synchronized单机锁后,在关键步骤添加分布式锁来对具体业务进行锁定,然而由于锁定范围大,导致锁竞争增加,不断发生锁等待,如果不进行优化,可能会让线程队列增大甚至阻塞,而且在等待时长超过设定的阈值时,线程将超时返回。

数据库读写分离时,主从延时导致数据不一致的解决方案

引入主从架构,数据读写分离,目的是为了解决业务快速发展,请求量变大,并发量变大,从而引发的数据库的读瓶颈。不过当引入新一个架构解决问题时,势必会带来另外一个问题,数据库读写分离之后,主从延迟从而导致数据不一致的情况。

Java性能调优分享

Java性能调优分享 这次分享还是之前在公司对项目进行性能调优时,前期的调研,以及积… Read More »