学习路线
2020-11-25 13:34:06 0 举报AI智能生成
Java学习路线
作者其他创作
大纲/内容
集合
HashMap
1.7
数组+链表
头插
1.8
数组+链表+红黑树
尾插
扩容机制
LoadFactory 默认0.75
创建一个空数组重新Hash
Hash公式跟长度有关
线程不安全
2的幂次
方便位运算
均匀分布
重写equals必须重写HashCode
ConcurrentHashMap
安全失败
1.7
数组+链表
segment分段锁
继承了reentranLock
尝试获取锁存在并发竞争 自旋 阻塞
get高效 volatile修饰 不需要加锁
volatile修饰节点指针
HashEntry
1.8
数组+链表+红黑树
CAS+synchronized
cas失败自旋保证成功
再失败就sync保证
node
ArrayList
数组
查找 访问速度快 增删效率低 线程不安全
LinkedList
双向链表
适合插入删除频繁的情况 内部维护了链表的长度
基础
UDP
语音
视频
直播
TCP
三次握手
syn seq
syn ack seq
ack seq
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
四次挥手
fin ack seq
ack seq
fin ack seq
fin ack seq
ack seq
场景
网络会话
文件传输
发送接收邮件
远程登录
如何保证可靠
HTTP
HTTPS
为啥安全
BIO
阻塞等待链接
阻塞等待数据
开线程处理并发
耗资源
NIO
非阻塞IO
epoll
粘包/拆包
在报文末尾增加换行符表明一条完整的消息，这样在接收端可以根据这个换行符来判断消息是否完整。
将消息分为消息头、消息体。可以在消息头中声明消息的长度，根据这个长度来获取报文（比如 808 协议）。
规定好报文长度，不足的空位补齐，取的时候按照长度截取即可。
将消息分为消息头、消息体。可以在消息头中声明消息的长度，根据这个长度来获取报文（比如 808 协议）。
规定好报文长度，不足的空位补齐，取的时候按照长度截取即可。
多路复用
select
单个进程可监视的fd数量被限制，即能监听端口的大小有限。
对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：
需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大
poll
大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义
poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
epoll
没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）；
效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。
内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。
neetty 非异步 阻塞 response trse id 感觉
序列化
多线程
synchronized
对象
对象头（Header）
Mark Word（存储对象的HashCode，分代年龄和锁标志位信息。）
Klass Point（对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。）
Monitor
EntryList
Owner（会指向持有 Monitor 对象的线程）
WaitSet
实例数据
对其填充
方法
ACC_SYNCHRONIZED
代码块
monitorenter
monitorexit
程序计数器 count
加减
锁膨胀
无锁
偏向锁
mark Word 中有线程信息 cas 比较
轻量级
复制了一份mark work 叫 Lock record 也是cas尝试改变指针
自旋
死循环
重量级
特性保证
有序性
as-if-serial
happens-before
可见性
内存强制刷新
原子性
可重入性
计数器
重锁
用户态内核态切换
sync 和 Lock的区别
synchronized是关键字，是JVM层面的底层啥都帮我们做了，而Lock是一个接口，是JDK层面的有丰富的API。
synchronized会自动释放锁，而Lock必须手动释放锁。
synchronized是不可中断的，Lock可以中断也可以不中断。
通过Lock可以知道线程有没有拿到锁，而synchronized不能。
synchronized能锁住方法和代码块，而Lock只能锁住代码块。
Lock可以使用读锁提高多线程读效率。
synchronized是非公平锁，ReentrantLock可以控制是否是公平锁。
synchronized会自动释放锁，而Lock必须手动释放锁。
synchronized是不可中断的，Lock可以中断也可以不中断。
通过Lock可以知道线程有没有拿到锁，而synchronized不能。
synchronized能锁住方法和代码块，而Lock只能锁住代码块。
Lock可以使用读锁提高多线程读效率。
synchronized是非公平锁，ReentrantLock可以控制是否是公平锁。
单一线程持有
劣势
锁升级不可逆
ThreadLocal
内存泄露
session
Lock
ReentrantReadWriteLock
ReadLock
WriteLock
ReentrantLock
NonfairSync
tryAcquire
acquireQueued
CAS
FairSync
hasQueuedPredecessors
如果是当前持有锁的线程 可重入
AbstractQueuedSynchronizer
入队 出队
头结点设计
共享和独享的实现
CAS
实际应用
存在的问题
cpu开销
只能保证一个共享变量原子操作
AtomicReference
ABA
标志位 时间戳
StampedLock
volatile
MESI
当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取
锁bus
volitale会一直嗅探 cas 不断循环无效交互 导致带宽达到峰值
总线风暴
Java内存模型JMM
高速缓存
可见性
嗅探机制 强制失效
处理器嗅探总线
有序性
禁止指令重排序
lock 前缀指令 内存屏障
源代码->编译器优化重排序->指令级并行重排序->内存系统重排序->最终执行的指令序列
happens-before
volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
as-if-serial
AtomicInteger
跳出死循环
线程池
newFixedThreadPool
newCacheThreadPool
SynchronousQueue
newSIngleTheadExecutor
newScheduledThewadPool
DelayedWorkQueue
newWorkStealingPool
ThreadPoolExecutor
参数意义
核心线程数
默认没线程等任务来了才调用 除非调用了 预创建线程 一个或者全部
最大线程数
空闲时间&单位
没有执行任务多久会终止 当线程池的线程数大于核心线程才会起作用 调用allowCoreThreadTimeOut会起作用
缓冲队列
LinkedBlockingQueue
无界 当心内存溢出
ArrayBlockingQueue
有界队列
加锁保证安全 一直死循环阻塞 队列不满就唤醒
入队
阻塞调用方式 put(e)或 offer(e, timeout, unit)
阻塞调用时，唤醒条件为超时或者队列非满（因此，要求在出队时，要发起一个唤醒操作）
进队成功之后，执行notEmpty.signal()唤起被阻塞的出队线程
阻塞调用时，唤醒条件为超时或者队列非满（因此，要求在出队时，要发起一个唤醒操作）
进队成功之后，执行notEmpty.signal()唤起被阻塞的出队线程
在进行某项业务存储操作时，建议采用offer进行添加，可及时获取boolean进行判断，如用put要考虑阻塞情况（队列的出队操作慢于进队操作），资源占用。
Synchronous
工厂方法
拒绝策略
抛异常
丢弃
重试
丢弃最早提交的
使用Has表维护线程的引用
submit
使用future获取任务的执行结果
实际使用
商品详情界面
批处理
执行过程
核心线程->队列->最大线程->拒绝策略
运行状态
有个Volatile的状态码
running
shutdown
stop
terminated
所有线程销毁
corePoolSize、maximumPoolSize、largestPoolSize 有意思
故障
JUC
常见问题
线程间是怎么进行通信的？
主要可以介绍一下 wait/notify 机制，共享变量的 synchronized 或者 Lock 同步机制等。
volatile
CountDownLatch
CyclicBarrier
ThreadLocal 用来解决什么问题？
可以从尽量减少临界区范围，使用 ThreadLocal，减少线程切换、使用读写锁或 copyonwrite 等机制这些方面来回答。
如何尽可能提高多线程并发性能？
ThreadLocal 是如何实现的？可以重点回答 ThreadLocal 不是用来解决多线程共享变量的问题，而是用来解决线程数据隔离
读写锁适用于什么场景？
可以回答读写锁适合读并发多，写并发少的场景，另外一个解决这种场景的方法是 copyonwrite。
如何实现一个生产者与消费者模型？
可以尝试通过锁、信号量、线程通信、阻塞队列等不同方式实现。
线程状态
线程就绪
start
sleep休眠超时
countDownLatch
只有一个构造方法 只会被赋值一次
没有别的方法可以修改 count
JVM
JVM内存模型
堆
栈
方法区
本地方法栈
程序计数器
类加载机制
加载->验证->准备->解析->初始化->使用->卸载
双亲委派原则
父类加载 不重复加载
分代回收
年轻代
Eden/s1/s2
老年代
永久代/元空间
晋升机制
根据存活时间
垃圾回收机制
标记清除
适用场景
对象存活比较多的时候适用
老年代
缺点
提前GC
碎片空间
扫描了两次
标记存活对象
清除没有标记的对象
标记复制
适合场景
存活对象少 比较高效
扫描了整个空间（标记存活对象并复制异动）
适合年轻代
缺点
需要空闲空间
需要复制移动对象
引用计数
没办法解决循环引用的问题
标记整理
垃圾回收器
CMS
分代
年轻
edan
s1
s2
minor gc
通过阈值晋升
老年
major gc 等价于 full gc
永久
缺点
对cpu资源敏感
无法处理浮动垃圾
基于标记清除算法 大量空间碎片
G1
分区概念 弱化分代
标记整理算法 不会产生空间碎片 分配大对象不会提前full gc
可以设置预设停顿时间
充分利用cpu 多核条件下 缩短stw
收集步骤
初始标记 stw 从gc root 开始直接可达的对象
并发标记 gc root 对对象进行可达性分析 找出存活对象
可达性分析算法
最终标记
筛选回收
根据用户期待的gc停顿时间指定回收计划
回收模式
young gc
回收所有的eden s区
复制一些存活对象到old区s区
mixed gc
GC模式
区别
g1分区域 每个区域是有老年代概念的 但是收集器以整个区域为单位收集
g1回收后马上合并空闲内存 cms 在stw的时候做
内存区域设置
XX:G1HeapRegionSize
复制成活对象到一个区域 暂停所有线程
full gc
老年代写满
system。gc
持久代空间不足
STW
实战
性能调优
设置堆的最大最小值 -xms -xmx
调整老年和年轻代的比例
-XX:newSize设置绝对大小
防止年轻代堆收缩：老年代同理
主要看是否存在更多持久对象和临时对象
观察一段时间 看峰值老年代如何 不影响gc就加大年轻代
配置好的机器可以用 并发收集算法
每个线程默认会开启1M的堆栈 存放栈帧 调用参数 局部变量 太大了 500k够了
原则 就是减少gc stw
FullGC 内存泄露排查
jasvism
dump
监控配置 自动dump
oom种类
逃逸分析
可达性
虚拟机栈（栈帧中的本地变量表）中引用的对象
方法区中类静态属性引用的对象
方法区中常量变量引用的对象
本地方法栈中JNI（即一般说的Native方法）引用的对象
活跃线程的引用对象
方法区中类静态属性引用的对象
方法区中常量变量引用的对象
本地方法栈中JNI（即一般说的Native方法）引用的对象
活跃线程的引用对象
JVM调优
OOM
内存泄露
线程死锁
锁争用
Java进程消耗CPU过高
JVM性能检测工具
Jconsole
Jprofiler
jvisualvm
MAT
内存泄露
help dump
生产机 dump
mat
jmap
-helpdump
CPU100%
topc -c
top -Hp pid
jstack
进制转换
cat
Spring
设计模式
单例
工厂
适配器
根据不同商家适配
责任链
继承 process 链路执行
源码
Bean
生命周期
扫描类
invokeBeanFactoryPostProcessors
封装beanDefinition对象 各种信息
放到map
遍历map
验证
能不能实例化 需要实例化么 根据信息来
是否单例等等
判断是不是factory bean
单例池 只是一个ConcurrentHashMap而已
正在创建的 容器
得到 class
推断构造方法
根据注入模型
默认
得到构造方法
反射 实例化这个对象
后置处理器合并beanDefinition
判断是否允许 循环依赖
提前暴露bean工厂对象
填充属性
自动注入
执行部分 aware 接口
继续执行部分 aware 接口 生命周期回调方法
完成代理AOP
beanProstprocessor 的前置方法
实例化为bean
放到单例池
销毁
作用域
单例（singleton）
多例（prototype）
Request
Session
循环依赖
情况
属性注入可以破解
构造器不行
三级缓存没自己 因二级之后去加载B了
三级缓存
去单例池拿
判断是不是正在被创建的
判断是否 支持循环依赖
二级缓存 放到 三级缓存
干掉二级缓存
GC
下次再来直接 三级缓存拿 缓存
缓存 存放
一级缓存 单例Bean
二级缓存 工厂 产生baen
产生bean 复杂
三级缓存 半成品
父子容器
事务实现原理
采用不同的连接器
用AOP 新建立了一个 链接
共享链接
ThreadLocal 当前事务
前提是 关闭AutoCommit
AOP
静态代理
实现类
动态代理
JDK动态代理
实现接口
java反射机制生成一个代理接口的匿名类
调用具体方法的时候调用invokeHandler
cjlib
asm字节码编辑技术动态创建类 基于classLoad装载
修改字节码生成子类去处理
IOC
类加载机制
过程
加载
生成一个class对象
验证
文件格式验证
元数据验证
字节码验证
符号引用验证
准备
默认值
static会分配内存
解析
解析具体类的信息
引用等
初始化
父类没初始化 先初始化父类
使用
卸载
加载方式
main（）
class。forName
ClassLoader。loadClass
类加载器
Appclass Loade
Extention ClassLoader
Bootstrap ClassLoader
双亲委派原则
可以避免重复加载
安全
Redis
数据结构
String
Hash
set
zset
score
随机层数
只需要调整前后节点指针
不止比较score
还会比较value
场景
成绩
积分
排行榜
List
分页的坑
HyperLogLog
Geo
Pub/Sub
BitMap
底层
SDS
键值的底层都是SDS
AOF缓存区
记录本身长度 C需要遍历
修改字符减少内存重新分配
空间预支配
惰性空间释放
二进制安全
C只能保存文本数据 无法保存图片等二进制数据
sds是使用长度去判断
杜绝缓冲区溢出
兼容部分C字符串函数
链表
保存多个客户端的状态信息
列表订阅发布 慢查询 监视器
字典
数据库 哈希键
Hash表节点
hash冲突用单向链表解决
渐进式 rehash
会逐渐rehash 新的键值对全部放到新的hash表
每个字典带 两个hash表
一个平时用 一个rehash时候用
压缩列表
整数集合
常见命令
Keys
setnx
exprie
高可用
持久化
RDB
5分钟一次
冷备
恢复的时候比较快
快照文件生成时间久，消耗cpu
AOF
appendOnly
数据齐全
回复慢文件大
数据初始化
从节点发送命令主节点做bgsave同时开启buffer
数据同步机制
主从同步
指令流
offset
快照同步
RDB
缓冲区
哨兵
集群监控
消息通知
故障转移
配置中心
脑裂
集群
链表
多主
横向扩容
分片
常见问题
缓存雪崩
加随机值
集群部署
缓存击穿
互斥锁
热点数据不失效
缓存穿透
布隆过滤器
双写一致性
延时双删
并发竞争
分布式锁
大Key
bigkey命令 找到干掉
Redis 4.0引入了memory usage命令和lazyfree机制
热点key
缓存时间不失效
多级缓存
布隆过滤器
读写分离
过期策略
定时删除
消耗内存
创建一个定时器
惰性删除
可能存在大量key
定期删除
检查 删除 但是是随机的
淘汰机制
LUR
最少使用
备用方案
主从+哨兵+cluster
ecache+Hystrix+降级+熔断+隔离
持久化
限流
setnx ex
zset
窗口滑动
zset会越来越大
令牌
定时push
然后leftpop
问题
空轮训
blpop
空连接异常
重试
漏桶 funnel
make_space 灌水之前调用漏水 腾出空间 取决于流水速率
Hash
原子性有问题
Redis-Cell
redis cell
选择方案
热点key
二级缓存
备份热key 走不同的机器
扩展
跳跃表
令牌
漏桶
scan
多路IO复用
read得读到很多才返回 为0会卡在那 直到新数据来或者链接关闭
写不会阻塞除非缓冲区满了
非阻塞的IO 提供了一个选项 no_blocking 读写都不会阻塞 读多少写多少 取决于内核的套接字字节分配
非阻塞IO也有问题 线程要读数据 读了一点就返回了 线程什么时候知道继续读？写一样
一般都是select解决 但是性能低 现在都是epoll
MongoDB
CAP定理（CAP theorem）
CAP概念
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
一致性(Consistency) (所有节点在同一时间具有相同的数据)
理论的核心
一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个
三大类
CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些
NoSQL优缺点
优点
高可扩展性
分布式计算
低成本
架构的灵活性，半结构化数据
没有复杂的关系
缺点
没有标准化
有限的查询功能（到目前为止）
最终一致是不直观的程序
BASE
Basically Availble --基本可用
Soft-state --软状态/柔性事务。 "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
Eventual Consistency --最终一致性 最终一致性， 也是是 ACID 的最终目的
MongoDB术语与SQL术语对应
database
database
collection
table
document
row
field
column
index
index
primary key
primary key
3. CRUD
插入/保存
单条插入
批量插入
注意
Insert和Save的区别
如果插入的集合的“_id”值，在集合中已经存在,用Insert执行插入操作回报异常，已经存在"_id"的键。用Save如果系统中没有相同的"_id"就执行插入操作，有的话就执行覆盖掉原来的值。相当于修改操作。
在新建一个集合或者一个数据库时，MongoDb不会在马上生成。而是在你添加了第一个数据后才会有显示。这个特性很多的数据库都用，
查询操作
①： >, >=, <, <=, !=, =。
db.user.find({"age":{$gt:22}})
db.user.find({"age":{$get:22}})
db.user.find({"age":{$lt:22}})
db.user.find({"age":{$lte:22}})
db.user.find({"age":{$ne:22}})
db.user.find({"age":22})
②：And，OR，In，NotIn
db.user.find({"name":"jack","address.province":"anhui"})
db.user.find({$or:[{"address.province":"anhui"},{"address.province":"guangdong"}]})
db.user.find({"address.province":{$in:["anhui","guangdong"]}})
db.user.find({"address.province":{$nin:["anhui","guangdong"]}})
③:正则表达式
find name startwith 'j' and endwith 'e'
Update操作
Remove操作
MySQL
分库分表
唯一主键
事务隔离级别
读未提交
没视图概念 都是返回最新的
读已提交
不同的read view
可重复度
用一个read view
序列化
回滚日志
没更早的read view删除
5.5之前回滚段删了文件也不会变小
索引
B+
Hash
等值查询
优化流程
预发跑sql explain
排除 缓存 sql nocache
看一下行数对不对 不对可以用analyze table t 矫正
添加索引 索引不一定是最优的 force index 强制走索引 不建议用
存在回表的情况
覆盖索引避免回表，不要*
主键索引
联合索引 不能无限建 高频场景
最左前缀原则 按照索引定义的字段顺序写sql
合理安排联合索引的顺序
5.6之后 索引下推 减少回表次数
给字符串加索引
前缀索引
倒序存储
Hash
数据库的flush的时机
redo log满了 修改checkpoint flush到磁盘
系统内存不足淘汰数据页
buffer pool
要知道磁盘的io能力 设置innodb_io_capacity 设置为磁盘的IOPS fio测试
innodb_io_capacity设置低了 会让innoDB错误估算系统能力 导致脏页累积
系统空闲的时候 找间隙刷脏页
MySQL正常关闭，会把内存脏页flush到磁盘
innodb刷盘速度
脏页比例
redolog 写盘速度
innodb_flush_neighbors 0
机械磁盘的随机io不太行 减少随机io性能大幅提升 设置为 1最好
现在都是ssd了 设置为0就够了 8.0之后默认是0
索引字段不要做函数操作，会破坏索引值的有序性，优化器会放弃走树结构
如果触发隐式转换 那也会走cast函数 会放弃走索引
字符集不同可能走不上索引
convert 也是函数所以走不上
聚集索引
非聚集索引
多扫描一次
减少回表
索引维护
页满了 页分裂 页利用率下降
数据删除 页合并
自增 只追加可以不考虑 也分页
索引长度
索引选择
普通索引
找到第一个之后 直到朋友不满足的
唯一索引
找到第一个不满足的就停止了
覆盖索引
包含主键索引值
最左前缀原则
安排字段顺序
索引空间问题
hash
5.6之后索引下推
不需要多个回表 一边遍历 一边判断
页的概念
更新
change buffer
更新操作来了 如果数据页不在内存 就缓存下来 下次来了 更新 在就直接更新
唯一索引 需要判断 所以 用不到change buffer
innodb的处理流程
记录在页内存
唯一索引 判断没冲突插入
普通索引 插入
记录不再页中
数据页读入内存 判断 插入
change buffer
数据读是随机IO 成本高
机械硬盘 change buffer 收益大 写多读少 marge
MVCC
版本链 在聚集索引中 有两个隐藏列 trx_id roll_pointer
读未提交
直接读取最新版本
序列化
加锁
Read View
读已提交
每次读取前生成一个
可重复度
第一次生成一个
锁
全局锁
全库逻辑备份
表锁
lock table read/write
MDL（metadata lock)
MySQL5.5引入 自动添加 读锁不互斥 写锁互斥
多个事务之前操作，如果查询的时候修改字段容易让线程池饱满
MySQL的information_schema 库的 innodb_trx 表 找到对应长事务 kill掉
alter table里面设定等待时间
Myisam是不支持表锁的
行锁
需要的时候才加上 并不是马上释放 等事务结束才释放 两阶段锁协议
死锁
超时时间
innodb_lock_wait_timeout
默认是50s太久 但是如果设置太短会误判 一般采用死锁监测
死锁机制 事务回滚
innodb_deadlock_detect = on
热点行
死锁消耗CPU
临时关闭
关掉死锁会出现大量重试
控制并发度
更多的机器 开启比较少的线程 消耗就少了
分治
间隙锁
读写锁
读
lock in share mode
for update
行锁
写
innodb如何加锁
Record lock: 对索引项加锁。
Gap lock:对索引项之间的‘间隙’,第一条记录前的间隙，或最后一条记录后的间隙 加锁
Next-Key:前两种的组合，对记录及前面的间隙加锁
Gap lock:对索引项之间的‘间隙’,第一条记录前的间隙，或最后一条记录后的间隙 加锁
Next-Key:前两种的组合，对记录及前面的间隙加锁
B+
log
undo log
回滚 mvcc
redo log
物理日志 内存操作记录
sync_binlog 可以优化日志写入时机
binlog
组提交机制，可以大幅度降低磁盘的IOPS消耗。
两段式提交 redo 准备 binglog 提交
count1 *
mvcc影响
主备延迟
强制走主
sleep
join
驱动表
id用完
bigint
row_id 没设置主键的时候
thread_id
mysql io性能瓶颈
设置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count参数，减少binlog的写盘次数。这个方法是基于“额外的故意等待”来实现的，因此可能会增加语句的响应时间，但没有丢失数据的风险。
将sync_binlog 设置为大于1的值（比较常见是100~1000）。这样做的风险是，主机掉电时会丢binlog日志。
将innodb_flush_log_at_trx_commit设置为2。这样做的风险是，主机掉电的时候会丢数据。
将sync_binlog 设置为大于1的值（比较常见是100~1000）。这样做的风险是，主机掉电时会丢binlog日志。
将innodb_flush_log_at_trx_commit设置为2。这样做的风险是，主机掉电的时候会丢数据。
常见命令
show processlist
查看空闲忙碌链接
wait_timeout
客户端空闲时间
定时断开链接
mysql_reset_connection 恢复链接状态
innodb_flush_log_at_trx_commit
redolog事务持久化
sync_binlog
binlog事务持久化
真实故障
数据库挂了 show processlist 一千个查询在等待 有个超长sql kill 但是不会引起flush table 周末 优化脚本 analyze 会导致 MySQL 监测到对应的table 做了修改 必须flush close reopen 就不会释放表的占用了
Zookeeper
Zookeeper概述
Zookeeper典型应用场景
数据发布/订阅 使用MQ代替
负载均衡
命名服务【提供一种分布式环境的统一ID解决方案】
分布式协调，通知，心跳服务
Zookeeper优势
源代码开放
高性能，易用稳定，该优势已在众多分布式系统中得到验证
有着广泛的应用，并且与众多大数据相关技术能实现良好的融合开发。
Zookeeper文件系统
每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
四种类型的znode
PERSISTENT-持久化目录节点
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
EPHEMERAL-临时目录节点
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
Zookeeper监听机制
Zookeeper命令
通过 ./zkCli.sh 进入客户端后，就可以使用命令来操作zookeeper了。
创建节点 create [-s] [-e] path data acl
查看节点内容 get path
查看子节点 ls /
更新节点内容 set path data
删除无子节点的节点 delete path
rmr path 删除当前节点及子节点
选举机制
半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
java操作zookeeper
通过ZkClient进行CRUD
监控节点
subscribeDataChanges：监控数据变化
subscribeChildChanges：监控子节点变化
subscribeStateChanges：监听zookeeper的状态
Dubbo
Netty
零拷贝
bio
阻塞IO 读写都阻塞
问题 带宽 资源等
每个请求过来 开一个线程阻塞
nio
不阻塞来着不拒
但是可能等待时间太久 响应延迟大了 太短了 会重试
IO多路复用
便捷的通知机制
程序注册一组socket文件描述符给操作系统，表示“我要监视这些fd是否有IO事件发生，有了就告诉程序处理”
select
遍历 判断事件是否可达 然后继续
poll
做了优化
epoll
有转态 会创建 文件描述符指向的表 监听增删改查
通道 buffer 多路复用
监听事件
aio
架构设计思路
执行链路
初始化channel
注册 channel到selector
任务队列
轮训accept事件 处理这些简历 channel的链接
注册 channel到selector 接收方
轮训写 事件 开线程去处理
任务队列
线程组
boss
监听端口所有准备就绪的时间
work
监听准备工作
调用链路
服务暴露过程
IOC 启动加载dubbo配置的标签
解析标签 ServiceBean 会生成一个Bean
实现了 initializingBean
afterpropertiesSet
get provider
set provider
各种信息 保存在 ServiceBean
IOC完成 还实现了一个 ApplicationListener监听器
回调onapplicationEvent
是否暴露 不是延迟暴露
暴露
信息校验 doexport
检查
doexportURL 暴露URL
加载注册中心信息
循环协议 端口
代理工厂获取invoke 封装
暴露invoke
根据spi来
本地暴露
打开 服务器 exchangeServer
启动服务器netty 监听端口
注册中心 注册服务
注册表
执行器
暴露 p 和 s 两个invoker的map保存了地址
spi
服务引用
factoryBean ->getObject ->get
init
信息检查
创建代理对象 createProxy
远程引用 获取到zk 获取到信息 订阅
dubbo 执行远程引用
创建 netty客户端
返回invoke
注册到注册表进去
成功
SPI
java spi
Java 没ioc aop
具体的spi kv形式
静态代理
容错机制
failover
直接切换
failfast
快速失败
failsafe
failback
forking cluster
broadcast cluster
整合 hystrix
失败回调
返回默认
降级
return null
失败返回空
负载均衡
随机 加权
轮训
最少活跃数
hash一致
选举算法
注册中心
协议
dubbo
默认 nio 单一长连接
二进制系列化 小数据量 100k
数据量中等 不适合文件传输
memcached
redis
webService
http
RobbitMQ
消费端限流
场景:首先，我们迎来了订单的高峰期，在mq的broker上堆积了成千上万条消息没有处理，这个时候，我们随便打开了
消费者，就会出现下面请如此多的消息瞬间推送给消费者，我们的消费者不能处理这么多消息 就会导致消费者出现巨大压力，甚至服务器崩溃
消费者，就会出现下面请如此多的消息瞬间推送给消费者，我们的消费者不能处理这么多消息 就会导致消费者出现巨大压力，甚至服务器崩溃
解决方案
rabbitmq 提供一种qos（服务质量保证）,也就是在关闭了消费端的自动ack的前提
下，我们可以设置阈值（出队）的消息数没有被确认（手动确认），那么就不会推送
消息过来.
下，我们可以设置阈值（出队）的消息数没有被确认（手动确认），那么就不会推送
消息过来.
限流级别
consumer级别
channel级别
实现方式
void BasicQos(uint prefetchSize,ushort prefetchCount ,bool global)
uint prefetchSize ：指定的是设定消息的大小(rabbitmq还没有该功能，所以一般是填写0表示不限制)
ushort perfetchCount ：表示设置消息的阈值，每次过来几条消息(一般是填写1 一条 一条的处理消息)
bool global：表示是channel级别的还是 consumer的限制(channel的限制rabbitmq 还没有该功能)
消息确认机制
生产端
概念
消息的确认是指，生产端投递消息后，若mq-server接受到消息，就会给生产者一个应答
生产端根据mq broker返回应答来确认该条消息是否正常发送到了broker,这种方式是消息可靠性投递的核心保障
如何做
第一步:在channel上开启确认模式 channel.confirmSelect();
第二步;在channel上增加confirm监听，来监听成功和异常的confirm结果，实现一个confirmListener接口
消费端
手动ack
场景：
消费端的ack类型:自动ack 和手动ack
做消息限流的时候，我们需要关闭自动ack 然后进行手动ack的确认,若我们业务出现了问题，我们就可以进
行nack
做消息限流的时候，我们需要关闭自动ack 然后进行手动ack的确认,若我们业务出现了问题，我们就可以进
行nack
如果消费者处理消息需要较长时间，最好的做法是消费端处理完之后手动去确认。
如何保证消息的可靠性投递
消息状态
0->发送中
1->mq服务签收消息成功
2->mq服务签收失败
3->消费端签收消息
4->消费端签收失败
0->发送中
1->mq服务签收消息成功
2->mq服务签收失败
3->消费端签收消息
4->消费端签收失败
生产端
1.保障消息成功发送出去
2.保障mq的节点成功收到消息
3.消息发送端需要收到mq服务的确认应答
4.完善的消息补偿机制（百分百成功成功 需要该步骤）
消费端
解决方案：1消息入库
1.生产这发送消息，并且记录消息信息入库，记录状态为0（初始状态）
2.消息投递到消息队列中
3.消息队列访问一个确认消息，也就是消息确认机制ConfirmListener
返回的ack信息，ack=true更新状态为1，false为2
返回的ack信息，ack=true更新状态为1，false为2
4.消费者消费信息，消费者消费正常，更新表状态为3，否则更新为4
5.定时抓取一定时间内的消息状态不是3的状态的消息，
判断一个是否在规定的retry次数内，在次数内的重复在发一次消息
判断一个是否在规定的retry次数内，在次数内的重复在发一次消息
解决方案2：消息的延迟投递, 做二次确认, 回调检查
step1 : 第一次消息发送, 必须业务数据落库之后才能进行消息发送
step2 : 第二次消息延迟发送, 设定延迟一段时间发送第二次check消息
step3 : 消费端监听Broker, 进行消息消费
step4 : 消费成功之后, 发送确认消息到确认消息队列
step5 : Callback Service监听step4中的确认消息队列, 维护消息状态, 是否消费成功等状态
step6 : Callback Service监听step2发送的Delay Check的消息队列, 检测内部的消息状态,
如果消息是发送成功状态, 则流程结束, 如果消息是失败状态, 或者查不到当前消息状态时, 会通知生产者, 进行消息重发, 重新上述步骤
如果消息是发送成功状态, 则流程结束, 如果消息是失败状态, 或者查不到当前消息状态时, 会通知生产者, 进行消息重发, 重新上述步骤
核心概念
server
又称为broker，接受客户端连接，实现amqp实体服务
channel
网络通道，几乎所有的操作都是在channel中进行的，是进行消息对象的通道，客户端可以建立
多个通道，每一个channel表示一个会话任务
多个通道，每一个channel表示一个会话任务
connection
连接,应用程序与brokder建立网络连接
virtual host
是一个逻辑概念,最上层的消息路由，一个虚拟主机中可以包含多个exhange 和
queue 但是一个虚拟主机中不能有名称相同的exchange 和queue
queue 但是一个虚拟主机中不能有名称相同的exchange 和queue
exchange
交换机: 消息直接投递到交换机上，然后交换机根据消息的路由key 来路由到对应绑定的队列上
baingding
绑定 exchange 与queue的虚拟连接,bingding中可以包含route_key
route_key
路由key ，他的作用是在交换机上通过route_key来把消息路由到哪个队列上
queue
队列，用于来保存消息的载体，有消费者监听，然后消费消息
message
服务器和应用程序之间传递数据的载体，有properties（消息属性,用来修饰消息,比如消息的优
先级,延时投递）和Body（消息体）
先级,延时投递）和Body（消息体）
return listener 消息处理机制
作用
Return Listener是用来处理一些不可路由的消息
情况一: broker中根本没有对应的exchange交换机来接受该消息
情况二:消息能够投递到broker的交换机上，但是交换机根据routingKey 路由不到某一个队列上.
处理
；若在消息生产端 的mandatory设置为true 那么就会调用生产端ReturnListener 来处理，
若消息生产端的mandatory设置为false(默认值也是false) 那么mq-broker就会自动删除消息
死信队列
概念
就是在队列中的消息如果没有消费者消费，那么该消息就成为一个死信，那这个
消息被重新发送到另外一个exchange上的话，那么后面这个exhcange就是死信队列
消息被重新发送到另外一个exchange上的话，那么后面这个exhcange就是死信队列
出现原因
消息被拒绝：（basic.reject/basic.nack）并且requeue(重回队列)的属性设置为
false 表示不需要重回队列，那么该消息就是一个死信消息
false 表示不需要重回队列，那么该消息就是一个死信消息
消息TTL过期
消息本身设置了过期时间，或者队列设置了消息过期时间x-message-ttl
队列达到最大长度:比如队列最大长度是3000 ,那么3001消息就会被送到死信队列上.
消息本身设置了过期时间，或者队列设置了消息过期时间x-message-ttl
队列达到最大长度:比如队列最大长度是3000 ,那么3001消息就会被送到死信队列上.
交换机类型
直连交换机:direct exchange
所以发送的direct exhchange 的消息都会被投递到与routekey名称(与队列名称)相同的queue上
**:direct模式下，可以使用rabbitmq自定exchange----> default exchange 所以不需要交换机和任何队列绑定,
消息将会投递到route_key名称和队列名称相同的队列上
**:direct模式下，可以使用rabbitmq自定exchange----> default exchange 所以不需要交换机和任何队列绑定,
消息将会投递到route_key名称和队列名称相同的队列上
topic_exchange
topic路由器的关键在于定义路由键，定义routingKey名称不能超过255字节
消费消息的时候routingKey可以使用下面字符匹配消息：
"*"匹配一个分段(用“.”分割)的内容；
"#"匹配0和多个字符；
"*"匹配一个分段(用“.”分割)的内容；
"#"匹配0和多个字符；
fanout交换器——发布/订阅模式
当你发送一条消息的时候，交换器会把消息广播到所有附加到这个交换器的队列上。
RocketMQ
基础组成
NameServer
无状态模式
broker向发心跳顺便带上所有的Topic信息
早期是zk后来改了
Broker
中转消息，消息持久化
底层通信基于Netty
Producer
同步
异步
单向
Consumer
pull
push
支持集群模式
多master
多master多slave异步复制
多master多slave双写
消费保证
发送成功后返回consume_success
回溯消费
高可用
集群
NameService 集群
Broker 主从 双主 双从
Consumer 自动切换
producer 链接两个Broker
刷盘
同步 超时会返回错误
异步 不返回
消息的主从复制
同步复制
异步复制
主从同步 异步刷盘
顺序消息
Hash取模
RocketMQ提供了MessageQueueSelector队列选择机制
顺序发送 顺序消费由 消费者保证
消费者是多线程
消息去重
幂等
去重
消息表主键冲突
分布式事务
最大努力
消息表 不断轮训 人工干预
半消息
发送半消息 发送成功 本地事务 觉得是否提交还是回滚 服务端没收到回查 检查本地事务 根据本地事务决定 提交
2/3pc
最终一致
预发 持久化 返回状态 发送处理结果 判断是否干掉持久化的 发送
完整的一个调用链路
producer 和NameService 节点建立一个长连接
定期从NameService获取Topic信息
并且向Broker Master 建立链接 发送心跳
发送消息给 Broker Master
consumer 从 Mater 和 Slave 一起订阅消息
消息重试
顺序消息重试
不断重试 16次 4小时46分钟 可以修改尝试次数
对一个消费者设置 组内都会设置
可以获取消息重试次数
无序消息重试
死信队列
不再被正常消费
保存3天
面向消费者组
控制台 重发 重写消费者 单独消费
事务消息
消息丢失
消息积压
决定是否丢弃
判断吞吐量
停止消费 加机器 加topic
分布式锁
Zookeeper
死锁
羊群效应
临时节点顺序
性能没redis高
Redis
jedis.set(String key, String value, String nxxx, String expx, int time)
性能比较高
数据库
死锁
设置一个失效时间用定时任务去跑
数据库集群 主备同步
搞个死循环排队
可重入设计一个字段累加
排它锁
用数据库自身的锁就可以了 行锁 索引
select XX for update
记得 提交
宕机数据库也会自动释放锁
缺点
比其他的更消耗资源
复杂
特点
互斥
安全性
死锁
容错
算法
贪心
分治
动态规划
快排
堆排
二叉树
链表反转
成环
环节点
跳楼梯
0 条评论
下一页
