分布式服务问题总结
为什么要把系统分成分布式?
服务独立自治
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次后记录日志
