A_69_distributed
2021-04-14 17:10:39 0 举报AI智能生成
全面、高效的知识图谱：A_69_distributed!! 全面又深度的提升认知，达到实际应用的目的! 建议先纵观全局，掌握好大方向。 再根据自己的需要，针对性的学习某一个点，最后做到逐步由点及面。
作者其他创作
大纲/内容
分布式
提高架构性能
缓存
缓存分区
缓存更新
缓存命中
负载均衡
服务路由
服务发现
异步调用
消息队列
消息持久
异步事务
数据镜像
数据同步
读写分离
数据一致性
数据分区
分区策略
数据访问层
提高架构稳定性
服务拆分
服务调用
服务依赖
服务隔离
服务冗余
弹性伸缩
故障迁移
限流降级
异步队列
降级控制
服务熔断
高可用架构
多租户系统
灾备多活
高可用服务
高可用运维
全栈监控
DevOps
自动化运维
分布式锁
Redis实现
lua脚本
redlock
1. 获取当期毫秒时间，轮流用相同的key和随机值在N个节点上请求锁，在这一步里客户端在每个master上请求锁时，会有一个比总释放时间小的多的超时时间，这样可以防止客户端在某个master 宕机时堵塞过长时间，如果这个master节点不可用我们应尽快尝试下一个master
2. 客户端计算获取锁所花的时间，只有当客户端在大多数master节点上成功获取了锁（在这里是3个），而且总共消耗的时间不超过锁释放时间，这个锁就认为是获取成功了。
3. 如果锁获取成功了，那现在锁自动释放时间就是最初的锁释放时间减去之前获取锁所消耗的时间。
4. 如果锁获取失败了，不管是因为获取成功的锁不超过一半（N/2+1)还是因为总消耗时间超过了锁释放时间，客户端都会到每个master节点上释放锁，即便是那些他认为没有获取成功的锁。
Zookeeper实现
一致性算法
强一致性
主从同步（保证CP）
多数派
Paxos
Basic Paxos
角色
1. Client: 系统外部角色，请求发起者，像民众
2. Propser: 接受Client请求，向集群提出提议。并在冲突发生时，起到冲突协调作用。像议员替民众提出议案。
4. Learner : 提案学习者。一个提案超过半数accpetor通过即可被确定，其他未确定的Acceptor可以通过learner来同步结果。对集群一致性没影响，像记录员
流程
1. Prepare阶段
2. Promise阶段
3. Accept阶段
未超过半数的accpetor回复承诺，则本次提案失败
超过半数的Acceptor回复承诺，又分为不同情况
1. 所有Acceptor都未接收过value（都为null），那么向所有的Acceptor发起（Propose）自己的value和提案编号n
2. 如果有部分Acceptor接收过value，那么从接受过的value中选择提案编号最大的value作为本次提案的value，提议编号仍然为n
4. Accepted阶段
时序图
分支主题
缺点
活锁
难实现
效率低
Multi Paxos
Fast Paxos
Raft
划分三个子问题
Leader Election
Log Replication
Safety
Leader
Follower
Candidate
选举过程
子主题 4
一致性协议
二阶段提交
提交过程
投票
1. 协调者向各个节点发送提交事务的消息
2. 各节点接收到消息后开始执行事务但不提交，同时记录Redo、Undo日志
3. 各节点执行完成事务后向协调者反馈执行结果
此处会引申出两将军问题及拜占庭将军问题
执行
提交事务
1. 向各节点发送提交请求
2. 节点开始提交事务
3. 反馈事务提交结果
1. 全部响应Yes
2. 部分响应No
原因
执行业务的事务失败
网络超时
4. 完成事务
回滚事务
1. 发送回滚请求
2. 利用Undo信息回滚事务
3. 反馈事务结果
4. 完成终端机事务
优点
原理简单，实现方便
同步阻塞
单点问题
数据不一致
过于保守
三阶段提交
CanCommit
1. 询问各个节点是否可以执行事务
2. 各个节点向协调者反馈询问结果
PreCommit
执行事务预提交
协调者向各个节点发送预提交请求
各个节点执行事务预提交，并记录Redo Undo 日志
各个节点反馈执行结果
中断事务
doCommit
发送提交请求
各个节点提交事务
反馈事务提交结果
完成事务
Paxos算法
常见模式
Cache Aside
可能存在多个应用实例并发更新的情况
1. 若是用户数据则几率较小
2. 对于读服务场景，可以考虑使用一致性哈希，将相同的操作负载均衡到同一个实例，从而减少并发几率。或设置比较短的过期时间
（1）修改服务Service连接池，id取模选取服务连接，能够 保证同一个数据的读写都落在同一个后端服务上
（2）修改数据库DB连接池，id取模选取DB连接， 能够保证同一个数据的读写在数据库层面是串行的
3. 使用分布式锁，不考虑操作顺序
4. 假如要求顺序操作，则可使用MVCC数据多版本并发控制
Cache-As-SoR
read-through
write-through
write-behind
缓存删除失败如何处理
1. 将相应的key放入队列中待后续继续重试
2. 通过订阅数据库的binlog日志来删除（canal中间件），若仍删除失败则将key放入消息队列
redis
缓存与数据库双写一致性问题
缓存雪崩
缓存击穿
并发
数据结构
string
list
set
hash
zset
命令
blpop/brpop
keys
没有limit，我们只能一次性获取所有符合条件的key，如果结果有上百万条，那么等待你的就是“无穷无尽”的字符串输出。
keys命令是遍历算法，时间复杂度是O(N)。这个命令非常容易导致Redis服务卡顿。因此，我们要尽量避免在生产环境使用该命令。
scan
scan命令的时间复杂度虽然也是O(N)，但它是分次进行的，不会阻塞线程。
scan命令提供了limit参数，可以控制每次返回结果的最大条数。
它返回的结果有可能重复，因此需要客户端去重
Pipeline
Replication主从复制
1. Slave连接Master，首次连接会进行完全同步。Master创建一个RDB文件（快照方式），发送给Slave，并在发送期间使用缓冲区记录该期间客户端请求的写命令。RDB发送完毕之后，开始向Slave发送存储在缓冲区中的写命令；
2. Slave丢弃所有旧数据，载入Master发来的RDB文件，之后开始接受Master发来的写命令。Master每执行一次写命令，将向Slave发送相同的写命令；
3. 如果Slave中断后重新启动，向Master请求数据，会先发送自己的Replication ID及offset与Master进行对比，如果Replication ID一致，即可在offset的基础上进行部分缺失数据同步。
psync1
psync2
概念
全量重同步
部分重同步
replication backlog buffer
offset
run_id
演变
1. Reis 2.8 版本之前 Redis 复制采用 sync 命令，无论是第一次主从复制还是断线重连后再进行复制都采用全量同步，成本高
2. Reis 2.8 ~ 4.0 之间复制采用 psync 命令，这一特性主要添加了 Redis 在断线重连时候可通过 offset 信息使用部分同步
3. Reis 4.0 版本之后也采用 psync，相比于 2.8 版本的 psync 优化了增量复制，这里我们称为 psync2，2.8 版本的 psync 可以称为 psync1
持久化
AOF
同步策略
everysec
no
always
重写或压缩
RDB 快照
过期策略
定时过期
惰性过期
定期过期
Redis中同时使用了惰性过期和定期过期两种过期策略
内存淘汰策略
noeviction
allkeys-lru
volatile-lru
volatile-lfu
allkeys-lfu
volatile-random
allkeys-random
volatile-ttl
LFU算法从4.0版本开始引入
实现
Sorted Set
ziplist
skiplist
高可用
主从模式
sentinel
缺陷
Redis Sentinel 水平扩容一直都是程序猿心中的痛点，因为水平扩容牵涉到数据的迁移。迁移过程一方面要保证自己的业务是可用的，一方面要保证尽量不丢失数据所以数据能不迁移就尽量不迁移
cluster
常见问题
缓存穿透
将没有查询到数据的key也设置到缓存中，设置一定过期时间
使用布隆过滤器，将所有可能存在的数据哈希到一个足够大的位图中
将热点数据设置为永不过期
基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据
事前 ： redis高可用，主从+ 哨兵，redis cluster，避免全盘崩溃
事中： 本地 ehcache缓存 + hystrix 限流& 降级，避免MySQL崩溃
事后： Redis 持久化，一旦重启自动从磁盘上加载数据，快速恢复缓存数据
集群扩容
垂直扩容
水平扩容
高并发
应用无状态
拆分
系统维度
功能维度
AOP维度
读写维度
模块维度
服务化
幂等设计
MVCC方案
去重表
select + insert
状态机幂等
token机制
需要接入商户提交付款请求时附带：source来源，seq序列号。source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
OpenApi
理论
CAP
consistency
Availability
Partition Torlerance
BASE
Base Available
响应时间上的损失
功能上的损失
Soft state
Eventually consistent
Causal consistency (因果一致性 )
Read your writes 读己之所写
Session consistency 回话一致性
Monotonic read consistency 单调读一致性
Monotonic write consistency 单调写一致性
通信方式
同步
RPC
实现考虑
2. 序列化与反序列化，hessian、protobuf、json、kryo等
3. 服务注册与发现
4. 负载均衡及容错
5. 结果缓存
6. 接口多版本控制
现有案例
motan
gRPC
Apache Thrift
Dubbo
rpcx
dubbox
HTTP - 特殊的RPC
Http 1.0 短连接
Http 1.1 Keep-Alive 保持长连接
Http 2.0
异步
MQ
服务治理
服务注册与发现
Zookeeper
ZAB协议（Zookeeper Atomic Broadcast）
选举机制
Eureka
etcd
Consul
分布式事务
两阶段提交
TCC
一致性分类
强一致性（strong）
单调一致性（monotonic）
会话一致性 （session）
最终一致性（eventual）
弱一致性（weak）
常用框架
容错机制
Failover 失败自动切换
Failfast 快速失败
Failsafe 失败安全
Failback 失败自动恢复
Forking 并行调用多个服务器
Broadcast 广播调用
负载均衡机制
random随机
roundrobin轮询
leastactive最少活跃数
consistanthash 一致性哈希
整体流程
1. 服务容器启动、加载和运行服务提供者
2. 服务提供者在启动时向注册中心注册自己的服务，而服务消费者在启动时，在注册中心订阅自己所需的服务
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
4. 服务消费者从提供地址列表中基于软负载均衡算法选一台提供者进行调用，如果调用失败再选另一台调用
5. 服务消费者和提供者 ，在内存中累计调用次数和时间，定时每分钟发送一次统计数据到监控中心
协议
dubbo
RMI
hessian
SpringCloud
Netflix Eureka(保证AP)
1. 服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
Consul(保证CP)
1.服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
2.Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
服务网关 Zuul
统一接入
请求路由
版本控制
容错性
服务埋点
流量监控
限流
降级
安全防护
防止恶意攻击
IP黑白名单
频率限制
频次限制
鉴权
内外网隔离
业务隔离
关键技术
应用整体监控
基础层监控
CPU
网络
IO
内存
...
中间层监控
数据库
应用容器
网关
Jvm
应用层监控
Api请求
吞吐量
响应时间
错误码
调用链路
函数调用栈
业务指标
资源、服务调度
计算资源调度
磁盘
服务调度
服务编排
服务复本
服务容量伸缩
故障服务迁移
服务生命周期管理
架构调度
多租户
架构版本管理
部署、运行、更新、销毁
灰度发布
状态、数据调度
数据可用性
多副本保存
读写一致性策略
数据分布式
数据索引、分片
流量调度
服务降级
服务保护
流量控制
流量分配
异地灾备
流量管理
协议转换
请求校验
数据缓存
数据计算
0 条评论
下一页
