java技术栈
2021-11-25 16:37:31 62 举报
AI智能生成
Java 技术栈
作者其他创作
大纲/内容
计算机基础
计算机网络
OSI七层模型
应用层
表示层
会话层
传输层
网络层
数据链路层
物理层
TCP/IP四层模型
应用层
传输层
网际互联层
网络接口层
HTTP请求
get
post
response
HTTP的请求过程
域名解析
3次握手
建立TCP连接,发起http请求
响应
解析html
加载资源js、css、图片
Keep-Alive
chunked 分块传输
HTTP Pipelining(HTTP 管线化)
协议结构
TCP
面向连接的、可靠、重传
3次握手
4次挥手
SYN攻击
UDP
无连接的
多播和广播
IP协议
IO模型
epoll
kqueue
select
数据结构
什么是数据结构
研究方向
逻辑结构
线性结构
树形结构
图形结构
存储结构
运算结构
基本类型
集合结构
线性结构
树形结构
图形结构
线性表
顺序表(数组)
单链表
双链表
循环链表
栈
队列
队列、栈、链表、树、堆、图
树
二叉树
哈希
哈希的定义
适用场景
构造函数
基础算法
图算法
排序算法
操作系统
进程
线程
linux
常用命令
cd,ls,grep,find,cp,mv,rm,ps,kill,file,tar,cat,tail
源码安装
shell脚本
日志查找
日志处理
docker
第一个demo
通用软件技术
负载均衡
反向代理
squid
Varnish
Nginx
工作原理
异步非阻塞
配置
负载均衡
健康检查
ngx_http_proxy_module、
ngx_http_upstream_module
ngx_http_upstream_module
nginx_upstream_check_module
https
301
40X,50X错误页面
高效配置
缓存
Purge清理缓存
etag
保持连接
Apache
同步多进程
rewrite
haproxy
DNS负载均衡
IP负载均衡
LVS
Maglev
Vortex
CDN技术
监控
第三方-听云
flash dog 日志监控
Zabbix监控平台
数据库/文件系统
数据库设计
关系数据库
MySQL
SQL
函数
视图
触发器
存储过程
性能优化
高性能查询
其他
null值
服务器
主从、集群
定时任务
权限
数据库索引
B+Tree索引
B+Tree索引
索引类型
索引的原则
尽量选择区分度高的列作为索引
最左前缀匹配原则
尽量选择区分度高的列作为索引
索引的缺点
mycat
mycat
SQL Server
函数
视图
触发器
存储过程
性能优化
高性能查询
oracle
cassandra
postgre
nosql
redis
redis基本原理
redis配置优化
主从
集群
踩过的坑
mongodb
documentdb
时序数据库
了解
influxDB
其他数据
FastDFS分布式文件系统
Minio
开发&测试
接口协议
webservice
常用接口
Java WebService接口生成和调用
http
接口开发
微信公众号开发
小程序
短信供应商接口
支付接口
微信支付
支付宝
邮件
OCR
名片识别
通用图文识别
语义识别
语音识别
微软
科大讯飞
百度地图
SEO优化
sitemap
TDK
爬取原则
爬行、抓取、索引、收录
新技术
区块链
设计案例
流水号,批量生产
通用草稿功能
动静分离
页面静态化
样式、图片、js
动态内容缓存技术 CSI,SSI,ESI
前后分离
单点登录
cas
工作原理
生产部署
客户端源码修改
连接池
JDBC
作用&工作原理
常用连接池
DBCP
C3P0
Druid
JPA?
JNDI
多数据源
动态数据源
前端展示
jsp
freemarker
html
HTML5
JavaScript
jQuery
跨域访问
JSONP
Proxy
CORS
css
测试
自动化测试
单元测试
功能测试
压力测试
测试工具
loadrunner
http_load
ab工具
安全测试
网站安全检测工具
网站安全规范
数据
数据分析
ETL
BI
报表
日志采集
实时数据平台
搜索
爬虫
其他语言
python
数据清洗
日志清洗
PHP
工作原理
功能开发
服务器部署
golang
perl
linux shell
容器技术
why
java
java基础
JVM
内存模型
方法区、虚拟机栈、堆、本地方法栈、程序计数器
类加载机制
性能调优
案例一MetaspaceSize
JDK8新特性
接口的默认方法
lambda表达式
。。。
基本类型
String
子主题
数据结构
数组、链表、队列、栈
树、图
集合
map
坑
forEach删除元素
HashMap可能异常
ConcurrentHashMap 不会抛出异常
自定义对象作为Key
需要重写hashCode与equals方法
保证对象是不变的
不同实现类,KV为null约束不一样
HashTable KV不允许为null
HashMap KV允许为null
ConcurrentHashMap KV不允许为null
TreeMap K不允许为null,V允许为null
Map 返回集合(keySet,values,entrySet)
支持remove,clear方法的坑
不支持add操作
ConcurrentHashMap 错误使用导致线程不安全
只保证容器(集合)对外操作API的线程安全
多个操作还需加锁
list
坑
foreach删除元素
Arrays#asList
不支持add、remove、
支持set。。。
与原数组关联
List#subList
与原始List关联
同时引用原始List对象
Collections#unmodifiableList不可以变集合可以变的坑
socket编程
多线程
协程
线程同步
高并发
设计模式
单例模式
工厂模式
代理模式
观察者模式
委派模式
策略模式
原型模式
模板模式
java 开发框架
servlet
struts
spring
IOC
设计原理
高级特性
AOP
AOP的实现机制
动态代理
接口代理
子类(cglib)
静态织入
场景
事务
日志
链路跟踪
BeanFactory
事物处理机制
SpEL
使用
注入
调用方法
操作符
三目操作符
操作List、Map集合取值
spring mvc
九大组件
springSession原理
session和cookie原理
springSession工作原理
ORM
hibernate
mybatis
spring boot
持续集成/项目管理
jenkins
安装部署
对接gerrit
对接Nexus
自动构建
定时构建
代码更新出发
评审
自动测试
自动发布
gerrit
安装部署
权限
评审模式
结合eclipse
svn
使用
Nexus
安装部署
配置第三方
常见问题
第三方仓库失效
刷新索引、缓存
手动上传的jar,位置不规范
Maven
作用
构建、测试、打包和部署
版本控制
依赖管理
常用命令
常用plugin
模块化
常见问题
本地jar缓存
私服jar缓存
RAP
部署
使用
特性开关
灰度发布
微服务
互联网架构演进
1、单体架构
优点
比较简单
IDE友好
易于部署
缺点
代码庞大复杂
可靠性差
技术栈限制
伸缩性差
交付效率差
适合场景
创业公司
高性能应用
改进
纵向划分业务模块
横向划分
微服务
2、水平分层
优点
低耦合
高内聚
开发效率高
扩展性高
缺点
请求路径长
平均响应延迟高
定位问题难
运维成本高
3、SOA
SOA架构思想
4、微服务架构
一些拆分
网关层
业务服务层
数据层
注册中心
配置中心
服务发现
优点
服务独立部署
服务独立维护
其他优点见单机版缺点
缺点
服务治理能力要求高
-5、容器化
-6、DevOps
什么是微服务
定义
特点
按业务划分良好的扩展能力
通过http相互通信
每个微服务都有自己独立的数据库
自动化部署
服务集中管理
天然分布式架构
代码容易理解、开发效率高
良好的扩展能力
技术选择灵活
版本更新便捷
良好的健壮性
管理分散
服务拆分
服务拆分的关键点
拆分方法
挑战
架构复杂度高
服务多
管理困难
分布式事务
服务划分的标准没有定论
服务部署难
新的问题
服务之间如何定义
服务的发布和订阅
服务监控
服务治理
故障定位
微服务的基本组件
服务描述
解决什么问题
RESTful API
XML(RPC)
IDL文件(跨语言服务调用框架)
注册中心
解决什么问题
工作流程
注册中心的功能
注册接口、反注册接口
心跳汇报接口
服务订阅接口、最新服务查询接口
服务查询接口、修改接口
要求
集群部署保证高可用
多 IDC 部署
数据一致性
开源方案
AP型、应用内:Eureka
Eureka Server
Eureka Clien
CP型、应用外:Consul
Consul:注册中心的服务端
Registrator:一个开源的第三方服务管理器项目,它通过监听服务部署的 Docker 实例是否存活,来负责服务提供者的注册和销毁。
Consul Template:定时从注册中心服务端获取最新的服务提供者节点列表并刷新 LB 配置
CP型:zookeeper
是什么
特性
master/slave(半数正常)
子主题
使用场景
安装&集群
配置项
一些命令
web界面node-zk-brower
监控界面taokeeper
如何使用
负载均衡
节点管理
与dubbo结合使用
工作原理
leader
ZAB 协议
znode
长连接
Watcher 机制
AP、CP型:Nacos
中文官网
英文官网
源起
配置中心
注册中心
使用多个配置文件ext-config[0]、ext-config[1]
选择
API网关
请求合法性和安全校验
安全
IP、token过滤
访问频率控制
黑白名单等
请求路由功能
请求回包
策略、请求预处理、错误处理
访问限制、安全、流量控制、分析监控、日志、请求转发、合成和协议转换功能
Kong
Azure API Management 服务
自建
配置中心
要求
配置K-V形式
配置更新实时同步
配置项热加载
配置项最终一致性
高可用、高可靠
客户端缓存配置项
友好的管理界面
多环境配置项
淘宝diamond
项目整合使用
基本工作原理
高可用技术方案
源码解读
携程Apollo
服务框架
解决什么问题
通讯协议
HTTP 通信是基于应用层 HTTP 协议的
Socket 通信是基于 TCP/IP 协议的封装
处理请求
同步阻塞方式(BIO)
同步非阻塞方式 (NIO)
异步非阻塞方式(AIO)
数据传输协议
HTTP 协议
私有协议Dubbo 协议
消息头和消息体
数据压缩(序列化)
文本类如 XML/JSON
二进制类如 PB/Thrift
产品
Dubbo 框架
Motan
Tars:腾讯内部使用的 RPC 框架,于 2017 年对外开源,仅支持 C++ 语言。
spring cloud
跨语言:gRPC
原理
跨语言:Thrift
原理
对比选型
发展
支持多语言是 RPC 框架未来的发展趋势。正是基于此判断,各个 RPC 框架都提供了 Sidecar 组件来支持多语言平台之间的 RPC 调用。
服务监控
监控对象
接口监控
资源监控
基础监控
指标收集
请求量
响应时间
错误率
监控系统原理
数据采集
方式:服务主动上报
方式:代理收集
采样率
数据传输
方式:UDP 传输
方式:Kafka 传输
格式:二进制协议
格式:文本协议
数据处理
数据处理是对收集来的原始数据进行聚合并存储
接口维度聚合
机器维度聚合
索引数据库(ES)
时序数据库(OpenTSDB)
数据展示
服务追踪
解决什么问题
作用
优化系统瓶颈
优化链路调用
生成网络拓扑
透明传输数据
原理
Google Dapper
实现
数据采集层
数据处理层
数据展示层
产品
Twitter 的Zipkin
阿里的鹰眼
美团的MTrace
SkyWalking
服务治理
故障类型
单机故障
单IDC故障
依赖服务不可用
服务提供者自身出现问题
网络问题,如服务提供者、注册中心、服务消费者这三者任意两者之间的网络出现问题。
治理手段
节点管理
注册中心主动摘除机制
服务消费者摘除机制
负载均衡
服务路由
解决的问题
业务存在灰度发布的需求
多机房就近访问的需求
服务容错
失败自动切换
失败通知
失败缓存
快速失败
高可用手段
负载均衡
无状态化
异步化
服务降级
服务治理
服务实时监控
高并发手段
页面静态化
数据Sharding
缓存
批量读取
延迟修改
异步设计
降低响应延迟
动态扩容?
关键技术
无状态设计
异步设计
服务降级
幂等设计
单点登录
session
产生背景
什么是cookie
什么是session
session与cookie的区别
session在何时被创建
sessionid
session怎么实现
session共享
问题及场景
Web 服务器集群等场景
多个子系统实现单点登录
域名和端口都不一样的多个子系统单点登录
方案
粘性session
容器session复制
Servlet容器
利用Cookie记录Session
Session重写
spring-session
工作原理
重写HttpServletRequest、HttpServletResponse、HttpSession
cas
场景:域名和端口都不一样的多个子系统单点登录
子主题
分布式ID
什么是分布式ID
问题
条件
UUID
优点:生成足够简单,本地生成无网络消耗,具有唯一性
缺点:无序的字符串,不具备趋势自增特性
缺点:没有具体的业务含义
缺点:长度过长16 字节128位,36位长度的字符串,存储以及查询对MySQL的性能消耗较大,MySQL官方明确建议主键要尽量越短越好,作为数据库主键 UUID 的无序性会导致数据位置频繁变动,严重影响性能。
数据库自增ID
优点:实现简单,ID单调自增,数值类型查询速度快
缺点:DB单点存在宕机风险,无法扛住高并发场景
数据库集群模式自增ID
优点:解决DB单点问题
缺点:不利于后续扩容,而且实际上单个数据库自身压力还是大,依旧无法满足高并发场景。
基于数据库的号段模式
优点:生成方式不强依赖于数据库,不会频繁的访问数据库,对数据库的压力小很多
缺点:实现稍微复杂
基于Redis模式
优点:简单、速度快、可支持高并发
缺点:redis持久化的问题
雪花算法(Snowflake)模式
百度(uid-generator)
美团(Leaf)
滴滴(Tinyid)
分布式事务
CAP与Base
方案
2阶段提交
补偿事务(Try-Confirm-Cancel)
消息表(消息重发)
MQ支持事务
Sagas 事务模型
人工处理
熔断
分布式锁
是什么
场景
实现条件
唯一性
释放(自动或过期)
重入
阻塞锁和非阻塞锁
数据库锁
缓存锁
分布式缓存锁—Redlock
基于Zookeeper的分布式锁
RPC
RPC框架
解决的问题
技术要求
序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机
dubbo
项目整合使用
基本工作原理
子主题
如何实现服务降级
gRPC
Thrift
其他
不停机更新
分级管理
设置合理的超时
网络不稳定
大数据
什么是大数据
大数据技术“三驾马车”
Google 的思路是部署一个大规模的服务器集群,通过分布式的方式将海量数据存储在这个集群上,然后利用集群上的所有机器进行数据计算。
分布式文件系统 GFS
大数据分布式计算框架 MapReduce
NoSQL 数据库系统 BigTable。
大数据应用的发展脉络:1搜索引擎时代2:数据仓库时代(数据统计分析)3:数据挖掘时代(关联分析,推荐系统)4:机器学习时代(预测未来)
数据分析
发展史
2006 年Doug Cutting 启动了一个独立的项目专门开发维护大数据技术—— Hadoop,主要包括 Hadoop 分布式文件系统 HDFS 和大数据计算引擎 MapReduce。
2008 年,Hadoop 正式成为 Apache 的顶级项目
Yahoo 的一些人觉得用 MapReduce 进行大数据编程太麻烦了,于是便开发了 Pig。
编写 Pig 脚本虽然比直接 MapReduce 编程容易,但是依然需要学习新的脚本语法。于是 Facebook 又发布了 Hive
随后,众多 Hadoop 周边产品开始出现,大数据生态体系逐渐形成,其中包括:专门将关系数据库中的数据导入导出到 Hadoop 平台的 Sqoop;针对大规模日志进行分布式收集、聚合和传输的 Flume;MapReduce 工作流调度引擎 Oozie 等。
2012 年,Yarn 成为一个独立的项目开始运营,随后被各类大数据产品支持,成为大数据平台上最主流的资源调度系统。
2012 年,Spark推出,MapReduce 进行机器学习计算的时候性能非常差,因为机器学习算法通常需要进行很多次的迭代计算,而 MapReduce 每执行一次 Map 和 Reduce 计算都需要重新启动一次作业,带来大量的无谓消耗
...
能做什么
大数据处理的主要应用场景包括数据分析、数据挖掘与机器学习。
未来的软件开发不再是需求-分析-设计-实现的确定性过程,而是定义问题和目标,收集数据,提供数据,再由神经网络不断探索最优解的非确定性过程。
例子
统计人的驾驶行为进行机器学习,就是无人驾驶
统计股票的历史交易数据进行机器学习,就得到量化交易系统。
推荐:啤酒与尿布这个经典案例
统计大家p图的参数进行智能美颜
游戏的AI电脑
微软识花
头条的智能推荐阅读
淘宝小红书的推荐购物
广告系统
估价系统
大数据在医疗健康领域的应用
医疗健康领域会产生大量的数据;其次,医疗健康领域有一个万亿级的市场规模;最关键的是,医疗健康领域里很多工作依赖人的经验,而这正是机器学习的强项。
医学影像智能识别
病历大数据智能诊疗
大数据在教育领域的应用
AI 外语老师
智能解题
大数据在社交媒体领域的应用
舆情监控与分析
大数据在金融领域的应用
大数据在金融领域的应用
大数据在新零售领域的应用
大数据在交通领域的应用
解决什么问题
大规模数据的存储问题
数据存储容量的问题
数据读写速度的问题
数据可靠性的问题
对比:RAID(独立磁盘冗余阵列)技术
RAID 0
RAID 1
RAID 10
RAID 3
RAID 5
RAID 6
传输大规模的数据的问题
单机计算能力有限的问题
核心原理及架构
技术应用架构图
大数据计算实现过程的简单描述
1、数据存储在HDFS
2、启动若干分布式任务执行进程
3、使用大数据计算框架支持的编程模型进行编程
4、用 Hadoop 或者 Spark 的启动命令执行这个应用程序的 JAR 包,首先执行引擎会解析程序要处理的数据输入路径,根据输入数据量的大小,将数据分成若干片(Split),每一个数据片都分配给一个任务执行进程去处理。
5、任务执行进程收到分配的任务后,检查自己是否有任务对应的程序包,如果没有就去下载程序包,下载以后通过反射的方式加载程序。走到这里,最重要的一步,也就是移动计算就完成了。
6、加载程序后,任务执行进程根据分配的数据片的文件地址和数据在文件内的偏移量读取数据,并把数据输入给应用程序相应的方法去执行,从而实现在分布式服务器集群中移动计算程序,对大规模数据进行并行处理的计算目标
Hadoop 分布式文件系统 HDFS
目标
原理
DataNode
NameNode
高可用
移动计算
大数据引擎根据集群里不同服务器的计算能力,在每台服务器上启动若干分布式任务执行进程,这些进程会等待给它们分配执行任务。
MapReduce计算
Hadoop 的 MapReduce 编程模型
MapReduce 计算框架
解决的问题
大数据应用进程
JobTracker 进程
TaskTracker 进程
MapReduce 作业启动和运行机制
MapReduce 数据合并与连接机制
shuffle 过程
shuffle 也是整个 MapReduce 过程中最难、最消耗性能的地方
Spark 的 RDD 编程模型
Yarn叫作资源调度框架
Yarn 发展的过程
问题由来
解决办法
Yarn 的架构图
资源管理器(Resource Manager)
调度器
应用程序管理器
节点管理器(Node Manager)
工作流程
首先执行引擎会解析程序要处理的数据输入路径,根据输入数据量的大小,将数据分成若干片(Split),每一个数据片都分配给一个任务执行进程去处理。
HBase
解决什么问题
概念:NoSQL
HBase 的架构设计
中间件
中间技术
中间件(Middleware)是提供系统软件和应用软件之间连接的软件,以便于软件各部件之间的沟通
是指网络环境下处于操作系统、数据库等系统软件和应用软件之间的一种起连接作用的分布式软件,主要解决异构网络环境下分布式应用软件的互连与互操作问题,提供标准接口、协议,屏蔽实现细节,提高应用系统易移植性
常用
过程调用
分布式组件
消息队列
事务
安全
连结器
商业流程(工作流)
HTTP服务器
Web Service
特征
平台化
应用支撑
软件复用
耦合关系
互操作性
消息队列
适用场景
应用解耦
峰值处理
异步处理
冗余、系统扩展
可恢复性
日志处理
监控
流计算
IoT
ETL数据清洗
协议
JMS
Peer-to-Peer 模式
一个消息只能被一个接受者消费
消费者不必在线
...
Publish/Subscribe模式
支持多个消费者
消费者只有在线才能接收到消息
...
消息监听器
消息转换器
事务管理
AMQP
MQTT
背景IoT
网络不稳定
使用场景
海量IoT设备
每个客户端对应一个主题
解决方案
使用传统消息队列扩展
专门的MQTT Server产品
云平台厂商提供的 MQTT 云服务
商业版 MQTT Server
自建MQTT集群
负载均衡
Proxy 集群
Broker集群
OpenMessaging
使用的技术
网络通信
序列化与反序列化
一致性
分布式事务
异步编程
数据压缩
内存管理
文件与高性能IO
高可用分布式系统架构
产品
kafka
01入门
官方文档
什么是消息引擎
kafka基本术语
服务端:Broker
主题Topic
分区
副本Replica
Leader副本
Follower副本
Producer
Consumer Group
产生Rebalance问题
消息位移:Offset
消费者位移:Consumer Offset
消息日志(Log)
关系图
kafka的定位
kafka版本选择
发行的版本
Apache Kafka
优势在于迭代速度快,社区响应度高
与外部系统的连接器单一
监控没有
Confluent Kafka
包含更多的连接器
跨IDC备份
集群监控
缺陷在于相关文档资料不全,普及率较低,
CDH/HDP Kafka
缺陷在于把控度低,演进速度较慢
版本号
历史版本
0.11.0.0 版本
02使用
集群安装
线上方案制定
Linux系统
磁盘
磁盘容量计算
带宽
关键参数
log.dirs
Failover机制
zookeeper.connect
listeners
advertised.listeners
Topic 管理
auto.create.topics.enable
unclean.leader.election.enable
auto.leader.rebalance.enable
数据留存
log.retention.{hours|minutes|ms}
log.retention.bytes
message.max.bytes
Topic 级别参数
retention.ms:规定了该 Topic 消息被保存的时长
retention.bytes:规定了要为该 Topic 预留多大的磁盘空间
JVM 参数
java8以上
手动设置使用 G1 收集器
推荐,堆大小设置成 6GB
环境变量
KAFKA_HEAP_OPTS
KAFKA_JVM_PERFORMANCE_OPTS:指定 GC 参数
操作系统参数
文件描述符限制ulimit -n
文件系统
swap 的调优
Flush 落盘时间
03客户端
生产者
分区机制(算法)
解决的问题
分区的作用
分区策略
自定义策略,只要实现.Partitioner接口即可
轮询策略
随机策略
Key-ordering 策略
有序消息
错误案例
如何实现消息的顺序问题
基于地理位置的分区策略
压缩算法
为什么要压缩?
压缩消息
CRC校验
Producer 端压缩、Broker 端保持、Consumer 端解压缩。
何时压缩
生产者端
配置 compression.type 参数即表示启用指定类型的压缩算法
启用压缩的一个条件就是 Producer 程序运行机器上的 CPU 资源要很充足
如果你的Producer环境中带宽资源有限,也建议开启压缩。
Broker 端
Broker 端指定了和 Producer 端不同的压缩算法
Broker 端发生了消息格式转换
何时解压缩
压缩算法比较
GZIP
Snappy
LZ4
Zstandard 算法(简写为 zstd)
吞吐量方面:LZ4 > Snappy > zstd 和 GZIP
压缩比方面,zstd > LZ4 > GZIP > Snappy
无消息丢失配置
为什么会丢失消息
已提交的消息
案例1:Producer 程序丢失消息
案例 2:消费者程序丢失数据
案例3:增加主题分区
办法
不要使用 producer.send(msg),而要使用 producer.send(msg, callback)。
设置 acks = all。acks 是 Producer 的一个参数,代表了你对“已提交”消息的定义。如果设置成 all,则表明所有副本 Broker 都要接收到消息,该消息才算是“已提交”。这是最高等级的“已提交”定义。
较大的值。这里的 retries 同样是 Producer 的参数,对应前面提到的 Producer 自动重试。当出现网络的瞬时抖动时,消息发送可能会失败,此时配置了 retries > 0 的 Producer 能够自动重试消息发送,避免消息丢失。
设置 unclean.leader.election.enable = false
设置 replication.factor >= 3。
设置 min.insync.replicas > 1。这依然是 Broker 端参数,控制的是消息至少要被写入到多少个副本才算是“已提交”。
确保 replication.factor > min.insync.replicas。
确保消息消费完成再提交。
幂等生产者与事务
消息投递承诺
最多一次(at most once)
至少一次(at least once)
Kafka 默认提供的交付可靠性保障
精确一次(exactly once)
用户的期望——精确一次
kafka的Broker 端自动去重
幂等性 Producer
它只能保证单分区上的幂等性,即一个幂等性 Producer 能够保证某个主题的一个分区上不出现重复消息,它无法实现多个分区的幂等性。
它只能实现单会话上的幂等性,不能实现跨会话的幂等性。这里的会话,你可以理解为 Producer 进程的一次运行。当你重启了 Producer 进程之后,这种幂等性保证就丧失了
事务型 Producer
保证跨分区、跨会话间的幂等性
Producer发送消息的过程
TCP连接管理分析
TCP 能够被用于多路复用连接场景
何时创建 TCP 连接
METADATA 请求
高级功能
kafka拦截器
消费者
消费者组
Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。
Consumer Group 下可以有一个或多个 Consumer 实例。这里的实例可以是一个单独的进程,也可以是同一进程下的线程。
Group ID 是一个字符串,在一个 Kafka 集群中,它标识唯一的一个 Consumer Group。
Consumer Group 下所有实例订阅的主题的单个分区,只能分配给组内的某个 Consumer 实例消费。
理想情况下,Consumer 实例的数量应该等于该 Group 订阅主题的分区总数。
位移主题_consumer_offsets
前世今生
保存在zk中
zk不适合频繁写更新
将位移保存在 Kafka 内部主题
位移主题的 Key 中应该保存 3 部分内容:<Group ID,主题名,分区号 >
Broker 端参数 offsets.topic.num.partitions 的取值了。它的默认值是 50,因此 Kafka 会自动创建一个 50 分区的位移主题。
删除位移主题中的过期消息
Compaction
Rebalance
触发条件
组成员数发生变更
订阅主题数发生变更
订阅主题的分区数发生变更
分配策略
公平的分配策略
社区于 0.11.0.0 版本推出了 StickyAssignor,即有粘性的分区分配策略。
缺点
在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 完成。
全部重新分配所有分区,更高效的做法是尽量减少分配方案的变动
时间长
Coordinator
如何避免
session.timeout.ms= 6s
heartbeat.interval.ms= 2s
max.poll.interval.ms
GC 设置不合理导致程序频发 Full GC 而引发的非预期 Rebalance
位移提交
混淆点1:提交的是下一条消息的位移
混淆点2:每个分区提交各自的位移数据
自动提交
手动提交
commitSync()
commitAsync()
混合使用
异常处理
CommitFailedException
原因:,原因是消费者组已经开启了 Rebalance 过程,并且将要提交位移的分区分配给了另一个消费者实例。
Standalone Consumer的CommitFailedException问题
多线程开发实例
一次poll太多记录回来
Kafka Java Consumer 为什么采用单线程的设计
非阻塞式的消息获取
够简化 Consumer 端的设计
不是所有的编程语言都能够很好地支持多线程
多线程开发
KafkaConsumer 类不是线程安全的 (thread-safe)。所有的网络 I/O 处理都是发生在用户主线程中
方案1:消费者程序启动多个线程,每个线程维护专属的 KafkaConsumer 实例,负责完整的消息获取、消息处理流程
方案2:消费者程序使用单或多线程获取消息,同时创建多个消费线程执行消息处理逻辑
优缺点
TCP连接管理分析 TODO
消费者消费进度监控
消费者 Lag 或 Consumer Lag
Kafka 自带命令
Kafka Java Consumer API
Kafka JMX 监控指标
Lead 指标——消息丢失的监控
04核心原理
备份机制(副本)
Kafka 依托于 ZooKeeper 提供的监控功能能够实时感知到,并立即开启新一轮的领导者选举
副本同步是异步的
追随者副本是不对外提供服务的
方便实现“Read-your-writes”
单调读——更简单
In-sync Replicas(ISR)
满足条件:Broker 端参数 replica.lag.time.max.ms
Unclean 领导者选举
请求处理过程
Reactor 模式
kafka请求处理架构
Broker 端参数 num.network.threads
网络线程处理流程
参数 num.io.threads
Rebalance流程解析
Rebalance
何时发生
缺点
非必要场景
解决
Rebalance通知的方式
消费者组状态
empty
dead
PreparingRebalance
CompletingRebalance
Stable
消费者端重平衡流程
JoinGroup 请求
领导者消费者
SyncGroup 请求
Broker 端重平衡场景
场景一:新成员入组
场景二:组成员主动离组
场景三:组成员崩溃离组
场景四:重平衡时协调者对组内成员提交位移的处理
Controller控制器
做什么
1.主题管理(创建、删除、增加分区)
2.分区重分配
3.Preferred 领导者选举
4.集群成员管理(新增 Broker、Broker 主动关闭、Broker 宕机)
5.数据服务
哪些数据
如何被选出来的
集群中任意一台 Broker 都能充当控制器的角色
第一个成功创建 /controller 节点的 Broker 会被指定为控制器
控制器故障转移(Failover)
控制器内部设计原理
0.11 版本之前的问题
设计改进——单线程加事件队列的方案
同步操作 ZooKeeper 全部改为异步操作
高水位机制
05运维与监控
主题管理
动态配置
消费者位移管理
KafkaAdminClient
认证机制
MirrorMaker
监控框架
授权管理
Kafka调优
06高级应用
kafka Streams
kafka DSL开发
其他(问题思考)
为什么消息会丢失
丢失消息的场景
解决方法
一些配置
如何实现高吞吐量
分区机制
压缩消息
批次发送消息
使用零拷贝技术
消息重复?
消息顺序?
RocketMQ
也叫Metaq
官方文档
中文社区
RabbitMQ
官方文档
ActviteMQ
队列
订阅/发布
客户端去重
消息确认机制
消息监听的实现
Pulsar
微软云-service bus
产品优缺点
搜索引擎
Solr
使用场景
Lucene
elasticsearch
使用场景
安装及集群部署
版本及对应的客户端版本
脑裂问题
分片设置及扩容问题
倒排索引、版本控制的实现
azure search
分布式任务调度(定时任务)
使用场景
定时任务与mq
传统定时任务方案
java.util.Timer类
ScheduledExecutorService
Spring-Task
@Scheduled
集群模式的问题场景
定时任务执行多次
分布式任务调度要求
子主题
Cron表达式说明
格式: [秒] [分] [小时] [日] [月] [周] [年]
解决方案
Quartz
触发方式
基本概念
xxl-job
你想要了解的都在官网
oracle版实施
elastic-job
其他
Saturn
TBSchedule
缓存
本地缓存
guava
ehcache
其他
带锁的Map
Oscache
leveldb
还可分为堆内缓存和堆外缓存
优点
不需要序列化
速度最快
节省内网带宽
缺点
大小受限于本机内存
GC暂停时间会变长
分布式中无法保证数据统一性
违背了分层架构设计的无状态准则
数据统一性方案
通过MQ通知其他节点
节点定时任务
使用场景
案例一
分布式缓存
redis
特点
单线程
string,list,set,sorted Set和Hash
支持持久化
支持集群
memcached
特点
多线程
仅支持key/value
不支持持久化
支持集群
优点
大小无限
缺点
需要序列化
使用场景
回收算法
回收策略
基于空间
基于容量(数量)
基于时间
FIFO(Fisrt In Fisrt Out)
LRU(Least Recently Used)
LFU(Least Frequently Used)
使用场景
错误场景
把缓存作为服务与服务之间传递数据的媒介
使用缓存未考虑雪崩
调用方缓存数据
多服务共用缓存实例
多级缓存方案
容器
Tomcat
调优BIO、NIO、APR
jetty
独立安装部署,研究activeMQ的部署
NIO实现的高并发轻量级
支持servlet3.1和websocket。
undertow
NIO实现的高并发轻量级
支持servlet3.1和websocket。
resin
WebLogic
WebSphere
Jboss
zookeeper
集群成员管理、分布式锁、领导者选举
znode
持久性 znode
临时 znode
Watch 通知功能
0 条评论
下一页
为你推荐
查看更多