分布式
2020-11-01 11:55:37 0 举报AI智能生成
分布式
作者其他创作
大纲/内容
分布式
理论
CAP
C:一致性
写操作带来的影响始终可以在后续的操作中准确获取。（类似：可见性）
集群：一个有状态的服务，对其中一个节点状态的修改，其他节点都需要能同步修改，且在同步完成前不能提供服务。
如：数据库数据、缓存中间件数据、节点缓存数据等，这些都是状态。
主从模式，读写都在一个节点，必定强一致
主节点失效时，从节点升级为主节点且必须等待同步完主节点数据才能提供服务
强一致，选主和同步期间不可用
关系型数据库
Zookpeer
单机吞吐量有限，大并发会导致响应延迟，甚至宕机
可用性差
A:可用性
集群：能处理的请求量在总请求量的占比高
节点无状态
无状态没有一致性要求，始终高可用
节点有状态
主从同步
主节点失效时，从节点升级为主节点后不等待主节点数据同步完，直接提供服务
高可用，但数据会不一致
Redis
相互复制
节点平等，所有节点都能独立提供服务，始终高可用
节点间，数据复制有时差，数据不一致
Eureka
P:分区容忍性
集群：由于节点故障或网络原因，节点被分成了无法通信几个分区，每个分区依然能正常提供服务
失败转移
多节点负载均衡
状态同步
BASE
BA:基本可用
当P出现时，允许损失部分可用性
S:软状态
不同节点的状态进行同步时，允许存在延时
E:最终一致性
经过一段时间的同步后，所有节点的状态最终都能达到一致
事务
ACID
A:原子性
事务的所有操作要么全部提交成功，要么全部失败回滚。
事务前后数据的完整性必须保持一致。
I :隔离性
并发的事务相互隔离，一个事务的执行不能不被其他事务干扰。
读未提交
读已提交
可重复读
串行化
D:持久性
事务一旦被提交，它对数据库中数据的改变就是永久性的
2PC
准备提交
协调者发起事务预处理请求
参与者执行本地事务但不提交，再向协调者反馈结果
执行提交
所有参与者反馈的都是Yes，协调者会发起事务提交请求
参与者提交本地事务
参与者回滚本地事务
缺点
性能问题
所有参与节点都是事务阻塞型的
单点故障
协调者和参与者任何节点出现宕机时，事务状态会无法正常处理，导致全事务阻塞
数据不一致
当参与者在2阶段真正提交事务前宕机了，就会造成有些参与者成功，有些参与者失败的情况，破坏了原子性，造成数据不一致
3PC
询问提交
协调者发起事务询问
参与者尝试获取数据库锁，并将结果反馈给协调者
同2PC，协调者和参与者都引入了超时机制
同2PC
改进了2PC的单点故障引起的阻塞问题。通过设置超时时间，减少单点故障后造成的阻塞问题
ID
UUID
MySQL主键自增
雪花算法
Redis生成
双buffer ID段
库存
数据库水平分库分表
ShardingJdbc
热点库存优化
优化数据库性能
减少加锁时间
请求幂等
过滤无效请求
缓存分桶
分片
节点取余分区
hash（key）%N
简单性，常用于数据库的分库分表规则，一般采用预分区的方式
扩容时通常采用翻倍扩容，避免数据映射全部被打乱导致全量迁移的情况
当节点数量变化时，数据和节点映射关系需要重新计算，会导致数据的重新迁移
一致性哈希分区
为系统中每个节点分配一个token，范围一般在0~2^{32}，这些token构成一个哈希环。数据读写执行节点查找操作时，先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。
加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响
但数据不均匀
加减节点会造成哈希环中部分数据无法命中
在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题。
虚拟节点解决
通常将虚拟节点数设置为32甚至更大
0 条评论
回复 删除
下一页
