分布式专题

Posted 曾鸿发

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式专题相关的知识,希望对你有一定的参考价值。

雪花算法的原理

第一位符号位固定为0,41位时间戳,10位workld,12位序列号,位数可以有不同实现
优点:

每个毫秒值包含的ID值很多,不够可以变动位数来增加,性能佳 (依赖workld的实现)。.时间戳值在高位,中间是固定的机器码,自增的序列在低位,整个ID是趋势递增的。0能够根据业务场景数据库节点布置灵活调整bit位划分,灵活度高。

缺点:
强依赖于机器时钟,如果时钟回拔,会导致重复的ID生成,所以一般基于此的算法发现时钟回拨,都会抛异常.
处理,阻止ID生成,这可能导致服务不可用。

为什么Zookeeper可以用来作为注册中心

可以利用Zookeeper的临时节点和watch机制来实现注册中心的自动注册和发现,另外Zookeeper中的数据都是存在内存中的,并且Zookeeper底层采用了nio,多线程模型,所以Zokeeper的性能也是比较高的,所以可以用来作为注册中心,但是如果考虑到注册中心应该是注册可用性的话,那么Zookeeper则不太合适,因为Zookeeper是CP的,它注重的是一致性,所以集群数据不-致时,集群将不可用,所以用Redis、Eureka、Nacos来作为注册中心将更合适。

数据库实现分布式锁的问题及解决方案

利用唯一约束键存储key,insert成功则代表获取锁成功,失败则获取失败,操作完成需要删除锁问题:
非阻塞,锁获取失败后没有排队机制,需要自己编码实现阻塞,可以使用自旋,直到获取锁;
不可重入,如果加锁的方法需要递归,则第二次插入会失败,可以使用记录线程标识解决重入问题;
死锁,删除锁失败、则其他线程没办法获取锁,可以设置超时时间、使用定时任务检查.
数据库单点故障,数据库高可用。

数据一致性模型有哪些

强一致性:当更新操作完成之后,任何多个后续进程的访问都会返回最新的更新过的值,这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。根据 CAP 理论,这种实现需要牺牲可用性。
弱一致性: 系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。用户读到某一操作对系统数据的更新需要一段时间,我们称这段时间为“不一致性窗口”。
最终一致性:最终一致性是弱一致性的特例,强调的是所有的数据副本,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。到达最终一致性的时间 ,就是不一致窗口时间,在没有故障发生的前提下,不一致窗口的时间主要受通信延迟,系统负载和复制副本的个数影响

最终一致性模型根据其提供的不同保证可以划分为更多的模型,包括因果一致性和会话一致性等。

因果一致性: 要求有因果关系的操作顺序得到保证,非因果关系的操作顺序则无所谓。
进程 A 在更新完某个数据项后通知了进程 B,那么进程 B 之后对该数据项的访问都应该能够获取到进程A更新后的最新值,并且如果进程 B 要对该数据项进行更新操作的话,务必基于进程 A 更新后的最新值。
在微博或者微信进行评论的时候,比如你在朋友圈发了一张照片,朋友给你评论了,而你对朋友的评论进行了回复,这条朋友圈的显示中,你的回复必须在朋友之后,这是一个因果关系,而其他没有因果关系的数据,可以允许不一致。
会话一致性:将对系统数据的访问过程框定在了一个会话当中,约定了系统能保证在同一个有效的会话中实现“读己之所写”"的一致性,就是在你的一次访问中,执行更新操作之后,客户端能够在同一个会话中始终读取到该数据项的最新值。实际开发中有分布式的 Session 一致性问题,可以认为是会话一致性的一个应用。

什么是分布式事务?有哪些实现方案?

在分布式系统中,一次业务处理可能需要多个应用来实现,比如用户发送一次下单请求,就涉及到订单系统创建订单、库存系统减库存,而对于一次下单,订单创与减库存应该界要同时成功或同时失败的,但在分布式系统中,如里不做处理,就很有可能出现订单创建成功,但界减库存失败,那么解决这类问题,就需要用到分布式事务。常用解决方案有:
1.本地消息表:创建订单时,将减库存消息加入在本地事务中,一起提交到数据库存入本地消息表,然后调用库存系统,如果调用成功则修改本地消息状态为成功,如果调用库存系统失败,则由后台定时任务从本地消息表中取出未成功的消息,重试调用库存系统
2.消息队列:目前RocketMQ中支持事务消息,它的工作原理是:
a.生产者订单系统先发送一条half消息到Broker,half消息对消费者而言是不可见的;
b.再创建单,根据创建订单成功与否,向Broker发送commit或rollback;
c 并且生产者订单系统还可以提供Broker回调接口,当Broker发现一段时间half消息没有收到任何操作命令,则会主动调此接口来查询订单是否创建成功;
d.一旦half消息commit了,消费者库存系统就会来消费,如果消费成功,则消息销毁,分布式事务成功结束;
e.如果消费失败,则根据重试策略进行重试,最后还失败则进入死信队列,等待进一步处理;
3.Seata:阿里开源的分布式事务框架,支持AT、TCC等多种模式,底层都是基于两阶段提交理论来实现的

以上是关于分布式专题的主要内容,如果未能解决你的问题,请参考以下文章

你敢信?清华毕业大牛竟然用了20张知识图谱就把大数据给讲完了

58技术沙龙 | 第十六期 分布式存储系列专题

「分布式系统理论」系列专题

Redis专题(分布式锁)

分布式事务专题-基本概念

分布式事务专题-基本概念