首页  思维导图  详情

《技术体系》读书笔记

2020-08-05 14:29:51   0  举报





AI智能生成

高级程序员《技术体系》

大数据，Java，程序员，技术体系，知识结构

大数据

后端开发

作者其他创作

大纲/内容

大数据

Hadoop

框架

Hadoopt体系

HDFS

基本概念

命令行操作

集群结构

namenode原理

namenode高可用

数据读写过程

读过程

写过程

文件格式

存储效率

常见问题和解决方案

MapReduce

原理

编程模型

Java API

执行机制

案例

参数调优

YARN

基本架构

资源调度器

调度算法

资源调度过程

任务提交

资源分配

Hadoop3.0新特性

纠删码存储

intra-datanode balancer

YARN timelien service

新容器资源类型

任务本地化

shell脚本更新

Hadoop核心源码

HDFS

DistributedFileSystem和DFSClient实现

HDFS打开文件流程

HDFS创建文件流程

HDFS写文件流程

Hadoop的容错机制

Fslmage与Edits

NameNode启动过程

RPC机制

MapReduce

数据流和工作流

Mapper的输入

Mapper的输出缓冲区MapOutputBuffer

Collector的MapOutBuffer

环形缓冲区

MapOutputBuffer输出

Map终结和Spill文件合并

Reduce阶段的输入和输出

YARN

Job.submit开始

YARNRunner和ResourceMGrDlegate

NM节点心跳和容器周转

Container的分配

NodeManeger与任务投递

MRAppMaster与作业投递

离线批处理：Hive

Hive总体架构

DDL/DML

Hive视图

Hive函数

分区，分桶，抽样

数据加载方式

Access Log

Hive优化

Hive on spark

数据采集：flume

作用与角色

架构

核心组件

源码分析

常用方式

用户行为分析

知识背景

用户行为数据采集

pv，uv功能实现

页面停留时间，流失率

留存率，转化漏斗

分析计算结果回流

Spark

语言

Scala

变量声明

方法和函数

循环

集合

类，继承，单例

函数式编程

概要

源码

Spark SQL

Spark Sreaming

flink

应用场景

实时数仓

实时监控

实时报表

流数据分析

组件

JobManager

接受application，包含StreamGraph、JobGraph和JAR

ResourceManager

一般是Yarn，当TM有空闲的slot就会告诉JM，没有足够的slot也会启动新的TM。kill掉长时间空闲的TM

TaskManager

会跑多个线程的task、数据缓存与交换

Dispatcher

提供REST接口来接收client的application提交，它负责启动JM和提交application，同时运行Web UI

模式

Session模式

预先启动好AM和TM，每提交一个job就启动一个Job Manager并向Flink的RM申请资源，不够的话，Flink的RM向YARN的RM申请资源。适合规模小，运行时间短的作业

1、Submit App

2、Launch AM

3、Submit Job

4、Start JM

5、Request Slot

6、Request Resource

7、Start TM

8、Request Slot

9、Offer Slot

10、Submit Task

Job模式

每一个job都重新启动一个Flink集群，完成后结束Flink，且只有一个Job Manager。资源按需申请，适合大作业。

Framework模式

Flink作业为JAR，并被提交到Dispatcher or JM or YARN

Library模式

Flink作业为application-specific container image，如Docker image，适合微服务

编程模型

数据流程

Source Operator

Transformation Operator

Sink Operator

并行处理

数据交换策略

转发

广播

基于键

随机

时间语义

事件时间

事件创建时间

接入时间

source进入flink的时间

处理时间

运算的时间

窗口模型

time window

滚动窗口

窗口大小

滑动窗口

窗口大小

滑动步长

会话窗口

全局窗口

count window

滚动count

滑动count

window join

滚动join

滑动join

间隔join

水位线

定义

1、算子根据时间水位线来触发相应的计算和处理

2、超过水位线的窗口，不会执行

场景

处理l乱序

处理延时

类型

定期水位线

标点水位线

state状态

定义

