Java 有现成的时钟同步解决方案吗?

发布于 2024-07-23 04:36:14 字数 611 浏览 2 评论 0原文

我们有一个大型的高性能软件系统,它由多个交互的 Java 进程(不是 EJB)组成。 每个进程可以在同一台机器上,也可以在不同的机器上。

某些事件在一个进程中生成,然后以不同的方式传播到其他进程以进行进一步处理等。

出于基准测试的目的,我们需要创建每个事件何时通过“检查点”的日志,最终组合这些日志以获得每个事件如何通过系统传播以及延迟的时间线(当然,进程切换和 IPC 添加了延迟,这没关系)。

当然,问题是时钟同步。 所以我的问题是:

1)如果所有进程都在同一台机器上,是否可以保证 currentTimeMilis 在调用时准确? ITP的误差有一定的界限吗?

2)如果某些进程可能位于不同的机器上,是否有现成的解决方案(也是免费或开源的)用于时钟同步? 我更喜欢寻找一种可以绕过操作系统(Windows 或 Linux)并直接从 Java 工作的解决方案。 我也在理想地寻找能够以微秒精度运行的东西。 我考虑过 NTP,但我不确定它是否可以通过 Java 而不是通过操作系统使用,而且我不确定它的复杂性。

3) 有没有办法确定在特定配置(或我最终使用的任何解决方案)中使用 NTP 的误差幅度,以便我可以在计算延迟时给出误差幅度?

谢谢!

We have a large high-performance software system which consists of multiple interacting Java processes (not EJBs). Each process can be on the same machine or on a different machine.

Certain events are generated in one process, and are then propagated in different ways to other processes for further processing and so on.

For benchmarking purposes, we need to create a log of when each event passed through a "checkpoint", eventually combine these logs to obtain a timeline of how each event propagated through the system and with what latency (of course, process switching and IPC adds latency, which is ok).

The problem, of course, is clock synchronization. So here are my questions:

1) If all processes are on the same machine, is it guaranteed that currentTimeMilis would be accurate at the time of call? Is there some bound on the errors of ITP?

2) If some processes may be on different machines, is there an off-the-shelf solution (that is also free or open-source) for clock synchronization? I am preferably looking for a solution that may bypass the operating system (Windows or Linux) and work straight from Java. I am also ideally looking for something that can operate at microsecond accuracy. I've thought about NTP, but I'm not sure if it's available via Java rather than through the OS, and I am not sure about its complexity.

3) Is there a way to determine the margin of error in using NTP in a particular configuration (or of any solution I end up using) so that I can give a margin of error on our calculation of the latency?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

我喜欢麦丽素 2024-07-30 04:36:14

对于分布式编程,时钟同步通常是不够的。 您可能想要构建一个逻辑时间框架(例如 Lamport 或矢量时钟或 Singhal-Kshemkalyani 方法......并且还有更多方法可以保持跨机器的因果关系同步)。 您的选择通常取决于应用程序和事件之间所需的因果关系。

时钟同步以确保并发事件保持正确的顺序。 除了保持系统时钟同步之外,还有其他方法可以做到这一点……除非它们共享一个共同的物理时钟……这是相当棘手的。

在NTP误差范围方面,有一些解决方案:

我的建议:

阅读:
分布式计算:原理、算法和系统

特别是:第 3 章,逻辑时间

编辑

除了 Cheeso 的帖子,我发现

http://www.uniforum.org/publications/ufm/apr96/opengroup.html

http://sourceforge.net/projects/freedce

可能存在 DCE Java 绑定。

With distributed programming, clock synchronisation is often not enough. you might want to build a logical time framework (such as the Lamport or vector clocks or Singhal-Kshemkalyani methods ... and there are loads more to keep causality in sync across machines). Which you choose often depends on the application and required causality between events.

Clocks are sync'd to ensure concurrent events are kept in the right sequential order. There are other ways to do this than keeping the system clock synchronized ... which unless they share a common physical clock ... is quite tricky.

In terms of NTP error margin, there are solutions:

my recommendation:

Read:
Distributed Computing: Principles, Algorithms and Systems

Especially: Chapter 3, logical time

Edit

Further to Cheeso's post, I found

http://www.uniforum.org/publications/ufm/apr96/opengroup.html

http://sourceforge.net/projects/freedce

There maybe DCE Java bindings out there.

别闹i 2024-07-30 04:36:14

我真的只想使用 NTP。 即使在互联网上它也相当准确,在局域网上它应该更好。 根据 Wikipedia[1],

NTPv4 通常可以将时间保持在 10 毫秒(1/100 s) 在公共互联网上,并且在理想条件下在局域网中可以达到 200 微秒 (1/5000 s) 或更好的精度。

因此,如果您的条件足够“理想”,它可能足以满足您的需求。 NTP 已经存在了足够长的时间,几乎所有东西都可以使用它。 我认为没有任何理由通过 Java 而不是操作系统来做到这一点。 如果操作系统同步,Java 也会同步。

[1] 维基百科:网络时间协议

I'd really just use NTP. It's pretty accurate even over the internet, and on a LAN it should be even better. According to Wikipedia[1],

NTPv4 can usually maintain time to within 10 milliseconds (1/100 s) over the public Internet, and can achieve accuracies of 200 microseconds (1/5000 s) or better in local area networks under ideal conditions.

so it may be good enough for your needs if your conditions are "ideal" enough. NTP has been around long enough that pretty much everything works with it. I don't see any reason to do this through Java rather than the OS. If the OS is synced up, so will be Java.

[1] Wikipedia: Network Time Protocol

耳根太软 2024-07-30 04:36:14

我在自己尝试一些东西后遇到了这个线程(应该先搜索!)
http://snippets.dzone.com/posts/show/11345 - 可能是一个好的方法,可能很糟糕,但它是分布式的(无服务器),这很好。

I encountered this thread after trying something on my own (should have searched first!)
http://snippets.dzone.com/posts/show/11345 - may be a good method, may be bad, but it's distributed (serverless) which is nice.

永不分离 2024-07-30 04:36:14

旧的DCE(“分布式计算环境”)曾经有一个分布式时间同步解决方案,所有这些能力。 它被称为 DTS。 管理员可以配置要同步的计算机集,并计算并提供延迟或不确定性。 如果任何机器不同步,它的时钟就会慢慢调整,直到再次同步。 可以保证任何机器上的时间永远不会向后调整(违反基本物理学)。 该网络至少需要一个 NTP 输入才能与“现实世界”保持同步。

我不知道时间同步的东西或者一般的 DCE 代码发生了什么。

在我看来,你不需要“Java”解决方案。 您需要同步一组分布式机器的时钟。 Java 应用程序只是在机器上运行的东西。

The old DCE ("Distributed Computing Environment") used to have a distributed time synch solution, with all those capabilities. It was called DTS. The admin could configure the set of machines to sync, and the latency or uncertainty was calculated and available. If any machine got out of sync, it's clock was slowly adjusted until it was in synch again. There was a guarantee that time on any machine would never be adjusted backward (in violation of basic physics). The network needed at least one NTP input in order to stay synched with "the real world".

I don't know what happened to that time synch stuff, or the DCE code in general.

Seems to me you don't need a solution "in Java". You need to sync the clocks of a set of distributed machines. The Java app is just the thing that runs on the machines.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文