C/S架构下UUID冲突处理方案简要说明

2022-08-11 MISC

在C/S架构中，Server端需要依赖ID来唯一标识Client，而客户端相关数据都由这个唯一标识来索引。

这个标识可以由服务端分配，也可以由客户端自行生成再注册到服务端。

服务端分配是一种中心化生成方式，可以保证唯一性。客户端自行生成方式可以采用UUID标准来生成，也可以保证唯一性。

尽管在生成方式可以保证唯一性，但是由于客户端某些特性的改变，服务端依然会出现ID冲突的场景。

比如，客户端在虚拟机中安装完成并已生成好UUID, 此时克隆虚拟机，克隆机中的客户端启动并使用原UUID与服务端通信。此时，如果服务端不使用客户端的属性进行校验，那么两个客户端在服务端就会被识别为一个客户端，从而可能造成数据混乱和覆盖。

于是，服务端需要对客户端的某些属性进行校验来检测UUID冲突，常用的属性如MAC地址，IP地址等信息。如果已经正常运行的客户端所在的机器属性发生变化时，比如，更换网卡，MAC地址发生变化，更改IP地址，由于服务端会校验这些属性，在服务端看来这些变化的属性也造成UUID冲突。

尽管都是相同的UUID，第一种情形，需要视为不同的客户端进行处理，第二种情况则需要视为同一个客户端进行处理。而单一从服务端角度是无法区分这两种情形的，需要引入人为判断，或者服务端根据业务场景提前配置好UUID冲突的处置方案。

针对这种冲突处置方案，简单梳理了一下客户端和服务端的处理流程:

客户端流程图:

控制中心流程图:

在不同场景下，可以根据实际业务需要选择需要校验的属性。

而在Linux上具体生成UUID的方法有许多，常用的方法有:

[root@default ~]# dmidecode -s system-uuid
cfba65ba-62dd-42f1-8976-8f3653de090a

[root@default ~]# cat /sys/class/dmi/id/product_uuid
CFBA65BA-62DD-42F1-8976-8F3653DE090A

[root@default ~]# cat /proc/sys/kernel/random/uuid
396fea55-23bb-4407-adf5-b527a117e8e8

Recommend