如果 DateTime.Now 不够好怎么办？

Question

好的，问题就在这里。 我们将 CQRS 与 Event Sourcing 结合使用，并且我们在聚合实例的每个提交序列中使用事件流。 每个流都保留其各自的创建日期，但问题是所有这些都发生得太快了，这意味着一些聚合事件流，它们是某些过程（注册、通知等）的一部分，出来了与完全相同的日期。 因此，当我们必须重播事件时，按创建日期对流进行排序不起作用，因为存在依赖于时间的事件流，但它们发生的速度太快以至于看起来它们是并行发生的（意味着我们使用了 DateTime.UtcNow 和日期等于纳秒）。

对于那些不知道 CQRS 或事件溯源是什么的人

假设您有一个资源列表，并且每个项目都有其创建日期。 了解 List 中项目的创建顺序至关重要。 请记住，有多个线程在列表中创建和添加项目。 问题是，当一个线程必须在列表中创建和添加两个项目时，它们的创建日期匹配，你不能按日期正确排序。 顺便说一句，我的电脑上的电脑很重要 DateTime.Now 不等于服务器上的 DateTime.Now。 实际上在同事 pcadding 25000 次 DateTime.Now 到列表结果列表的第一个和最后一个元素等于纳秒（完全匹配）

Answer 1

时间戳是一个有用的元数据。 正如您所发现的，它不是一个可靠的排序标准。 想象一下你在你的机器上想出了一些解决方案，但现在必须使用两台机器？ 你能保持他们的时钟在一纳秒内同步吗？ 少？

在事件溯源中，典型的保证只是事件在单个流中排序，例如一个聚合。 无论如何，这是您的交易保证。 为什么不使用整数来跟踪流中每个事件的序列？ 您的聚合可以生成它，因为它一直在跟踪所有事件。

如果要跨流排序，则必须集中生成该序列号（带有表示的耦合），或者接受多个流的多次读取并不总是以相同顺序返回事件，仅返回一个流中的事件应该排序。

Answer 2

您可以通过调用 Windows API 的QueryPerformanceCounter()获得一个准确的数字，您可以将其用作时间戳，这应该会以非常高的分辨率为您提供线程之间的一致值。

当然，这只会为您提供与一台特定计算机相关的值； 如果要比较在两台不同计算机上创建的时间戳，则不能使用它。

但是，请注意这一点（来自 Windows API 文档）：

在多处理器计算机上，调用哪个处理器无关紧要。 但是，由于基本输入/输出系统 (BIOS) 或硬件抽象层 (HAL) 中的错误，您可能会在不同的处理器上获得不同的结果。

（我自己没有在任何硬件上遇到上述错误。）

您可以通过 C# 获取性能计数器，如下所示：

public long PerformanceCounter()
{
    long result;
    QueryPerformanceCounter(out result);
    return result;
}

[DllImport("kernel32.dll", SetLastError=true)]
static extern bool QueryPerformanceCounter(out long lpPerformanceCount);