Yonhoo

Kafka-replica-server

本文简单介绍当Broker接受到producerRequest的时候，ReplicaManager是如何处理的本地写入和WaitForFollowerFetch

ClassLoader

类加载机制

在编译成的Class文件最终都要加载到虚拟机中才能被运行和使用，Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

Kafka-Concept

关于Kafka的文章，主要是为了学习在分布式系统下，非常重要的部分如数据复制，数据分区的真正实践，同时对于消息队列的使用并不是很多，从而通过学习Kafka相关内容来进行深入，当然没有大型项目关于Kafka的深入实践，很难结合业务场景来调优最佳实践和更加深刻的认知，但还是希望通过这种方式来进行入门，了解万变不离其宗的分布式系统下的复杂性。

Kafka-Producer

如今在维护各个微服务下，考虑到最多的就是分布式系统的可用性–CAP，那么就像数据密集型服务描述的那样，需要考虑分布式系统下数据复制、数据分区、分布式事务，本节通过看kafka的多分区复制方式，来学习数据复制中需要考虑到的通用处理。

Kafka-Fetch

每个Broker上都有一个ReplicaManager，它管理每个Partition的数据同步逻辑，因为每个Partition都会存在副本，从而在Broker中的TopicPartition可能是Leader或者Follower。

当它是Leader时，就需要处理来自Producer的请求，写入log数据，同时等ISR集合同步完成，如果是Follower，就需要同步来自Leader的log数据，保持数据同步。

在ReplicaManager中，就会开启同步Follower线程来FetchMessage。在ReplicaManager中会调用makeFollowers来处理同步Leader数据的逻辑。

Netty write 流程

1. ChannelPipline 传播事件

每一个Channel都会分配一个新的ChannelPipline，所有的出入站事件都会流经ChannelPipline来进行处理。

其中处理每一个事件的主要是ChannelHandler，例如ChannelOutboundHandler、ChannelInboundHandler分别用来处理出入站事件。通过调用ChannelHandlerContext实现，它将被转发给同一超类型的下一个ChannelHandler进行处理。

分布式事务

在如今的项目实践中，存在多个微服务之间互相通信，对于一个外卖服务，涉及到订单支付，优惠券扣减，餐厅下单，外卖配送等，在微服务设计下，就需要保证多个系统之间的数据一致性，这个时候就需要考虑到分布式事务来处理一致性问题。

Zookeeper 简介与使用场景

Zookeeper的视图结构和标准的Unix文件系统非常类似

，

但没有引入传统文件系统中目录和文件等相关概念

，

而是使用了其特有的

“

数据节点

”

概念

，

我们称之为ZNode

。

ZNode是Zookeeper中数据的最小单元

，

每个ZNode上都可以保存数据

，

同时还可以挂载子节点

，

因此构成了一个层次化的命名空间

，

我们称之为树

。

任务调度

任务场景
在支付宝中，如果你在蚂蚁森林里面种植了一颗树苗，它会根据用户每天使用支付宝的各种场景：地铁出行，线下支付等来生成相应的能量，每天早上，支付宝会通知每个用户收取能量，以便他们能够种植更多的树苗。

垃圾回收与检查工具

java内存区域

运行时数据区域

程序计数器

当前线程私有，是当前线程所执行的字节码的行号指示器

java虚拟机栈

当前线程私有，每个方法被执行时的栈帧，用于储存局部变量表、操作数栈，动态连接，方法出口等信息动态连接作用就是为了将这些方法符号引用转换为调用方法的直接引用，因为有的对象调用方法时动态生成的，所以在编译器不能确定要执行的符号，从而需要在运行时，去方法区动态的找。