在C/S架构中，Server端需要依赖ID来唯一标识Client，而客户端相关数据都由这个唯一标识来索引。
这个标识可以由服务端分配，也可以由客户端自行生成再注册到服务端。
服务端分配是一种中心化生成方式，可以保证唯一性。客户端自行生成方式可以采用UUID标准来生成，也可以保证唯一性。
尽管在生成方式可以保证唯一性，但是由于客户端某些特性的改变，服务端依然会出现ID冲突的场景。
比如，客户端在虚拟机中安装完成并已生成好UUID, 此时克隆虚拟机，克隆机中的客户端启动并使用原UUID与服务端通信。此时，如果服务端不使用客户端的属性进行校验，那么两个客户端在服务端就会被识别为一个客户端，从而可能造成数据混乱和覆盖。
于是，服务端需要对客户端的某些属性进行校验来检测UUID冲突，常用的属性如MAC地址，IP地址等信息。如果已经正常运行的客户端所在的机器属性发生变化时，比如，更换网卡，MAC地址发生变化，更改IP地址，由于服务端会校验这些属性，在服务端看来这些变化的属性也造成UUID冲突。
尽管都是相同的UUID，第一种情形，需要视为不同的客户端进行处理，第二种情况则需要视为同一个客户端进行处理。而单一从服务端角度是无法区分这两种情形的，需要引入人为判断，或者服务端根据业务场景提前配置好UUID冲突的处置方案。
针对这种冲突处置方案，简单梳理了一下客户端和服务端的处理流程:
客户端流程图:
控制中心流程图:
在不同场景下，可以根据实际业务需要选择需要校验的属性。
而在Linux上具体生成UUID的方法有许多，常用的方法有:
- 通过
dmidecode工具获取:
1 | [root@default ~]# dmidecode -s system-uuid |
- 从
sysfs中获取:
1 | [root@default ~]# cat /sys/class/dmi/id/product_uuid |
- 随机生成:
1 | [root@default ~]# cat /proc/sys/kernel/random/uuid |
参考: