zookeeper分布式协调
这个其实是zk很经典的一个用法,简单来说,好比你A系统发送个请求到mq,然后B系统消费。那么A系统如何知道B系统的处理结果?用zk就可以实现分布式系统之间的协调工作。A系统发送请求之后可以在zk上对某个节点的值注册个监听器,一旦B系统处理完了就修改那个节点的值,A立马就可以收到通知
分布式锁
对某一个数据连续发出两个修改操作,两台机器同时收到了请求,但是只能一台机器先执行另外一个机器再执行。那么此时就可以使用zk分布式锁,再某个目录下,比方说lock节点下创建一个节点,看自己是不是最小的,是就执行呗,不是就监听比自己次小的节点
元数据/配置信息管理
zk可以用作很多系统的配置信息的管理,比如数据库,kafka、storm等等很多分布式系统都会选用zk来做一些元苏剧、配置信息的管理,包括dubbo注册中心不也支持zk吗
HA高可用
es(选取一个master进行节点协调,primary shard、replica shard)、kafka(topic partition 1 leader,topic partition replica)、redis、dubbo都可以依赖zk来开发HA高可用机制,就是一个重要进行会做主备两个
分布式session
spring+redis
分布式事物
订单系统:TCC强一致性分布式事物
流程图生成流程文件,生成截图:最终一致性
TCC分为三个阶段:
- Try阶段:对各个服务的资源做检测以及对资源进行锁定或预留
- Confirm阶段:各个服务中执行实际的操作
- Cancel阶段:任何一个服务的执行出错,执行回滚
可靠消息最终一致性方案:
- A系统先发送一个prepared消息到mq,如果这个prepared消息发送失败那么就直接取消操作别执行了
- 如果这个消息发送成功过去了,就执行本地事物,如果成功就告诉mq发送确认消息,如果失败就钙塑mq回顾消息
- 如果发送了确认消息,那么此时B系统会接收到确认消息,然后执行本地事物
- mq会自动定时轮询所有prepared消息回调接口,一般来说这里就可以查下数据库之前本地事物是否执行,如果回滚了,那么这里就回滚吧,这个就是避免可能本地事物执行成功了,别确认消息发送失败了
- 要是系统B的失败了咋办?重试咯,自动不断重试直到成功,实在不行就B系统执行回滚操作,A系统也执行回滚操作,或者发送报警由人工来手动回滚和补偿