就是一个内存中数据/存储结构，task独享变量

应用场景

下一个流需要使用，上一个流处理的结果时（上一个流已经消亡了），可以把结果存放在state中

状态类型

ValueState

update()

value()

ListState

add()

addAll()

get()

ReduceingState

update()

get()

AggregatingState

add()

get()

MapState

put()

putAll()

get()

容错

checkpoint

定义

在某一时刻，将flink job做一个快照，存储到state backend中（如hdfs）

应用场景

静态计算作业图

有状态作业图

非常大的状态，长窗口

需要HA的场景

容错机制

固定间隔延迟重启

故障率重启

不重启

后备重启

flink streaming sql

流程

1、输入流

2、动态表

3、执行查询sql

1、将sql解析成逻辑树

2、结合catalog验证sql语法

3、将逻辑树转换成Logical Plan

4、生成optimized Logical Plan

5、生成Flink Physical Plan

6、生成Flink Execution Plan

4、sql查询结果表

5、输出流

函数

聚合

group By

group By window

distinct

having

合并

union

unionAll

intersect/exception

in

连表

inner join

outer join

window join

异步IO

AsyncFunction

callback

DataStream异步

UDX

UDF

UDTF

UDAF

数据仓库

维度建模

选择业务过程

声明粒度

确认维度

结构

维度ID

描述

类型

退化维度

非规范化扁平维度

多层次维度

日历日期维度

扮演角色的维度

杂项维度

雪花维度

支架维度

一致性维度

缩减维度

缓慢变化维

拉链表

适用场景

确认事实

结构

维度ID

常规描述

度量值

类型

一致性事实

事务事实

周期快照事实

快照表

适用场景

累积快照事实

无事实

聚集事实

合并事实

模型评审与验证

数据加工

分层

ods

dwd

dws

dm

数据质量

如何快速展示数据情况

1、衡量质量的指标可视化界面

2、校验数据质量的业务规则的可视化界面

元数据管理

任务调度

AirFlow

搜索/推荐

算法

热销排行

基于人口属性

基于内容

协同过滤

关联规则

逻辑回归

架构

数据收集

数据加工

支持多种算法

支持多种业务规则

支持不同的算法测试策略

高可用

可配置

计算结果落库

推荐查询

机器学习

用户画像

定义

用户的各种属性

应用场景

业务精细化运营-圈人

数据分析挖掘

精准营销

个性化推荐

选人平台

模块

标签定义模块

标签开发模块

标签存储模块

标签作业ETL调度模块

选人UI模块

活动效果跟踪和评估

主题集市

用户属性

用户爱好

购买历史

用户行为

群体偏好

风险特征

数据流

1、数仓集市

2、ES标签库

3、选人平台

4、人库

5、营销工具

系统交互

1、DB-读写DAG状态

2、ES-标签ETL

3、选人平台-人群明细查询

4、选人平台-定时任务

5、选人平台-定时写入结果库

6、选人平台-通知营销工具

7、营销工具-推送消息

标签库设计

标签维度

用户标签维度

用户自身特征

性别

年龄

地域

教育水平

生日

职业

用户兴趣特征

终端偏好

喜欢浏览的产品类别

喜欢购买的产品类别

喜欢购买产品的投资周期

风险偏好

首次购买产品类型

最近购买产品类型

用户社交特征

婚姻状态

是否有子女

微信账号

微博账号

是否好友推荐

邮箱账号

用户财富特征

收入水平

AUM

已购商品类别

总购买次数

购买频率

是否有车

是否有房

累计充值金额

累计充值次数

投资经验

产品标签维度

开放式基金

P2P理财

理财计划

保险理财

现金管理

渠道标签维度

搜索渠道

网站导航渠道

在线广告渠道

标签类型

统计类

规则类

挖掘类

Java

基础

设计原则

开闭原则

依赖倒置原则

单一职责原则

接口隔离原则

迪米特法则

里氏替换原则

合成复用原则

设计模式

创建型模式

简单工厂模式

工厂方法模式

