在性能测试场景中,生成全局唯一标识符(GUID)是一个常见的需求,主要用于标识每个请求或者事务,以便于追踪和分析。这是因为在性能测试中，需要对系统的各个功能进行测试，而每个功能都需要有一个唯一的标识来区分。如果不使用全局唯一标识，则可能会出现重复标识的情况，导致测试结果不准确。

相信对于性能测试er来讲这些并不陌生，特别在并发场景中使用各类的解决方案。我最近在研究 Go 语言线程安全问题的时候也被其他人问到了。所以打算单独写一写唯一标识的主题，本来打算用一篇文章解决，但是在实践中方案概述、方案实践以及性能对比几个部分，内容着实有点多。所以分成了上下两篇，本篇讲述几种常见方案的概述和代码实践，下一期我会分享几种方案的性能。

UUID(Universally Unique Identifier)

UUID（通用唯一标识符）是一种标准化的用于标识信息的方法。通常用于分布式系统中的唯一标识，以防止不同系统中的数据重复或冲突。它在数据库记录、网络通信、消息队列等方面都有广泛的应用。它是由128位二进制数表示的唯一标识符，通常以32个十六进制数字的形式表示，每四个数字之间用连字符分隔。UUID的唯一性主要基于其随机性和长度，尽管在某些情况下可能会出现重复，但重复的概率非常低。具体有多低呢，我查到资料是这么说的：每秒产生10亿笔UUID，100年后只产生一次重复的机率是50%。如果地球上每个人都各有6亿笔GUID，发生一次重复的机率是50%。。我暂时还没遇到重复的情况，各位遇到请告诉我一下概率。

由于这是个自带的包，可以使用java.util.UUID类生成UUID,例如:

1. UUID uuid = UUID.randomUUID();

2. String id = uuid.toString();

AI写代码

大概长这样 245fee40-8b24-47d3-b5e1-09a5e48a08d1。查阅资料过程中，还有多种版本的 UUID，不知道是不是都这个格式。我用的 JDK17，如果又不一样格式的，兴许版本不同导致的。

UUID的优点包括：

1、全局唯一性：UUID基于其128位的长度和随机性，可以在全球范围内保证唯一性，极大地减少了数据冲突的可能性。

2、无序性：UUID是无序的，不受时间和空间的限制，可以在任何地方、任何时间生成，不需要中心化管理。

3、高性能：生成UUID的速度非常快，几乎可以瞬间完成，不会造成系统性能瓶颈。

4、不可推测性：UUID是随机生成的，不可预测，可以有效防止信息被猜测或破解。

5、可扩展性：UUID采用128位的长度，可以灵活地扩展应用范围，适用于各种场景。
然而，UUID也存在一些缺点：

1、长度较长：UUID通常由32个十六进制数字和四个连字符组成，总共36个字符，相比其他标识符（如自增ID）长度较长，占用存储空间较大。

2、不易读：UUID是一串十六进制数字，对人类来说不够友好，不如自增ID那样直观易读。

3、不连续性：由于UUID是随机生成的，所以其生成的顺序是不连续的，不适合作为连续递增的标识符。

4、碰撞概率：虽然UUID的碰撞概率非常低，但随着数据量的增加，碰撞的可能性也会增加，需要进行适当的处理和预防。

UUID适用于需要全局唯一标识且不依赖于中心化管理的场景，但在某些情况下可能会受到长度、可读性和碰撞概率等因素的限制，需要根据具体情况进行选择和权衡。如果我们在性能测试结束后清理数据的话，可以很大程序降低 UUID 重复的概率。

Redis/Zookeeper等分布式服务生成GUID

在分布式系统中,能够生成全局唯一ID是一个常见且重要的需求。全局唯一ID不仅可以用于标识分布在不同节点上的数据记录,还可以用于追踪分布式事务、消息队列等场景。传统的基于数据库自增序列或UUID等方式无法满足分布式环境下的需求,因此需要借助分布式服务来实现。

利用Redis的INCR命令可以实现一个简单的分布式ID生成器。Redis是一个高性能的内存数据库,它提供了原子操作命令INCR用于对键值进行自增操作。我们可以在Redis中设置一个全局的键,每次调用INCR命令即可获取一个唯一的ID值。由于Redis是单线程处理命令,因此可以确保获取到的ID是全局唯一的。这种方式实现简单,但需要注意Redis的可用性和性能问题。

