昆仑山上一棵草

在进行发送到其他节点的过程中，RAFT协议中CURINDEX就转换为FILEID + PAGEID, 从一个变量变成两个变量；同理 LAST INDEX 也是一样的。比较关系要发生变化，从单值比较变化为多值比较，比较的规则也有变化。其他NODE的进行同步的过程，需要特定的NODEID +FILEID+PAGEID, 也是通过 LOGSVR SERVICE 发消息给 KV TASK, 然后获得FIFO对应的BUFFER数据。此时RAFT TASK需要记录需要节点的路径信息，也是对应关系，有两种处理方式，一

设计中存在两个PAGE空间，一个是RAFTID 本身对应的空间，一个是进程间通讯的共享空间，目前没有找到统一的办法来处理，感觉还是需要两个，在KV进程执行慢的情况下，有两级的缓存设计。对应关系是RAFTID – LOGID – FD + SHAREMEM,如果操作进程间的FIFO, 必须任何时刻都是同一任务，不能多个，目前的FIFO设计是一对一无锁设计模式。通过对应关系来保证是同一个任务。也就是说RAFTSVR任务可以操作FIFO， 设计中LOGSVR的任务主要是SOCKET通讯和消息转发（...

RAFT系统设计

数据库LOG进程中设计RAFTSVR模块，专门进行LOG的复制。RAFTSVR中设置一个任务，用于进行与RAFT进程的通讯，包含连接，传递共享内存句柄，传递消息。同时提供进行共享内存写入接口，读取接口。运行过程如下：LOG的RAFTSVR模块初始化后，通过SOCKET通讯连接 RAFT进程，成功连接后，传输共享内存句柄。传递当前FILEID + PAGEID给RAFT进程。如此时RAFT进程为LEADER的情况下，LOG进程就是主LOG，有LOGSVR模块输出PAGE内容到共享区，并记录最新发出的FI.

对应网络数据报文粘包的处理，一个PACKET处理到后面，发现数据报文不完整，需要和后面的数据报文进行合并处理，如果没有数据报文的缓存的话，简单的做法就是将此PACKET的剩余数据拷贝到要接收新报文的缓存中，接收的指针向后调，相当于新接收的报文追加到新开始的完整报文中，此种办法处理比较简单。如果数据报文有多个缓存的情况下，更是简单，判断结尾是否需要跨数据包，直接进行跳到对应的下一个数据包操作。...

多路处理程序中，数据处理需要分到不同的任务中进行，有四种模式，一对一的情况，一对多的情况，多对多的情况，多对一的情况。比如网络通讯模块设计有多个任务，业务模块也设计多个任务，从网络过来的数据从任何SOCKET都可以进入的不同的SOCKET TASK中，数据要发给不同的业务模块，一个SOCKET的数据要发给不同的业务模块，一个SOCKET TASK有多个SOCKET处理，这就是典型的多对多的情况。大数据处理的过程中，这是常有的使用场景。通过设计PIPELINE，将数据的对应关系单独处理。可以进行分解和合并

对应中间的数据链路如没有办法知道有多少空间可以发送的情况，需要建立发送缓存区和接收缓存区，发送方都有可能PUSH不进数据到其中，所以要进行发送缓存区的设置，同时进行水线控制，过水线通过其他可靠链路发消息给对方，要求加快处理。发送方缓存满，停止操作。接收方接收数据采用定时+消息触发的方式，这里为何不说轮询+中断的方式，应为描述更接近实现方式，轮询方式在多任务情况下，需要让渡处理时间给其他任务，不能一直循环POLL的数据，即使没有数据可POLL的情况下，任务可以让渡处理时间。这有一个极限的情况，如果发送方高

Raft group 包含多个RAFT ID, 在协议中应该定义GROUP ID 和RAFT ID，以便进行区别。每一个RAFT ID 包含多个NODE ID， NODE ID对应一个IP +PORT。数据结构是一对多的关系。每一个NODE都需要一个唯一的ID号，如何在开机时确定这个ID号？节点ID号，可以通过将IP ADDRESS转换为整数，此整数作为节点ID号，IP地址相同的情况下，可以通过增加PORT号，IPADDRESS +PORT 64位代表一个节点ID号。RAFT GROUP的数据进行组