分布式相关最全的知识点
2022-02-21 18:23:06 1 举报AI智能生成
分布式相关最全的知识点
作者其他创作
大纲/内容
一致性 Hash 算法
分布式系统接口调用保证顺序性
根据一致性 Hash 算法将需要保证顺序性的请求打到一个机器上
建立内存队列进行执行
分布式 session 如何实现
分布式事务
XA 方案（两阶段提交方案）
适用场景
一个系统跨多个数据库操作
原理
事务管理器管理多个事务
实现
Spring+JTA
TCC方案
seata开源框架
本地消息表
基于 Mysql 中自建的消息表
可靠消息最终一致性（较多公司在用）
基于 RocketMQ(3.2.6之前的版本)
最大努力通知
建议不用分布式事务
1. 监控（发邮件发短信）
2. 记录日志
3. 事后补偿
如何设计一个高并发系统
系统拆分
缓存
MQ
分库分表
为什么要分库分表
数据量大：单表一千万，系统瓶颈
分库分表中间件
cobar
TDDL
sharding-jdbc（常用）
优点
无需部署，集成在 cilent 端
运维成本低
无需转发，性能高
缺点
版本升级需要重新发布
各个项目强依赖 sharding-jdbc
mycat
优点
对于项目是透明的，作为代理层
缺点
运维成本高
未分不分表的系统如何动态切换到分库分表
不停机双写方案
如何设计动态扩容的分库分表方案
分库分表后 id 主键如何处理
全局的数据库自增 ID
优点
简单
缺点
数据库自增 ID 库会成为瓶颈
适用场景
并发低但是数据量大
uuid
优点
本地生成
缺点
作为 Mysql主键不合适
系统当前时间+业务值+随机值
snowflake 算法
读写分离
原理
mysql 原生支持的主从复制
主库写并发越高，从库延迟越高
主库宕机数据丢失问题
配置打开半同步复制机制（主库确保一定会有一个从库
同步成功才保证这个写操作是成功的）
同步成功才保证这个写操作是成功的）
主从同步延时问题
准确性强的业务强制性走主库
将主库分库
Elasticsearch
如何设计一个高可用系统
限流
熔断
降级
消息队列
项目中是如何使用消息队列的
为什么要用消息队列
解耦
异步
削峰
引入消息队列有什么缺点
系统可用性降低
系统复杂性升高
一致性问题
市面上各个消息队列有什么优缺点
RabbitMQ
优点
erlang 开发，低时延
监控、管理方便
开源社区活跃
功能完备
缺点
erlang 开发很难定制化开发
ActiveMQ
缺点
官方社区基本不维护了
数据量吞吐量少
优点
功能完备
Kafka
优点
吞吐量高
消息批处理：减少网络通信开销
磁盘顺序读写：减少寻道移臂开销
利用 PageCache 加速消息读写：减少磁盘 IO 开销
零拷贝技术：减少数据多次拷贝的开销
易扩展
适合大数据实时采集
缺点
仅支持简单的 MQ 功能
RocketMQ
优点
单机吞吐量大
分布式，扩展起来方便
Java 开发，容易读懂源码
缺点
阿里有可能会弃掉的风险
如何保证消息队列发消息的可靠性（保证消息不丢）
RabbitMQ
生产者消息丢失
try，catch 利用事务
吞吐量低
利用 confirm 机制，异步模式
吞吐量高
MQ 消息丢失
消息持久化到磁盘中
创建 queue 时设置为持久化
设置消息 deliveryMode 为 2，消息持久化
消费者消息丢失
关闭 autoAck 机制，手动进行确认消息
Kafka
生产者消息丢失
设置 acks=all可以保证不会丢失数据
MQ 消息丢失
leader 机器宕机，将 follower 切换为 leader 之后数据丢失
给 topic 设置 replication.factory参数，必须大于1，每个 partion 至少有两个副本
设置 min.insync.replicas参数，必须大于 1。用于 leader 感知是否还有一个 follower 和自己保持联系
在 producer 端设置 acks=all，要求每条数据写入所有副本才认为写入成功
消费者消息丢失
关闭自动提交 offset
RocketMQ
生产者
采用同步发送策略
服务器
同步刷盘策略，接收到消息立即刷磁盘
主从消息同步都成功才代表成功
消费者
消费成功后才会返回 ack
如何保证消息队列的顺序性
RabbitMQ
一个 queue 对应多个消费者可能导致顺序不一致
解决办法
一个 queue 对应一个消费者，将需要保证顺序性的消息发送到一个 queue 中
Kafka
写入一个 partion 中的数据一定是有顺序的，生产者在写入时可以指定一个 key
消费者如果内部使用多线程消费 Kafka 的消息可能导致顺序不一致
解决办法
内部建立多个内存队列，将需要保证顺序的消息放入到一个内存队列中
队列积压了消息怎么办
消费者扩容消费
如何保证消息消费时幂等性
基于数据库的唯一索引
消息队列如何保证高可用
RabbitMQ
单机模式
普通集群模式
不是高可用的
镜像集群模式
是高可用的
如何开通镜像集群
在管理控制台新增一个策略，指定要求在新建 queue 时是将数据同步
所有 queue 还是指定数量 queue
所有 queue 还是指定数量 queue
Kafka
分布式架构 数据分开存储
leader 和 follower 之间数据同步
RocketMQ
如果要你设计一个消息队列，该怎么做？
快速扩容
数据落磁盘
高可用
数据丢失问题
缓存
在项目中缓存是如何使用的？
缓存都有哪些？优缺点？
redis
支持的数据类型多
支持更多复杂的场景
单线程
原生支持 cluster 模式
memcached
多线程
支持的数据类型较少
无原生的集群模式
为什么在项目中使用缓存
高性能
高并发
用了缓存后有什么不良后果
缓存与数据双写不一致
先删除缓存再更新数据库
在业务系统内存中建立队列，根据顺序执行
延时双删
缓存雪崩
事前
redis 高可用
事中
在本地 ehcache加缓存+hystrix限流+降级
事后
redis持久化机制，尽快恢复缓存集群
缓存穿透
布隆过滤器
缓存并发竞争
分布式锁
确保同一时间只有一个系统实例在操作某个 key
redis单线程模型
文件事件处理器
为什么redis 单线程还能这么快
非阻塞的 IO 多路复用机制
纯内存操作
避免了多线程频繁上下文切换
redis 都有哪些数据类型？适用哪些场景
String
hash
对象
list
利用 lrange 进行分页查询
set
全局去重
zset
Redis 的过期策略，手写 LRU 算法
redis 对于过期 key 处理策略
定期删除+惰性删除
redis内存淘汰机制
noeviction
拒绝写请求，读和del可继续（不淘汰key，默认策略）
volatile-lru
淘汰设置了过期时间的key，采用LRU算法，没有设置过期时间的不淘汰
volatile-ttl
淘汰设置了过期时间的key，key的剩余寿命ttl的值，ttl越小越优先淘汰
volatile-random
从已设置过期时间的key中随机淘汰
allkeys-lru
淘汰所有的key，使用LRU算法
allkeys-random
所有的key随机淘汰
手写 LRU 算法
利用 Java 的 LinkedHashMap 实现
如何保证 Redis 高并发高可用
高并发
高可用
redis cluster
核心算法
hash slot 算法
分配 16384 个 slot，然后对其进行取模，找到相应的 master 节点
节点间通信
gossip 协议
redis 的持久化有哪几种方式
RDB
对 Redis 中的数据进行周期性的持久化
优点
适合做冷备份
性能高，对 redis 本身影响小，fork 一个子进程，子进程进行持久化
故障后数据恢复更快
缺点
故障时有可能会丢失更多的数据
如果子进程在持久化生成磁盘文件如果特别大话，那么有可能会阻塞客户端
AOF
对写命令进行记录
优点
更好的保护数据不丢失，每间隔 1 秒，通过后台执行 fsync 操作
日志写入是追加写入，写入效率高
缺点
同一份数据来说，AOF 日志比 RDB 数据快照文件大
会影响 Redis 的效率
如何选择？
1. 不要仅仅使用 RDB，有可能会导致丢失数据
2. 不要仅仅使用 AOF，RDB 做备份更加快
3. 综合使用 AOF 和 RDB
你们公司生产环境 Redis 是如何部署的
redis cluster
10 台机器
5 台机器部署 master 节点
最多是 25w 读写请求/s
5 台机器部署 slaver 节点
32G 内存+8 核CPU+1T 磁盘
分配给 redis 进程的是 10g 内存
目前高峰期每秒 3500 请求量
Dubbo
工作原理
service层：provider 和 consumer 接口，留给使用者实现
config 层：任何一个框架，都需要提供配置文件，让你进行配置
proxy 层：代理层，无论是 consumer 还是 provider，dubbo 都会生成代理，代理之间进行网络通信
registry 层：provider 注册自己作为个服务，consumer 去注册中心寻找自己要调用的服务
cluster 层：provider 可以部署在多台机器上，多个 provider 组成了一个 cluster
monitor 层：consumer 调用 provider，调用多少次？监控信息
protocol 层：负责具体的 provider 和 consumer 之间的网络通信
exchange 层：信息交换层
serilize 层：序列化
dubbo 支持哪些序列化协议和通信协议
通信协议
dubbo 协议（默认）
单一长连接
NIO异步通信
rmi 协议
序列化协议
hessian(默认)
Json
Java
负载均衡策略
按照权重请求（默认）
均匀流量打到各个机器
根据机器性能自动感知
一致性 Hash 算法请求
集群容错策略
failover cluster 模式
失败自动切换，自动重试其他机器（默认）
failsafe cluster 模式
出现异常时忽略掉，常用于不重要的接口调用，比如记录日志
failback cluster 模式
失败了后台自动记录请求，然后定时重发，比较适合于写消息队列
failfast cluster 模式
一次调用失败就立即失效
forking cluster 模式
并行调用多个 provider，只要一个成功就立即返回
broadcacst cluster 模式
逐个调用所有 provider
动态代理策略
默认使用 javassist 动态字节码生成
SPI 扩展
服务治理
调用链路自动生成
服务访问压力以及时长统计
服务降级
失败重试
超时重试
如何设计一个类似的 dubbo框架
注册中心
动态代理
负载均衡
网络请求
序列化
Zookeeper
使用场景
分布式协调
分布式锁
redis 实现
set nx 命令
redlock 算法
zookeeper 实现
创建临时节点，监听通知机制
顺序节点实现
配置信息管理
HA 高可用
分布式搜索引擎
es的分布式架构原理
es 中的术语
index
相当于 mysql 中的一张表
type
一个 index 中可以有多个 type，每个 type 字段有略微差别
mapping
相当于 Mysql 中表结构定义
document
相当于 Mysql 中的每行数据
field
相当于 Mysql 中每个字段的值
es 写入数据的工作原理
es 在数据量很大的情况下如何提高查询性能
提高 filesystem cache 利用率
数据预热
冷热分离
document 模型设计
分页性能优化
如果类似于 APP 推荐商品不断下拉使用 scrool API
es 生产集群部署架构是什么，每个索引数据量？每个索引有多少分片
5 台机器，每台机器 6 核 64G
日增量 2000w 条，大约 500MB，每月大概是 6 亿，15G，目前已经差不多几个月，100G
5 个索引，每个索引数据量大概 20G，每个索引分配 8 个 shard
0 条评论
下一页
