分布式服务问题总结

为什么要把系统分成分布式?

服务独立自治

dubbo的简单流程

provider注册服务到注册中心

consumer订阅服务从注册中心,consumer从注册中心获取对应服务的ip+端口号 通过代理负载均衡调用响应的接口

consumer和provider异步通知检测中心

注册中心挂掉之后还能提供服务吗 ?

注册信息会缓存到本地,所以注册中心挂掉用可以继续使用

dubbo支持的通信协议?

dubbo协议

长连接/异步nio/hession序列化协议 由于是长连接所以数据量比较大的时候会阻塞 数据量小的时候支持高并发

hession/rmi

短连接

http

json序列化

dubbo支持哪些负载均衡,

随机分发

轮询

性能弱的分到请求更少

一致性hash

集群容错

发送失败转发到其他机器去

发送失败报错

发送失败忽略

发送失败定时重试

并行调用多台机器

调用所有的机器一遍

动态代理策略

默认使用javassist动态字节码生成的

dubbo spi思想是什么?

spi是接口有多个实现的时候 具体是使用哪个实现呢?

在指定目录下找到文件 查找对应的实现类配置等

可以自己写个jar包,在META-INF文件夹中写一个接口同名的文件,文件中写好实现类配置然后在dubbo中配置上自己的key即可

降级处理

使用dubbo mock设置为true 重写降级服务 调用超时就可以调用

分布式系统接口幂等性问题?

条件1: 必须有一个唯一标识

条件2: 处理完请求之后必须记录一下这个标识已经处理过了  比如mysql以orderid作为唯一主键,扣款之前插入一条支付流水,成功才能扣款

分布式服务接口如何保证顺序性?

一致性hash 同样id的数据发送到同一台机器,如果服务是多线程的,就创建队列相同id发送到同一个队列 单线程处理  不能保证100%顺序性

要想保证百分百顺序性 得使用分布式锁+顺序标识 去判断是否轮到自己执行不是的话释放锁 

设计一个rpc架构?

注册中心 使用zookeeper 保存着provider的ip+端口号等

消费者从注册中心获取对应的服务信息,使用hession或者java等序列化对象

消费者代理对象去实现负载均衡功能,调用服务提供者,在返回信息

 异步发送调用信息到检测中心

zookeeper使用场景?

1. 分布式服务协调

 A系统执行完之后在zookeeper注册一个监听器,B系统执行完之后修改监听器值,A得到通知根据数据选择重发或者完成等

2. 分布式锁

3. 保存元数据/配置数据管理

4. 基于临时节点实现HA高可用

redis分布式锁跟zookeeper分布式锁区别?

 zookeeper作为分布式锁的用法是:

节点1去获取锁成功,节点2去获取锁失败注册一个监听事件,当节点1释放锁的时候收到通知,再去获取锁

1. 节点1尝试去zookeeper创建临时节点 加锁成功

2. 节点2尝试创建同名节点 失败就对这个临时节点注册监听器

3. 节点1删除临时节点释放锁 zookeeper通知节点2这个节点被删除了锁释放掉了

4. 节点2去创建锁

6. 断开连接的临时节点会把自动删掉

redis跟zookeeper对比分布式锁哪个好?


redis还是不完全安全

分布式session是怎么实现的?


在tomcat配置文件中配置 redisSessionManager tomcat会将session 存储在redis中

spring+redis  通过springsession直接写入redis

分布式事务?

两阶段提交

第一阶段:事务管理器  联系着多个子系统 询问多个系统是否可以执行

第二阶段: 所有子系统开始提交

适用于一个系统调节多个库 绝对不适用高并发  现在微服务不允许一个服务操作多个库 没法治理

tcc

锁定资源

执行

补偿

用的也很少,对代码有侵入 需要写大量的补偿代码 

适用于核心业务 强一致性 金钱业务

本地消息表

A系统先执行a业务 成功后插入消息到消息表,然后发送消息到mq

B系统获取到消息,先插入消息表避免重复消费,然后在执行业务 成功之后更新B和A系统的消息表

A系统会重复扫描A系统的消息表 有未完成的会重新发送消息到mq中

缺点是:依赖本地消息表 不适用高并发

可靠消息最终一致性方案


A系统发送一个消息到MQ中,如果发送失败就不执行

发送成功就执行本地事务,如果执行成功就通知mq可以被消费,如果失败就回滚

B系统接到消息开始执行,成功就发送ack 失败会重复执行直到成功

MQ会定时询问prepared的消息是否执行成功了根据状态处理消息

最大努力通知


A系统发送消息到mq,最大努力通知系统负责 调用B系统 失败的话负责重试 重试N次后记录日志

原文地址:https://www.cnblogs.com/isnotnull/p/14897551.html