关于分布式系统的连环炮二

dubbo的spi是什么

Spi服务实现类接口


分布式系统怎么保证消息的顺序性?
假如一个用户发送了3个请求,如何保证这三个请求在分布式系统中的执行顺序,
首先我们为这三个请求设置唯一的id,保证这三个请求的关联性,不让这三个请求直接请求到分布式服务器,而是通过接入服务去分发这三个请求要请求到节点机器,首先我们通过dubbo的hash一致性算法将这三个请求落在一台机器上,可能这台机器是多线程执行的,那么就将这个id的请求扔到内存队列中去,让一个线程进行消费这样就保证了执行顺序的顺序性。

通过分布式锁保证执行顺序。
太过繁琐,降低了系统的吞吐量
也可以通过mq进行异步解决。

zkkeeper有哪些使用场景?
Zk是分布式系统框架

zk分布式协调场景
用户请求系统A 系统A发送一个消息到MQ,系统B监听MQ中的消息去执行,那么系统A怎么知道系统B的执行结果呢?
Zk就可以做分布式系统之间的协调工作,系统A在zk上注册一个对某个节点的值变化的监听器,当系统B执行完请请求后,系统A就可以通过zk马上知道它发送的请求的执行结果。

Zk分布式锁的场景
分布式系统下,同一个系统多台机器,同一时间只能有一台机器能够获取zk锁,
其余机器只有在获取锁机器执行完自己的业务之后才能再获取到锁。系统A没有获取到锁的机器会对这个锁注册一个监听器,当这个锁被释放掉,zk会反推给该机器获取到这把锁

Zk元数据/配置信息的管理
比如系统A部署在三台机器上,地址分别为01,02,03,三台机器都在dubbo中进行注册,dubbo会在zk中保存注册信息,同时在zk中注册一个
系统A的监听器,监听系统A的变化,调用者从dubbo拉取服务配置信息缓存到自己本地,当系统A的配置信息发生改变时,zk就可以监听到系统A
的变化,同时通知所有机器配置信息的更新。

zk高可用场景
Zk高可用,系统A部署两台机器,机器01作为主节点,机器02作为备用节点,平时所有业务都由主节点01进行处理,如果突然01宕机了,那么02机器自动提升为主节点,当01机器恢复,发现02机器成为了主节点,自动将自己设置为备用节点。




<ignore_js_op>

3.png (35.45 KB, 下载次数: 0)

<ignore_js_op>

4.png (35.08 KB, 下载次数: 0)

<ignore_js_op>

5.png (32.32 KB, 下载次数: 0)

相关推荐