八股分布式

分布式场景

Raft

Raft 是一种更为简单方便易于理解的分布式算法，主要解决了分布式中的一致性问题。

选举

情况 1：领导人选举

情况 2：领袖挂掉情况

情况 3：出现多个候选者情况

日志复制

复制状态机

数据同步流程

日志复制原理

每一个日志条目一般包括三个属性：整数索引Log Index、任期号Term和指令Commond。

每个条目所包含的“整数索引”即该条目在日志文件中的槽位，“任期号”对应到图中就是每个方块中的数字，用于检测在不同服务器上日志的不一致问题，指令即用于被状态机执行的外部命令。

一旦领导人创建的条目已经被复制到半数以上的节点上了，那么这个条目就称为可被提交的。

从实现原理来讲，Nacos 为什么这么强？

日均 20 亿流量：携程机票查询系统的架构升级

RPC的底层原理

1、RPC框架一般使用长链接，不必每次通信都要3次握手，减少网络开销。
2、RPC框架一般都有注册中心，有丰富的监控管理。发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作协议私密，安全性较高
3、RPC 协议更简单内容更小，效率更高，服务化架构、服务化治理，RPC框架是一个强力的支撑。

具体步骤：

1. 服务消费者（client客户端）通过本地调用的方式调用服务。
2. 客户端存根（client stub）接收到请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息
   体。
3. 客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端。
4. 服务端存根（server stub）收到消息后进行解码（反序列化操作）。
5. 服务端存根（server stub）根据解码结果调用本地的服务进行相关处理。
6. 本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）。
7. 服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方。
8. 客户端存根（client stub）接收到消息，并进行解码（反序列化）。
9. 服务消费方得到最终结果。

涉及到的技术

1. 动态代理：生成Client Stub（客户端存根）和Server Stub（服务端存根）的时候需要用到java动态代理技术。
2. 序列化 在网络中，所有的数据都将会被转化为字节进行传送，需要对这些参数进行序列化和反序列化操作。目前主流高效的开源序列化框架有Kryo、fastjson、Hessian、Protobuf等。
3. NIO通信：Java 提供了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持。可以采用Netty或者mina框架来解决NIO数据传输的问题。开源的RPC框架Dubbo就是采用NIO通信，集成支持netty、mina、grizzly。
4. 服务注册中心：通过注册中心，让客户端连接调用服务端所发布的服务。主流的注册中心组件：Redis、Zookeeper、Consul、Etcd。Dubbo采用的是ZooKeeper提供服务注册与发现功能。
5. 负载均衡：在高并发的场景下，需要多个节点或集群来提升整体吞吐能力。
6. 健康检查：健康检查包括，客户端心跳和服务端主动探测两种方式。

RPC框架的零拷贝应用

Netty零拷贝主要体现在三个方面：

1、Netty的接收和发送ByteBuffer是采用DIRECT BUFFERS，使用堆外的直接内存（内存对象分配在JVM中堆以外的内存）进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果采用传统堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后写入Socket中。
2、Netty提供了组合Buffer对象，也就是CompositeByteBuf 类，可以将 ByteBuf 分解为多个共享同一个存储区域的 ByteBuf，避免了内存的拷贝。

3、Netty的文件传输采用了FileRegion 中包装 NIO 的 FileChannel.transferT o() 方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。

零拷贝带来的作用就是避免没必要的 CPU 拷贝，减少了 CPU 在用户空间与内核空间之间的上下文切换，从而提升了网络通信效率与应用程序的整体性能。

题外话：如何优化持久化？或者说如何写入磁盘更快？

1 Kafka顺序写入，而不是随机写入，所以更快一点。

2 或者说同时发消息的时候先缓存，然后批量发送等等。

3 然后就是零拷贝处理啊什么的

有了 HTTP 协议，为什么还要有 RPC ？

• 纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义 消息边界 。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。
• RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。
• 从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。 很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。
• RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP1.1 性能要更好，所以大部分公司内部都还在使用 RPC。
• HTTP2.0 在 HTTP1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。