抽象工厂

建造者模式

单例模式

原型模式

结构型模式

享元模式

组合模式

桥接模式

适配器模式

门面模式

装饰器模式

代理模式

行为型模式

策略模式

模板方法模式

迭代器模式

委派模式

观察者模式

责任链模式

命令模式

备忘录模式

状态模式

访问者模式

中介者模式

解释器模式

集合

List

ArrayList

LinkedList

Map

HashMap

ConcurrentHashMap

Set

HashSet

TreeSet

JVM

运行时数据区

程序计数器

虚拟机栈

本地方法栈

堆

新生代

老年代

方法区

垃圾回收器

Serial

ParNew

Parallel Scavenge

Serial Old

Parallel Old

CMS

GC日志

GC发生的时间

垃圾收集的停顿类型

GC发生的区域

GC前该内存区域已使用容量 -> GC后该内存区域已使用容量

GC所占用的时间

用户消耗的CPU时间

内存态消耗的CPU时间

操作从开始到结束所经过的时间

dump文件

大对象分析

多线程

Thread

currentThread()

join()

yield()

isAlive()

sleep()

getId()

同步

Synchronized

volatile

AbstractQueuedSynchronizer

工具类

CountDownLatch/CyclicBarrier

Threadlocal

Semophore

Exchanger

线程池

阻塞队列

LinkedBlockingQueue

ArrayBlockingQueue

ThreadPoolExecutor

corePoolSize

maximumPoolSize

keepAliveTime

unit

workQueue

threadFactory

数据结构

枚举

位集合

向量

栈

字典

哈希表

属性

算法

算法复杂度

贪心算法

分治算法

动态规划算法

回溯法

分支定界法

字符串匹配算法

排序算法

常用框架

Spring

核心包

spring-core

构建应用的核心，主要提供了依赖注入的特性

spring-context

顶层接口ApplicationContext，主要存放各种配置的信息（properties文件，yml文件等）

spring-beans

顶层接口BeanFactory，主要存放bean的元数据beanDefinitions和造bean

spring-web

WebApplicationContext接口，主要存放web容器，servlet相关配置信息

spring-webmvc

DispatcherServlet，主要是分发请求，组装返回，model，view，controller

初始化过程

入口：ContextLoaderListener

1、prepareRefresh()

2、obtainFreshBeanFactory()

3、prepareBeanFactory(beanFactory)

4、postProcessBeanFactory(beanFactory)

5、invokeBeanFactoryPostProcessors(beanFactory)

6、registerBeanPostProcessors(beanFactory)

7、initMessageSource()

8、initApplicationEventMulticaster()

9、onRefresh()

10、registerListeners()

11、finishBeanFactoryInitialization(beanFactory)

12、finishRefresh()

Spring MVC

初始化过程

入口：DispatcherServlet

1、initMultipartResolver(context)

2、initLocaleResolver(context)

3、initThemeResolver(context)

4、initHandlerMappings(context)

5、initHandlerAdapters(context)

6、initHandlerExceptionResolvers(context)

7、initRequestToViewNameTranslator(context)

8、initViewResolvers(context)

9、initFlashMapManager(context)

运行过程

入口：DispatcherServlet

1、getHandler(processedRequest)

2、getHandlerAdapter(mappedHandler.getHandler())

3、ha.handle(processedRequest, response, mappedHandler.getHandler())

4、processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException)

MyBatis

初始化过程

1、调用 SqlSessionFactoryBuilder 对象的 build(inputStream) 方法

2、SqlSessionFactoryBuilder 会根据输入流 inputStream 等信息创建XMLConfigBuilder 对象

3、SqlSessionFactoryBuilder 调用 XMLConfigBuilder 对象的 parse() 方法

4、XMLConfigBuilder 对象返回 Configuration 对象

5、SqlSessionFactoryBuilder 根据 Configuration 对象创建一个DefaultSessionFactory 对象

6、SqlSessionFactoryBuilder 返回 DefaultSessionFactory 对象给 Client

