《技术体系》读书笔记
2020-08-05 14:29:51 0 举报AI智能生成
高级程序员《技术体系》
作者其他创作
大纲/内容
大数据
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
G1
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
MQ
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
0 条评论
下一页
