分布式系统各种问题和解决方法
2018-05-20 10:50:51 449 举报AI智能生成
分布式系统在处理大量数据和提供高并发服务时具有显著优势，但同时也面临着许多挑战。这些问题包括数据一致性、系统可用性、容错性和性能等。为了解决这些问题，可以采用多种方法，如使用一致性协议（如Paxos或Raft）来保证数据的一致性，通过负载均衡和冗余设计提高系统的可用性，利用故障切换和数据复制技术实现容错，以及通过优化算法和硬件资源提高性能。此外，还需要对系统进行持续监控和维护，以便及时发现并解决问题。
作者其他创作
大纲/内容
问题&解决方案
JVM垃圾回收器
Serial&SerialOld
-XX:+UseSerialGC
YOUNG
复制收集
OLD
标记整理
ParNew
-XX:+UseParNewGC
并发复制收集
OLD(不支持)
默认使用SerialOld收集器收集
CMS
-XX:+UseConcMarkSweepGC
YOUNG（不支持）
默认使用ParNew收集器
并发标记清理
初始标记（暂停用户线程）
标记GC ROOT关联对象
并发标记（和用户进程并行）
沿着GC ROOT向下遍历对象
重新标记（暂停用户线程）
处理并发标记期间的更新
并发清理（和用户进程并行）
Current Mode Failure
退化成Serial Old收集（暂停用户线程）
特点
低停顿，暂停时间短
会产生内存碎片 CPU占用较高
Parallel Scanvage
-XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy(可选)
并发的复制收集
并发标记整理
注重减少垃圾回收时间占程序运行时间的比例（比例低吞吐量大）
可以启用自适应调节GC配置的功能
G1
java gc基本概念
GC分类
FULL GC
对老年代中的对象进行回收
一般当老年代空间不足时发生
YOUNG GC
对新生代对象的回收
暂停线程，移动存活对象到survivior/old区
STW
GC中需要用户线程停止运行，保证标记阶段不会出现数据更改
SafePoint
作用
用户线程到达安全点才开始执行GC（因为在安全点处记录了此刻对象引用的地址信息）
定义
安全点一般是“让程序长时间执行的指令”
方法调用
异常跳转/循环跳转。。
使用
用户线程轮询一个标记，在GC开始时修改这个标记，然后用户线程会主动挂起自己此时已到达安全点
没有获得CPU时间的线程，在GC时通过SafeRegion实现类似功能
分代
新生代
Eden
Survivor
老年代
永久代
方法区的中数据
1.7 hotspot 字符常量等内容被移到堆中
1.8 用元空间代替永久代，元空间使用本地内存
可达性分析
从GC Root出发不可访问到的对象 会被视为不可达
不可达对象会在GC阶段首先被标记
GC ROOT
方法区的常量引用&静态引用
JVM栈中引用的对象
活跃线程&它本地栈中引用的对象
HotSpot OopMap
GC开始前就预先保存了GC Root的引用的内存地址，加快查找速度
JVM内存结构
共享区域
堆
对象
方法区
Class对象
常量池
1.7hotspot 后常量池放在了堆中
私有区域
JVM栈
局部变量表
reference引用
returnAddress字节码指令地址
操作数栈
JNI方法栈
程序计数器
线程执行字节码时的行号指示器
直接内存
JVM引用分类
StrongReference
一般都是强引用
不会被垃圾回收
SoftReference
当内存不足时才被回收
WeakReference
下一次GC就会被回收
PhantomReference
不能通过虚引用获得对象实例
作用仅限于被回收时通知
引用类基类
abstract Reference<T>
ReferenceQueue
ReferenceHandler
分布式存储
缓存 伸缩性设计
数据要分片在多个节点保存
保证扩容时对线上服务影响最小
保证原来的key尽量落在原来的位置，否则就会失效
分片方案
hash取模
优点：hash保证分布均匀
缺点：扩容时原来的key取模结果不同了
实现
index = hash(key) mod slotSize
一致性hash
优点：扩容时，只有部分缓存数据失效
缺点：扩容后会导致，各节点负载不均衡
查找操作
根据index顺时针寻找最近节点
扩容操作，向环中添加节点
Node 1 和Node 3流量较少
使用虚拟节点映射物理节点，让节点更稀疏
变的稀疏了吧
实例
memcache
redis cluster
hbase
数据库 伸缩性设计
数据分布在不同节点上
每个节点都要有一个备份
扩容时需要移动数据，任何数据都不能丢失（和缓存不同）
不支持 跨库join
分页变复杂
保证多个节点一致性
参与者+协调者模式
2PC
prepare阶段（投票阶段）
协调者
发送commit请求
参与者
写redo/undo log
ACK 同意 或 拒绝commit
commit阶段
所有参与者同意
发出正式提交请求
等着所有参与者 ACK，然后完成事务
有不同意 或 ACK超时
发出 回滚请求
等着所有参与者回滚，然后取消事务
收到正式提交请求
提交 释放占用资源 ACK
收到回滚请求
回滚 ACK
图示
缺陷
第一阶段完成后，协调者挂机，则参与者会一直被阻塞，资源也无法释放
当故障恢复之后，协调者不确定多少参与者已经执行的commit操作
无法处理网络分区问题
3PC
commit阶段中引入了preCommit阶段，所有参与者同一提交才会真正提交
还是无法处理网络分区
X/Open DTP
TM
事务统一管理
RM
资源管理（不同节点的数据库等）
AP
应用程序
1阶段 准备 2阶段提交（回滚）
paxos协议
前提
不会发生拜占庭问题，消息不被串改
分类
basic paxos
角色
正常流程
阶段一
prepare
proposer生成新编号N标记的议案，给quronum个acceptor发生prepare消息
promise
N小于之前接收议案编号则忽略，或者返回拒绝消息
阶段二
发送accept请求
这个value是proposer自己选择的或者是从acceptor返回的value中选择的最大值
响应accept请求
如果acceptor没有给大于N议案回复promise消息，那么就必须接受accept消息，返回accepted
足够多的acceptor回复accepted，本次议案通过，达成一致
异常流程
proposer没有收到足够多的promise、accepted消息
多个proposer发送的prepare消息冲突
两个proposer都重试增加议案号，导致彼此的议案都不能被接受
约束
每次投票只会对一个value达成一致
multi paxos
与basic paxos的不同
没有多个proposer
每次的议案编号完全由leader控制
当leader确定可用后，省去了prepate/promise阶段
初始化流程，选主
第一个议案通过流程和basic paxos基本相同，不过leader会在这次确定下来，leader控制的议案号I也会确定
一阶段提交
leader直接发送accept请求，议案号为I+1
足够多的acceptor接收，议案通过
cheap paxos fast paxos .....
0 条评论
回复 删除
下一页