另一种方式是利用 Zookeeper 的有序临时节点特性。Zookeeper是一个分布式协调服务,它允许客户端创建有序的临时节点,节点名称是一个递增的计数器。我们可以在Zookeeper上创建一个根节点,每个客户端在该节点下创建一个有序临时节点,临时节点的名称就是一个全局唯一的ID。这种方式相对复杂,但可靠性和可用性更高,适合于关键任务型系统。

这种方式最大的缺点就是需要N多次的网络通信，即使强如 Redis 也很难提供强大的性能，所以直接再次直接放弃了。对于性能要求不甚高的场景来说还是非常好用的。同样地我在查阅资料中发现也有使用 MySQL 递增主键实现的，性能就更差了，绝对不推荐。

雪花算法

雪花算法（Snowflake）是一种用于生成分布式系统中全局唯一的ID的算法。它由Twitter公司设计，采用了时间戳、机器ID和序列号等信息，结合位运算的方式生成64位的唯一ID。其中，时间戳部分用于保证ID的唯一性和递增性，机器ID部分用于标识不同的机器，序列号部分用于解决同一毫秒内并发生成ID时的冲突。雪花算法具有高效、高性能、高可用等特点，被广泛应用于分布式系统中的ID生成。

雪花算法很大程度上弥补了 UUID 的不足，而且使用非常灵活，几十行代码即可完成，还能够根据实际场景进行定制化，受到了越来越多码农的喜欢。这里我分享一个简单的例子：

1. package com.funtester.utils;

2. public class SnowflakeUtils {

3. private static final long START_TIMESTAMP = 1616489534000L; // 起始时间戳，2021-03-23 00:00:00

4. private long datacenterId; // 数据中心ID

5. private long workerId; // 机器ID

6. private long sequence = 0L; // 序列号

7. private static final long MAX_WORKER_ID = 31L;// 机器ID最大值

8. private static final long MAX_DATA_CENTER_ID = 31L;// 数据中心ID最大值

9. private static final long SEQUENCE_BITS = 12L;// 序列号位数

10. private static final long WORKER_ID_SHIFT = SEQUENCE_BITS;// 机器ID左移位数

11. private static final long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_SHIFT;// 数据中心ID左移位数

12. private static final long TIMESTAMP_LEFT_SHIFT = DATA_CENTER_ID_SHIFT + DATA_CENTER_ID_SHIFT;// 时间戳左移位数

13. private static final long SEQUENCE_MASK = ~(-1L << SEQUENCE_BITS);// 序列号掩码

14. private long lastTimestamp = -1L;

15. public SnowflakeUtils(long datacenterId, long workerId) {

16. if (datacenterId > MAX_DATA_CENTER_ID || datacenterId < 0) {

17. throw new IllegalArgumentException("Datacenter ID can't be greater than " + MAX_DATA_CENTER_ID + " or less than 0");

18. }

19. if (workerId > MAX_WORKER_ID || workerId < 0) {

20. throw new IllegalArgumentException("Worker ID can't be greater than " + MAX_WORKER_ID + " or less than 0");

21. }

22. this.datacenterId = datacenterId;

23. this.workerId = workerId;

24. }

25. /**

26. * 获取下一个ID

27. * * @return

28. */

29. public synchronized long nextId() {

30. long timestamp = System.currentTimeMillis();

31. if (timestamp < lastTimestamp) {

32. throw new RuntimeException("Clock moved backwards. Refusing to generate id for " + (lastTimestamp - timestamp) + " milliseconds");

33. }

34. if (lastTimestamp == timestamp) {

35. sequence = (sequence + 1) & SEQUENCE_MASK;

36. if (sequence == 0) {

37. timestamp = nextMillis(lastTimestamp);

38. }

39. } else {

40. sequence = 0L;

41. }

42. lastTimestamp = timestamp;

43. long l = ((timestamp - START_TIMESTAMP) << TIMESTAMP_LEFT_SHIFT) | (datacenterId << DATA_CENTER_ID_SHIFT) | (workerId << WORKER_ID_SHIFT) | sequence;

44. return l & Long.MAX_VALUE;

45. }

46. /**

47. * 获取下一个时间戳

48. *

49. * @param lastTimestamp

50. * @return

51. */

52. private long nextMillis(long lastTimestamp) {

53. long timestamp = System.currentTimeMillis();

54. while (timestamp <= lastTimestamp) {

55. timestamp = System.currentTimeMillis();

56. }

57. return timestamp;

58. }

59. }

