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机器成为了主节点，自动将自己设置为备用节点。

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机器成为了主节点，自动将自己设置为备用节点。