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