60. ``

61. 使用的方法如下：

62. ```go

63. public static void main(String[] args) {

64. SnowflakeUtils snowflake = new SnowflakeUtils(1, 1); // 创建雪花算法实例，数据中心ID为1，机器ID为1

65. for (int i = 0; i < 5; i++) {

66. System.out.println("Next ID: " + snowflake.nextId());

67. }

68. }

结果大概长这个样子：

1. Next ID: 3282842653393162240

2. Next ID: 3307893926320410624

3. Next ID: 3307893926320410625

4. Next ID: 3307893926320410626

5. Next ID: 3307893926320410627

AI写代码

我在 com.funtester.utils.SnowflakeUtils#nextId 方法的最后一行，加上了 l & Long.MAX_VALUE 为了获取一个正的值。

线程独享变量

在非并发场景当中，我们要想获取一个全局唯一的标识符，最简单的就是来一个 i++ ，但这样并不能保障并发场景中的线程安全。尽管如此，我们依旧可以通过之前分享过的 将共享变独享 的思路改造一下，将每一个线程都分配一个 int i ，然后在线程内 i++ 保障数值的唯一性。然后再给每一个线程进行唯一性标记，这个在之前分享线程工厂类时候提到过。如果遇到分布式场景，抄袭一下前面成熟框架的方法，增加唯一的机器码标识即可。

下面是我使用的单机版本代码：

1. // 创建threadlocal对象

2. static ThreadLocal<Integer> threadLocal = new ThreadLocal<Integer>() {

3. @Override

4. protected Integer initialValue() {

5. return 0

6. }

7. }

8. public static void main(String[] args) {

9. setPoolMax(3)

10. for (int i = 0; i < 10; i++) {

11. fun {

12. increase()// 增加1

13. System.out.println(Thread.currentThread().getName() + " threadLocal.get() = " + threadLocal.get());// 打印threadLocal值

14. }

15. }

16. }

17. /**

18. * 增加1

19. * @return

20. */

21. static def increase() {

22. threadLocal.set(threadLocal.get() + 1)

23. }

输出结果长这个样子：

1. F-3 threadLocal.get() = 1

2. F-2 threadLocal.get() = 1

3. F-1 threadLocal.get() = 1

4. F-2 threadLocal.get() = 2

5. F-1 threadLocal.get() = 2

6. F-3 threadLocal.get() = 2

7. F-2 threadLocal.get() = 3

8. F-1 threadLocal.get() = 3

9. F-3 threadLocal.get() = 3

10. F-2 threadLocal.get() = 4

基本是实现了设计需求。缺点就是 java.lang.ThreadLocal 可能会导致内存溢出。这一点在性能测试当中可以忽略，因为用例执行完之后，JVM自然也是要关闭的，如果是单 JVM 的性能测试服务，可以将 java.lang.ThreadLocal 对象设计成类成员属性规避内存溢出的问题。

线程共享变量

这个思路就简单了：新建一个全局线程安全的变量，每次获取一个值之后，安全地递增1，这样一下子就解决了所有问题，是所有方案里面最简单使用的。方案的代码

演示代码如下：

1. // 定义全局变量,用于线程安全递增计数

2. static AtomicInteger index = new AtomicInteger(0)

3. public static void main(String[] args) {

4. setPoolMax(3)

5. for (int i = 0; i < 10; i++) {

6. fun {

7. println "递增结果: ${index.incrementAndGet()}"

8. }

9. }

10. }

输出结果：

1. 递增结果: 2

2. 递增结果: 3

3. 递增结果: 1

4. 递增结果: 4

5. 递增结果: 5

6. 递增结果: 6

7. 递增结果: 7

8. 递增结果: 8

9. 递增结果: 9

10. 递增结果: 10

相信个性化的方案不止一种，如果你也有一些有趣的方案，欢迎一起交流分享。

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。