运行过程

查询

resultMap

一对一级联查询，association

一对多级联查询，collection

一级缓存，SqlSession

参数和SQL完全一样，SQL执行一次

传入的statementId

查询时要求的结果集中的结果范围

Sql语句字符串

参数值

二级缓存，Mapper

所有select语句将会被缓存

所有insert、update和delete语句会刷新缓存

标签

foreach

choose

when

otherwise

if

trim

where

set

bind

用于模糊查询<bind name="paran_uname" value="'%' + uname + '%'"/>

常用组件

Redis

数据结构

String

Hash

链表

Set

zset

持久化

RDB

概念

快照全量备份

触发方式

save

bgsave

自动触发

AOF

概念

将写命令都通过write函数追加到文件中

触发方式

always

同步持久化每次发生数据变更会被立即记录到磁盘性能较差但数据完整性比较好

everysec

异步操作，每秒记录如果一秒内宕机，有数据丢失

no

从不同步

高可用

主从

原理

初始化

同步一份RDB给从节点

写过程

master发送写命令给slave

断点续传

master和slave内部都会维护一个backlog文件，backlog里面保存一个offset数据，比较offset来续传

优点

缺点

哨兵

原理

sdown和odown转换机制

哨兵集群的自动发现机制

slave配置的自动纠正

slave->master选举算法

跟master断开连接的时长

slave优先级-高

复制offset-多

run id-小

quorum和majority

configuration epoch

configuraiton传播

优点

缺点

Cluster

原理

redis集群固定持有16384个hash slot（虚拟节点），K/V存储时，对K的取CRC16%16384，找到对应的hash slot

从节点选举

N/2 + 1

优点

缺点

常规问题

缓存

缓存穿透

缓存击穿

缓存雪崩

缓存数据与数据库数据一致性

session共享

将产生的session放入redis，下次请求根据session ID获取session

mongoDB

基本概念

database

collection

document

field

index

createIndex

getIndexes

totalIndexSize

dropIndexes

dropIndex

primary key

读过程

1、client

2、route server

3、config server

4、shard server

5、route server

6、client

写过程

1、client

2、route server

3、config server

4、shard server

高可用

主从方式

双机双工方式

集群工作方式

mysql

基本概念

引擎

InnoDB

聚集

MyISAM

非聚集

索引

B-Tree

B+Tree

最左前缀原理

失效

流程

1、客户端

2、查询缓存

3、语法解析

4、查询优化

5、执行查询

6、缓存结果

7、返回客户端

分库分表

垂直

优点

缺点

水平

优点

缺点

问题

事务一致性

跨节点关联查询 join

跨节点分页、排序、函数

全局主键避重

数据迁移、扩容

高可用

Master High Availability

MySQL Group Replication

组复制

Percona XtraDB Cluster

nginx

模块

核心模块

处理器模块

过滤器模块

代理类模块

web 服务

负载均衡

随机算法

轮询及加权轮询

最小连接及加权最小连接

哈希算法

IP地址散列

URL散列

web cache

限制IP，限制连接数

tomcat

启动过程

1、入口类，org.apache.catalina.startup.Bootstrap#main，初始化类加载器，反射实例化Catalina

2、执行Catalina的start方法，加载server.xml配置、初始化Server，开启服务、初始化并开启一系列组件、子容器

3、解析server.xml，创建Context后解析web.xml（读取顺序：context-param->listener->filter->servlet）

4、listener中的核心是ServletContextListener（spring初始化入口），ServletRequestListener（请求入口）

5、servlet的核心是DispatcherServlet（springMVC前端控制器）

运行过程

1、客户端发送请求http://localhost:8080/wsota/wsota_index.jsp

2、请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得

3、 Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应

4、Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host

5、Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）

6、localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context

7、Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）

8、path="/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table中寻找对应的servlet

9、 Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类

10、构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法

11、Context把执行完了之后的HttpServletResponse对象返回给Host

12、Host把HttpServletResponse对象返回给Engine

13、Engine把HttpServletResponse对象返回给Connector

