ligen1112的博客

1.前言想不想自己实现一下分布式的主从选举算法？reids,tidb,kafka主从协调都用到了raft一致性算法。mit6.824分布式系统的第二次作业lab2A就是用golang实现一个简易版的主从选举，本篇讲这个作业的实现，挺有趣的。可以做到在规定时间内选出leader，leader挂掉后选出新的leader，挂掉的leader，follower重新加入集群后不影响现在的leader。听着简单，真要自己实现就复杂了。所有规则在raft论文里面都说了，一板一眼的复现就能通过作业，但是只有在自己踩坑一

RegionServer核心模块RegionServer后面简称rs，是比较核心的模块，数据写入读取的基础组件。rs包含HLog,MemStore,HFile和BlockCache。1. RS内部结构HLog用来保证数据写入的可靠性，BlockCache读缓存，一个strore是一个列族，memstore是写缓存，数据达到阈值直接落盘HFile, HFile按照rowkey排序，文件之间异步会进行多路归并（LSM结构）。1.1 HLog所有写操作先追加写入HLog再写入memstore。rs挂了

0.前言mit 6.824分布式系统课程主页lab1是第一次作业，本菜鸡用了好几天独立完成，经过一次改版优化了数据结构和解决任务元数据并发环境下的data race问题，建议大家做之前有自己独立的思考，有很多可行方案都能完成任务。比如看到有的小伙伴采用master(coordinator)轮询slave(worker)进行交互，我是用slave定时发送请求触发master懒执行大部分任务（后面会聊到原因）。也有的小伙伴用队列增删加锁实现并发安全，本人用的golang自带的channel作为任务队列。不

前言一致性算法Raft,久闻大名，今天拜读一下论文。一致性算法支撑了大规模可靠软件系统，Paxos是主导算法，但是它太难理解。raft是简化版的Paxos。raft有几个主要部分：领导选举/日志复制/安全性。raft的特性有强领导者（Strong Leader）：Raft 使用一种比其他算法更强的领导形式。例如，日志条目只从领导者发送向其他服务器。这样就简化了对日志复制的管理，使得 Raft 更易于理解。领导选取（Leader Selection）：Raft 使用随机定时器来选取领导者。这

HDFS读写流程分析结合《Hadoop权威指南》 + Hadoop源码 + 《Hadoop 2.X HDFS源码剖析》，对HDFS读写流程和源代码以及常见面试题做了总结内容提要HDFS读写流程源代码分析和真实生产环境debug案例高频面试题总结1. HDFS读流程《Hadoop权威指南》：HDFS读操作，一般是客户端通过RPC 调用namenode以确定问价按块起始位置，对于每一个块，namenode返回保存该块副本的datanode地址（返回结果具有优先顺序），客户端通过Distri

分布式文件系统的操作涉及 master(namenode),slave(datanode),client之间的各种调用连接，HDFS将这些rpc通信抽象成不同接口Hadoop RPC:ClientProtocal :client和namenodeClientDatanodeProtocal: client和datanodeDatanodeProtocal: datanode和namenodeInterDatanodeProtocal:datanode和datanode1.ClientProt

tcp粘包拆包问题解决pollSelectionKeys.attemptRead中channel.read方法，receive.complete()是对接受的消息进行判断是否完整public NetworkReceive read() throws IOException { NetworkReceive result = null; //初始化对象NetworkReceive if (receive == null) { receive

kafka网络设计发送流程，较为复杂，画了一个全局图后才算明了，下面解读下sendProducerData流程send的发送数据方法sendProducerData中，首先会调用recordAccumulator的ready（红色）方法检查哪个消息分区可以发送数据得到ReadyCheckResult（包含可以发送的tp对应的node），顺便看下有没有没见过的新topicPartition,有后面就去更新元数据，然后调用networkClient的ready方法，这就是要检查node的连接状态了，没联通

Kafka的sender线程核心发送方法就是sendProducerDatasendProducerData读源数据缓存发送前需要获取消息的目的地broker节点和RecordAccumulator中要发送的消息,分为两步step1 先拉取本地缓存的元信息step2 accumulator.ready查看哪个队列可以发送 Cluster cluster = metadata.fetch(); // get the list of partitions with data read

众所周知，jvm的GC会有不小的时间损耗，stop the world会严重影响kafka 生产者的消息发送。如果我们每次消息发送后，对中间生成的实例不做任何处理留给JVM，可能会造成严重的后果。因此Kafka生产者用内存池这种东西来循环利用中间生成的消息缓存bytebuffer。依据我的理解，就是：标准大小消息的bytebuffer，用过一次后接着用装下一条消息。对于非标准大小的消息，用另外手段分配。对于大消息手动使用赋值null对于GC有无帮助？看到下面的说明java对象不再使用时，为什么要赋值为

生产者数据准备好了，还需要知道kafka集群元数据才能发送出去，这里我们看下元数据是怎么过来的生产者的doSend方法中，有一个ClusterAndWaitTime类，包含了Cluster类（真正的元数据）和等待时间private static class ClusterAndWaitTime { final Cluster cluster; final long waitedOnMetadataMs; ClusterAndWaitTime(Cluster

kafka生产者构造器如下，可以传入properties,KV序列化器等等从传入properties这个构造器入手解析下，其实KV序列化器也可以在properties里面指定，就是下面这种创建kafka生产者的常规操作,指定broker的信息等等 public static KafkaProducer<String, String> createKafkaProducer() { Properties properties = new Properties();

Flume概述Flume是一种基于流式架构的日志采集，聚合和传输系统。可以用来把Java EE平台的日志数据（比如实时推荐）传输给HDFS主要目的：实时读取服务器日志，写到HDFS中架构Agent:JVM进程。以事件（event）的形式把数据传送到目的地，主要由三部分组成：source,channel,sink???? source: 负责生产事件（接收数据）。Source组件可以处理各种...