分布式存储
分布式锁的利用场景是什么？有哪些实现方案？
在单体架构中，多个线程都是属于同一个进程的，以是在线程并发实行时，遇到资源竞争时，可以利用ReentrantLock、synchronized等技能来作为锁，来控制共享资源的利用。
而在分布式架构中，多个线程是可能处于不同进程中的，而这些线程并发实行遇到资源竞争时，利用ReentrantLock、synchronized等技能是没办法来控制多个进程中的线程的，以是需要分布式锁，意思就是，需要一个分布式锁生成器，分布式系统中的应用步伐都可以来利用这个生成器所提供的锁，从而达到多个进程中的线程利用同一把锁。
目前主流的分布式锁的实现方案有两种：
1、zookeeper：利用的是zookeeper的临时节点、顺序节点、watch机制来实现的，zookeeper分布式锁的特点是高一致性，因为zookeeper保证的是CP，以是由它实现的分布式锁更可靠，不会出现紊乱
2、redis：利用redis的setnx、lua脚本、消费订阅等机制来实现的，redis分布式锁的特点是高可用，因为redis保证的是AP，以是由它实现的分布式锁可能不可靠，不稳定（一旦redis中的数据出现了不一致），可能会出现多个客户端同时加到锁的环境
什么是分布式事务？有哪些实现方案？
分布式事务是指在分布式系统中，由多个微服务或数据库到场的事务，这些到场者可能分布在不同的服务器或数据存储中。与单体应用中的传统事务不同，分布式事务需要确保在多个系统或服务之间的一致性、可靠性和原子性，即要保证在多方到场的事务中，要么全部成功，要么全部失败。
什么是ZAB协议
ZAB协议是Zookeeper用来实现一致性的原子广播协议，该协议描述了Zookeeper是如何实现一致性的，分为三个阶段：
- 领导者选举阶段：从Zookeeper集群中选出一个节点作为Leader，所有的写请求都会由Leader节点来处置惩罚
- 数据同步阶段：集群中所有节点中的数据要和Leader节点保持一致，如果不一致则要举行同步
- 请求广播阶段：当Leader节点接收到写请求时，会利用两阶段提交来广播该写请求，使得写请求像事务一样在其他节点上实行，达到节点上的数据及时一致
但值得留意的是，Zookeeper只是只管的在达到强一致性，现实上仍然只是终极一致性的。
为什么Zookeeper可以用来作为注册中央
可以利用Zookeeper的临时节点和watch机制来实现注册中央的自动注册和发现，另外Zookeeper中的数据都是存在内存中的，并且Zookeeper底层采用了nio，多线程模型，以是Zookeeper的性能也是比较高的，以是可以用来作为注册中央，但是如果思量到注册中央应该是注册可用性的话，那么Zookeeper则不太合适，因为Zookeeper是CP的，它注意的是一致性，以是集群数据不一致时，集群将不可用，以是用Redis、Eureka、Nacos来作为注册中央将更合适。
Zookeeper中的领导者选举的流程是怎样的？
对于Zookeeper集群，整个集群需要从集群节点中选出一个节点作为Leader，大体流程如下：
- 集群中各个节点起首都是观望状态（LOOKING），一开始都会投票给自己，以为自己比较得看成为leader
- 然后相互交互投票，每个节点会收到其他节点发过来的选票，然后pk，先比较zxid，zxid大者获胜，zxid如果相等则比较myid，myid大者获胜
- 一个节点收到其他节点发过来的选票，经过PK后，如果PK输了，则改票，此节点就会投给zxid或myid更大的节点，并将选票放入自己的投票箱中，并将新的选票发送给其他节点
- 如果pk是平手则将接收到的选票放入自己的投票箱中
- 如果pk赢了，则忽略所接收到的选票
- 固然一个节点将一张选票放入到自己的投票箱之后，就会从投票箱中统计票数，看是否凌驾一半的节点都和自己所投的节点是一样的，如果凌驾半数，那么则以为当前自己所投的节点是leader
- 集群中每个节点都会经过同样的流程，pk的规则也是一样的，一旦改票就会告诉给其他服务器，以是终极各个节点中的投票箱中的选票也将是一样的，以是各个节点终极选出来的leader也是一样的，这样集群的leader就选举出来了
Zookeeper集群中节点之间数据是如何同步的
- 起首集群启动时，会先举行领导者选举，确定哪个节点是Leader，哪些节点是Follower和Observer
- 然后Leader会和其他节点举行数据同步，采用发送快照和发送Diff日记的方式
- 集群在工作过程中，所有的写请求都会交给Leader节点来举行处置惩罚，从节点只能处置惩罚读请求
- Leader节点收到一个写请求时，会通过两阶段机制来处置惩罚
- Leader节点会将该写请求对应的日记发送给其他Follower节点，并等待Follower节点持久化日记成功
- Follower节点收到日记后会举行持久化，如果持久化成功则发送一个Ack给Leader节点
- 当Leader节点收到半数以上的Ack后，就会开始提交，先更新Leader节点本地的内存数据
- 然后发送commit命令给Follower节点，Follower节点收到commit命令后就会更新各自本地内存数据
- 同时Leader节点还是将当前写请求直接发送给Observer节点，Observer节点收到Leader发过来的写请求后直接实行更新本地内存数据
- 最后Leader节点返回客户端写请求响应成功
- 通过同步机制和两阶段提交机制来达到集群中节点数据一致
简述zk的命名服务、配置管理、集群管理
命名服务：
通过指定的名字来获取资源或者服务地址。Zookeeper可以创建一个全局唯一的路径，这个路径就可以作为一个名字。被命名的实体可以是集群中的机器，服务的地址，或者是远程的对象等。一些分布式服务框架（RPC、RMI）中的服务地址列表，通过利用命名服务，客户端应用能够根据特定的名字来获取资源的实体、服务地址和提供者信息等
配置管理：
现实项目开发中，经常利用.properties或者xml需要配置很多信息，如数据库毗连信息、fps地址端口等等。步伐分布式摆设时，如果把步伐的这些配置信息生存在zk的znode节点下，当你要修改配置，即znode会发生变化时，可以通过改变zk中某个目录节点的内容，利用watcher关照给各个客户端，从而更改配置。
集群管理：
集群管理包括集群监控和集群控制，就是监控集群机器状态，剔除机器和加入机器。zookeeper可以方便集群机器的管理，它可以及时监控znode节点的变化，一旦发现有机器挂了，该机器就会与zk断开毗连，对应的临时目录节点会被删除，其他所有机器都收到关照。新机器加入也是雷同。
讲下Zookeeper中的watch机制
客户端，可以通过在znode上设置watch，实现及时监听znode的变化
Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时间，则服务器将这个改变发送给设置了Watch的客户端
●父节点的创建，修改，删除都会触发Watcher事件。
●子节点的创建，删除会触发Watcher事件。
一次性：一旦被触发就会移除，再次利用需要重新注册，因为每次变动都需要关照所有客户端，一次性可以减轻压力，3.6.0默认持久递归，可以触发多次
轻量：只关照发生了事件，不会告知事件内容，减轻服务器和带宽压力
Watcher 机制包括三个脚色：客户端线程、客户端的 WatchManager 以及 ZooKeeper 服务器
1 客户端向 ZooKeeper 服务器注册一个 Watcher 监听，
2 把这个监听信息存储到客户端的 WatchManager 中
3 当 ZooKeeper 中的节点发生变化时，会关照客户端，客户端会调用相应 Watcher 对象中的回调方法。watch回调是串行同步的
Zookeeper和Eureka的区别
zk：CP设计(强一致性)，目标是一个分布式的调和系统，用于举行资源的同一管理。
当节点crash后，需要举行leader的选举，在这个期间内，zk服务是不可用的。
eureka：AP设计（高可用），目标是一个服务注册发现系统，专门用于微服务的服务发现注册。
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现毗连失败，会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）
同时当eureka的服务端发现85%以上的服务都没有心跳的话，它就会以为自己的网络出了问题，就不会从服务列表中删除这些失去心跳的服务，同时eureka的客户端也会缓存服务信息。eureka对于服务注册发现来说是非常好的选择。
存储拆分后如何解决唯一主键问题
●UUID：简朴、性能好，没有顺序，没有业务含义，存在泄漏mac地址的风险
●数据库主键：实现简朴，单调递增，具有一定的业务可读性，强依赖db、存在性能瓶颈，存在暴露业务 信息的风险
●redis，mongodb，zk等中间件：增长了系统的复杂度和稳定性
●雪花算法
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