14、Connector把HttpServletResponse对象返回给客户browser

ActiveMQ

写过程

读过程

高可用

RabbitMQ

写过程

读过程

高可用

RocketMQ

写过程

读过程

高可用

微服务

理论

大型分布式架构演进过程

分布式架构需要常规考虑因素

CDN加速静态文件

分布式存储

分布式搜索引擎

应用发布与监控

容灾及机房规划

系统动态扩容

分布式架构设计原则

SOA架构和微服务架构

领域驱动和业务驱动

CAP，BASE

C(一致性)

A(可用性)

P(分区容错性)

高可用设计

可伸缩设计

高性能设计

框架

Spring Boot

@SpringBootApplication

@Configuration

@ComponentScan

默认扫描注解所在类的package

@EnableAutoConfiguration

开启自动配置

启动过程

1、创建SpringApplication对象实例

扫描spring.factories中的ApplicationContextInitializer和ApplicationListener

2、执行run方法，遍历执行SpringApplicationRunListener的started()方法

SpringApplicationRunListener用于监听启动过程中的各个节点

3、创建并配置Environment

4、遍历调用所有SpringApplicationRunListener的environmentPrepared()的方法

5、如果SpringApplication的showBanner属性被设置为true，则打印banner

6、创建ApplicationContext，将Environment设置给创建好的ApplicationContext

7、遍历调用ApplicationContextInitializer的initialize（applicationContext）方法

8、遍历调用所有SpringApplicationRunListener的contextPrepared()方法

9、将@EnableAutoConfiguration获取的所有配置以及其他形式的IoC容器配置加载到ApplicationContext

扫描spring.factories中的EnableAutoConfiguration，装配组件

10、遍历调用所有SpringApplicationRunListener的contextLoaded()方法

11、调用ApplicationContext的refresh()方法，完成IOC容器和依赖注入

12、遍历执行CommandLineRunner

13、遍历执行SpringApplicationRunListener的finished()方法

Spring Cloud

Eureka

Eureka Client

负责将这个服务的信息注册到Eureka Server中

默认30秒心跳

Eureka Server

注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号

刷新列表频率

监测心跳频率，默认90秒

A(可用性)和P(分区容错性)

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

当网络稳定时，当前实例新的注册信息会被同步到其它节点中

Feign

动态代理

实现接口，并根据@FeignClient等注解构造请求

Ribbon

默认轮询算法

客户端负载均衡

维护Sever列表的数量(新增、更新、删除等)

维护Server列表的状态(状态更新)

当请求Server实例时，能否返回最合适的Server实例

使用方法

引入ribbon的jar

在RestTemplat加入LoanBalance注释即可

Hystrix

隔离

线程池

熔断

直接返回，不走网络请求超时，没有补偿措施

降级

直接返回的同时，有补偿措施，比如消息队列，调用记录等

使用方法

消费端启动类上加@EnableDiscoveryClient，@EnableHystrix，@EnableHystrixDashboard

Zuul

能力

验证与安全保障

审查与监控

动态路由

压力测试

负载分配

静态响应处理

多区域弹性

过滤器

PRE

这种过滤器在请求被路由之前调用

ROUTING

这种过滤器将请求路由到微服务

POST

这种过滤器在路由到微服务以后执行

ERROR

在其他阶段发生错误时执行该过滤器

特殊过滤器

StaticResponseFilter

允许从Zuul本身生成响应，而不是将请求转发到源

SurgicalDebugFilter

允许将特定请求路由到分隔的调试集群或主机

自定义过滤器

热部署

FilterScriptManagerServlet

Filter源码文件放在zuul 服务特定的目录， zuul server会定期扫描目录下的文件的变化，动态的读取\编译\运行这些filter

zipkin

链路追踪

耗性能，有问题调试的时候再打开

config

配置中心

利用消息队列建立一个spring cloud bus，由git存储配置文件，利用bus总线动态更新配置文件信息

分布式事务

二阶段提交协议

最终一致性

消息队列

