编年史与微云

总览

我面临的一个常见问题是：如果是单个作者，多个读者，您如何扩展基于Chronicle的系统。尽管有解决此问题的方法，但很有可能根本不会出现问题。

微云

这是我用来描述单个线程来完成当前由多个服务器完成的工作的术语。（或者与将单个应用程序部署到多台计算机的趋势相反）

假设扩展系统的唯一方法是分区或具有多个副本。除非您同时拥有多个系统，否则这种扩展并不总是那么好。所有这些都增加了系统开发，部署和维护的复杂性。我看到的一个常见问题是，开发人员不再能够在其工作站或单元/功能测试中测试端到端系统

基于编年史的处理引擎具有不同的方法。它们通常旨在处理您所能承受的最大负载。即瓶颈在其他地方，例如与外部系统，网关和数据库的接触点。基于Chronicle的处理引擎可以每秒处理100,000至1,000,000入站和出站事件，延迟介于1到10微秒之间。这比网关可以向引擎输入数据或向引擎输出数据的速率高得多，因此从来没有一个很好的分区用例。这是一个选择，但您不应该认为这是您需要的选择。

这样做的好处是您拥有一个确定性系统，该系统在体系结构上非常简单。该系统是确定性的，因为您具有每条入站和出站消息的记录，这些记录可能具有微秒级的计时，并且系统的行为是完全可复制的（并且可重新启动的）。注意：其后果之一是，仅重新启动失败的服务将无济于事。如果它基于特定消息以特定方式失败一次，则每次重新启动时都应该以完全相同的方式失败。这使得重现问题和测试变得更加容易。

为什么这么快？

一个线程中的一个单线程处理引擎具有

无锁
没有TCP延迟
可以锁定到内核或CPU，以改善缓存行为。
即它永远不会上下文切换或放弃CPU。
可重用的可变对象更加实用，因此您可以避免用垃圾搅乱缓存，从而使内存访问速度提高5倍。（有了奖金，您将不再具有GC暂停）

避免产生垃圾的真正原因

大多数Java应用程序中的一个常见问题是GC暂停时间。您通常希望将其最小化。我主张减少产生的垃圾，但是我不担心GC暂停，因为我还没有编写一个可以在交易四年后暂停的系统。我通过使Eden大小大于一天中产生的垃圾量来做到这一点，并在维护时段（视情况在深夜或周末）进行System.gc（）。在低延迟应用程序中避免垃圾的主要原因是创建垃圾会导致缓存的滚动或刷新。如果您有一个系统（套接字上的所有JVM）产生200 MB / s的垃圾，并且有20 MB的L3高速缓存，则您每隔0.1秒就会有效地用垃圾填充高速缓存。对L3高速缓存的内存访问可能比对主内存的访问快5倍。

注意： L3缓存在套接字的所有内核之间共享，因此，如果要在所有内核上实现可伸缩性，则希望使用L1缓存（通常为32 KB），并且如果有繁忙的线程在创建32 MB / s的垃圾，则每毫秒就会充满垃圾。