分布式专题

Posted 2023-02-13 曾鸿发

雪花算法的原理

第一位符号位固定为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等多种模式，底层都是基于两阶段提交理论来实现的