java - Java 中的分布式序列 ID(长)生成器 - 有人可以验证此设计是否正确吗？

Question

要求:一个可以在分布式环境(多个 JVM)中工作的序列 ID(长)生成器。每个 JVM 上将有多个线程工作。

解决方案:我们有一个集中的持久键值存储。但是我们不想为每个传入请求都进行远程调用，所以我们想到从这个集中式键值存储中获取一批序列 ID 并保存在本地 JVM 中，然后使用它。

Key Value Store:这是我们的集中键值存储，我们在其中保存一个对象 SEQUENCE_ID 和一个 Long 值。我们这个key-value存储有一个通过版本号来控制并发更新的特性。

BatchRetriever:执行以下操作:

1. 从键值存储中获取 SEQUENCE_ID 的当前值
2. 将批量大小添加到检索值
3. 更新SEQUENCE_ID的新值

多个线程可能会尝试执行此操作，因此所有这 3 个步骤将作为单个原子工作执行。我们使用此键值存储的版本号功能来控制此并发更新。

SequenceHolder:一种基于队列的数据结构，用于保存一批序列 ID。

SequenceObserver:一个观察者(通过 Observer 设计模式实现)可以检查 SequenceHolder 的大小是否下降到阈值，它将使用 BatchRetriever 检索下一批。

如果有人可以验证此设计并提出更好的建议，我们将不胜感激。

~NN

Answer 1

这些都是很好的方法。

一个更简单的解决方案可能是使用共享内存。这具有 AtomicLong 的性能，同时在同一台机器上跨进程共享。

import net.openhft.lang.io.DirectBytes;
import net.openhft.lang.io.MappedStore;

import java.io.File;
import java.io.IOException;
import java.nio.channels.FileChannel;

public class CounterExampleMain {
    static volatile long id;

    public static void main(String... ignored) throws IOException {
        int counters = 128;
        int repeats = 100000;

        File file = new File(System.getProperty("java.io.tmpdir") + "/counters");
        MappedStore ms = new MappedStore(file, FileChannel.MapMode.READ_WRITE, counters * 8);
        DirectBytes slice = ms.bytes();

        long start = System.nanoTime();
        for (int j = 0; j < repeats; j++) {
            for (int i = 0; i < counters; i++) {
                id = slice.addAtomicLong(i * 8, 1);
            }
        }
        long time = System.nanoTime() - start;
        System.out.printf("Took %.3f second to increment %,d counters, %,d times, last id=%,d%n",
                time / 1e9, counters, repeats, id);
        ms.free();
    }
}

每次我在我的笔记本电脑上运行它，我得到

Took 0.252 second to increment 128 counters, 100,000 times, last id=100,000
Took 0.267 second to increment 128 counters, 100,000 times, last id=200,000
Took 0.255 second to increment 128 counters, 100,000 times, last id=300,000

如您所见，这非常便宜，每次增量平均约 25 ns，并且在程序运行之间持续存在。它也是线程安全的，可以在 JVM 之间共享。

顺便说一句，在一个满足的示例中，多个线程正在更新相同的计数器，我预计接近 50 ns。

我使用的库是

<dependency>
    <groupId>net.openhft</groupId>
    <artifactId>lang</artifactId>
    <version>6.4.8</version>
</dependency>