DNS协议

DNS协议其本身就是一个天然的分布式服务发现中心，通过域名映射IP，用户只需要记住域名即可访问对应的服务。

纵观Nacos、Eureka、Etcd以及Zookeeper，这些充当服务发现中心的组件，其都需要一个Client-SDK为上层应用提供根据服务名查找到一个机器IP的能力，而这就带来了一个问题，应用必须要集成这一些组件的客户端SDK，一旦组件的SDK出现问题需要升级时，就需要推动应用方的升级，这是不想见到的。而DNS协议，天然跨语言，因此Consul或者Kubernetes都选择使用DNS协议作为服务发现，直接解决了跨语言的问题。

租约机制

相比Etcd2的TTL机制，在Etcd3中实现了租约机制，也就是一个租约绑定了多个Key，这样就不再需要单独去管理每一个Key的过期事件了，化零为整的操作，降低了需要处理过期Key的服务端的开销

Raft 协议的读操作处理

Raft协议是一个强一致性协议。因此，在T1时刻发生的一个对于A数据的写操作通过Raft协议同步其他节点之后，在T2时刻发起的对A数据的读操作，一定能够读到被修改过的A的值。那么如果说按照传统的走Raft Log去实现读的话，其实是会对写操作请求有影响的，Raft协议本质是一个分布式日志复制状态机，所有的日志回放，最终都是在StateMachine里面单线程串行执行的。而实际上，读操作对应的Raft Log日志，无论它是串行还是并行，都不会对最终的数据有影响，因此，我们希望说，让Raft StateMachine尽可能的只处理涉及写操作的Raft Log，换句话说，就是我们在向Raft提交一个数据操作时，这个数据操作最好是对数据的写操作，而不是读操作。

既然说最好让StateMachine处理的Raft Log是数据的写操作，那么读请求该怎么处理？这里就要引出Raft针对读操作做出的优化了～

时间轮算法

时间轮算法简单来说就是有一个环形数组（一般我们会将数组长度设置为2^n），每一个间隔表示一个tick，然后每一个延迟任务根据延迟时间以及tick，算出来自己在哪一个solt，然后在计算自己需要几轮完整tick之后才算过期。

本次特性的前期视频分享

Nacos 1.3.0-BETA 新特性以及修改点分享

Nacos 1.3.0-BETA 特性以及功能使用文档

前话

之前实习时负责公司标签系统的重构，由于用户身上的标签是随即变化的，也会很大，因此经过方案调研后选择采用Bitmap进行存储用户身上的标签ID信息数据。但是在前几天发生高CPU问题，怎么定位都定位不到是哪一个线程出现的高CPU，后面同为实习的小伙伴利用arthas的thread -n -i命令成功定位出问题所在（我怎么没有想到它，这就是大佬和菜鸡的区别吧～）

定位

Gossip 协议

Gossip协议，也叫做流言算法，或者疫情传播协议，在这个协议当中，所有的节点的角色地位都是一样的，节点间的数据怎么同步呢？大致的步骤如下

• 随机选取周边的k个节点
• 向这k个节点进行数据广播同步
• 这k个节点再次重复刚刚的操作

因此，最终一个消息经过多轮广播之后，所有的节点都同步了此数据。

JRaft 启动流程

1
2
3
4
5
6
7
8

public synchronized Node start(final boolean startRpcServer) {
  ...
  //Adds RPC server to Server.
  NodeManager.getInstance().addAddress(this.serverId.getEndpoint());
  // 工厂方法，创建并初始化一个 Raft Node 节点，会初始化一些Raft协议中的一些配置以及相应的触发器
  this.node = RaftServiceFactory.createAndInitRaftNode(this.groupId, this.serverId, this.nodeOptions);
  ...
}

前期导读

Nacos 中的 DistroConsistencyServiceImpl 工作浅析

之前的文章说的很浅显，这次打算重头好好解析下Nacos中使用的alibaba自研的AP协议——Distro

核心代码实现

Nacos Naming 模块启动做的时数据同步