幂等性

本身有幂等性

保证顺序

不具备幂等性

记录执行结果，执行过就不执行

事务补偿机制

TCC模式

Try

完成所有业务检查预留必须业务资源

Confirm

真正执行业务

操作具有幂等性

Cancel

释放Try阶段预留的业务资源

操作具有幂等性

周期性对账

Dubbo

介绍

适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况

原理

初始化

服务提供

服务消费

组件

ElasticSearch

介绍

基本概念

索引

类型

文档

字段

集群

节点

主节点

数据节点

协调节点

分片

主分片

副本分片

写过程

1、大概

ES的任意节点都可以作为协调节点(coordinating node)接受请求，当协调节点接受到请求后进行一系列处理，然后通过_routing字段找到对应的primary shard，并将请求转发给primary shard, primary shard完成写入后，将写入并发发送给各replica， raplica执行写入操作后返回给primary shard， primary shard再将请求返回给协调节点

2、coordinating节点

1、ingest pipeline：查看该请求是否符合某个ingest pipeline的pattern, 如果符合则执行pipeline中的逻辑，一般是对文档进行各种预处理，如格式调整，增加字段等。如果当前节点没有ingest角色，则需要将请求转发给有ingest角色的节点执行

2、自动创建索引：判断索引是否存在，如果开启了自动创建则自动创建，否则报错

3、设置routing：获取请求URL或mapping中的_routing，如果没有则使用_id, 如果没有指定_id则ES会自动生成一个全局唯一ID。该_routing字段用于决定文档分配在索引的哪个shard上

4、构建BulkShardRequest：由于Bulk Request中包含多种(Index/Update/Delete)请求，这些请求分别需要到不同的shard上执行，因此协调节点，会将请求按照shard分开，同一个shard上的请求聚合到一起，构建BulkShardRequest

5、将请求发送给primary shard：因为当前执行的是写操作，因此只能在primary上完成，所以需要把请求路由到primary shard所在节点

6、等待primary shard返回

3、primary shard

1、判断操作类型：遍历bulk请求中的各子请求，根据不同的操作类型跳转到不同的处理逻辑

2、将update操作转换为Index和Delete操作：获取文档的当前内容，与update内容合并生成新文档，然后将update请求转换成index请求，此处文档设置一个version v1

3、Parse Doc：解析文档的各字段，并添加如_uid等ES相关的一些系统字段

4、更新mapping：对于新增字段会根据dynamic mapping或dynamic template生成对应的mapping，如果mapping中有dynamic mapping相关设置则按设置处理，如忽略或抛出异常

5、获取sequence Id和Version：从SequcenceNumberService获取一个sequenceID和Version。SequcenID用于初始化LocalCheckPoint， verion是根据当前Versoin+1用于防止并发写导致数据不一致

6、写入lucene：这一步开始会对文档uid加锁，然后判断uid对应的version v2和之前update转换时的versoin v1是否一致，不一致则返回第二步重新执行。如果version一致，如果同id的doc已经存在，则调用lucene的updateDocument接口，如果是新文档则调用lucene的addDoucument. 这里有个问题，如何保证Delete-Then-Add的原子性，ES是通过在Delete之前会加上已refresh锁，禁止被refresh，只有等待Add完成后释放了Refresh Lock, 这样就保证了这个操作的原子性

7、写入translog：写入Lucene的Segment后，会以key value的形式写Translog， Key是Id, Value是Doc的内容。当查询的时候，如果请求的是GetDocById则可以直接根据_id从translog中获取。满足nosql场景的实时性

8、重构bulk request：因为primary shard已经将update操作转换为index操作或delete操作，因此要对之前的bulkrequest进行调整，只包含index或delete操作，不需要再进行update的处理操作

9、flush translog：默认情况下，translog要在此处落盘完成，如果对可靠性要求不高，可以设置translog异步，那么translog的fsync将会异步执行，但是落盘前的数据有丢失风险

