NFV一种提高进程消息高可用性的方法

1.背景及概述

1.1 背景

在做NFV的过程中，由于控制面进程被放置到不同虚拟机中，中间可能跨越路由器，因此期间网络有可能震荡，这种情况下保证高可用性就必须有保护机制，本文正是在这种背景下的考虑。

1.2 概述

原理其实很简单，有两个原则，一是这种保护机制不能让业务感知，二是尽可能简单。

2. 详述

2.1 正常交互

（1）源进程发送消息给目的进程

（2）目的进程回应消息给源进程

注意的是这些应该封装成公共库，以便复用。

2.2 异常交互

异常交互为两个方面，一是上述msg由于震荡被丢或被严重延时，二是ack由于震荡被丢弃或被严重延时。

2.2.1 msg异常

1）被丢，需要重传，为了保证唯一，需要加入进程1的id（记为clientid）、消息id（本进程唯一，且递增，记为msgid）、发送时间send_time。此外，需要设定重传interval、次数times。这些依然可能被丢弃，则应该通知源进程，所以这里应该有一段buff，用来唯一标识源数据（建议除正常id外，包括时间戳）。

2）被延时。除重传外，上次发送的消息的应答应该丢弃。

2.2.2 ack异常

1）被丢，则msg会被重发，重发时目的进程应该重新回复，若关联数据已不存在，则由目的进程业务做相关处理（如发送删除等）。

2）被严重延时。源进程重发，目的进程不论如何要回复。

2.3 总结及综述

（1）公共库的消息应该包含clientid、msgid、send_time，并设定interval、times，提供短buff（如64字节）；

#define MAX_STORED_MSG 1000

#define MAX_BUFF_LEN 64

typedef unsigned int uint32;

typedef unsigned char byte;

typedef VOID (*send_fail_callback)(byte *user_buff);

typedef struct

{

uinit32 clientid;

uinit32 msgid;

uinit32 send_time;

byte times;

byte pad[3];

} MSG_T;

BOOL send_msg(byte *msg, uinit32 msg_len, const byte *user_buff, uinit32 user_buff_len);

（2）公共库lib有一个定时器，interval/2时间扫描重传链；

（3）发送消息挂在重传链中；

（4）若无回应，则更新发送时间后重传；

（5）若重传X次（如10次）后，回掉业务进程send_fail_callback。

（6）接收端若收到interval之前的消息，则丢弃。

（7）收到后立刻回应ack，clientid、msgid应与源消息相同，更新send_time。

（8）接收端若收到重复msg，与（6）处理相同重复回应，但要更新send_time。

（9）源端收到interval之前发送的ack，则丢弃。