10、发送请求给replicas：将构造好的bulkrequest并发发送给各replicas，等待replica返回，这里需要等待所有的replicas返回，响应请求给协调节点。如果某个shard执行失败，则primary会给master发请求remove该shard。这里会同时把sequenceID， primaryTerm, GlobalCheckPoint等传递给replica

11、等待replica响应：当所有的replica返回请求时，更细primary shard的LocalCheckPoint

4、replica shard

1、判断操作类型：replica收到的写如请求只会有add和delete，因update在primary shard上已经转换为add或delete了。根据不同的操作类型执行对应的操作

2、Parse Doc

3、更新mapping

4、获取sequenceId和Version：直接使用primary shard发送过来的请求中的内容即可

5、写入lucene

6、write Translog

7、Flush translog

读过程

1、客户端发送请求到任意一个node，成为coordinate node

2、coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡

3、query phase：每个shard将自己的搜索结果（其实就是一些doc id），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果

4、fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，最终返回给客户端

Zookeeper

结构

文件系统

通知机制

作用

命名服务

配置管理

集群管理

是否有机器退出和加入、选举master

分布式锁

队列管理

原理

选主流程

paxos算法

basic paxos

1、选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server

2、选举线程首先向所有Server发起一次询问(包括自己)

3、选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中

4、收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server

5、线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来

fast paxos

某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader

同步流程

1、leader等待server连接

2、Follower连接leader，将最大的zxid发送给leader

3、Leader根据follower的zxid确定同步点

4、完成同步后通知follower 已经成为uptodate状态

5、Follower收到uptodate消息后，又可以重新接受client的请求进行服务了

工作流程

Leader

1、恢复数据

2、维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型

3、Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理

Follower

1、向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）

2、接收Leader消息并进行处理

3、接收Client的请求，如果为写请求，发送给Leader进行投票

4、返回Client结果

Netty

Kafka

适用场景

要求高吞吐，对数据有序性要求不严格的场景

作用

解耦

异步

削峰

通信模式

点对点模式

发布订阅模式

组件

Broker

Broker是kafka实例，每个服务器上有一个或多个kafka的实例

Topic

消息的主题，可以理解为消息的分类，kafka的数据就保存在topic

Partition

Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量

segment

.index文件

索引文件

.log文件

存储message的地方

offset

在新的版本中消费者消费到的offset已经直接维护在kafk集群的__consumer_offsets这个topic中

消息大小

消息体

.timeindex文件

索引文件

Replication

每一个分区都有多个副本

Message

每一条发送的消息主体

Consumer Group

我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据

建议消费者组的consumer的数量与partition的数量一致

Zookeeper

kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性

发送数据

1、从集群获取分区leader

2、将消息发送给leader

1、partition在写入的时候可以指定需要写入的partition，如果有指定，则写入对应的partition

2、如果没有指定partition，但是设置了数据的key，则会根据key的值hash出一个partition

3、如果既没指定partition，又没有设置key，则会轮询选出一个partition

3、leader将消息写入本地文件

4、followers从leader pull消息

5、followers将消息写入本地后向leader发送ACK

6、leader收到所有副本的ACK后向producer发送ACK

0

0代表producer往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高

1

1代表producer往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功

all

all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低

消费数据

1、先找到offset的368801message所在的segment文件（利用二分法查找），这里找到的就是在第二个segment文件

2、打开找到的segment中的.index文件（也就是368796.index文件，该文件起始偏移量为368796+1，我们要查找的offset为368801的message在该index内的偏移量为368796+5=368801，所以这里要查找的相对offset为5）。由于该文件采用的是稀疏索引的方式存储着相对offset及对应message物理偏移量的关系，所以直接找相对offset为5的索引找不到，这里同样利用二分法查找相对offset小于或者等于指定的相对offset的索引条目中最大的那个相对offset，所以找到的是相对offset为4的这个索引

3、根据找到的相对offset为4的索引确定message存储的物理偏移位置为256。打开数据文件，从位置为256的那个地方开始顺序扫描直到找到offset为368801的那条Message

Mycat