总览
我正在看Typesafe的Rolan Kuhn在介绍反应流方面的出色演讲，乍一看似乎与《纪事报》有一些相似的目标，但是当您深入研究细节时，对我来说显然有一些关键假设是根本不同。
关键假设
《纪事》设计的主要假设是
- 低延迟是您的问题，而不是吞吐量。 数据来自微突发，您希望在下一次微突发活动之前尽快处理。
- 如果您忙碌，则不能暂停交流/制作人。 （或暂停最终用户不是一种选择）
- 您的信息具有很高的价值，记录每个事件的详细时间非常有价值。 记录所有事件是了解微爆的关键。
- 您希望能够检查过去发生的任何事件。
低延迟至关重要
纪事报旨在帮助您解决的关键问题是一致的低延迟。 它假定如果延迟足够低，那么吞吐量就不会有问题。 许多基于Web的系统都是为吞吐量而设计的，只要最终用户看不到延迟，延迟就不会成为问题。 对于软实时系统，大多数时候您都需要低延迟，而最坏情况下的延迟则要适度，这要比人类看到的快得多。
你无法阻止世界
另一个关键假设是流量控制不是一种选择。 如果您运行缓慢，则无法对交易所及其所有用户说，请等我一会儿再追。 这意味着生产者永远不会被消费者放慢脚步。
降低生产者速度实际上与增加延迟时间相同，但是此延迟时间很容易隐藏。 如果您等到生产者将事件标记为时间戳，则可以使延迟看起来更好。 如果您想采取更现实的措施，则应使用时间戳记，事件应该由生产者发送 ，并且不会延迟。
您需要记录所有内容以便重播
重放对于在一定条件下测试应用程序很有用。 例如，您可以更改您的应用程序，不仅可以看到它的行为正确，而且可以及时运行。 对于定量分析，他们将需要一组数据来调整其策略。
实时重播旧事件。
您不必记住以后要引用的事件副本，而可以记住它的索引，并可以按需稍后重播该事件。 这样可以节省堆中的内存，或仅在情况下复制数据。
微爆发对于理解您的系统至关重要。
一些系统的性能以每天的交易为特征。 这意味着，如果在前23个小时内没有完成任何事务，而所有事务都在最后一个小时内完成，那么您仍将每天执行这么多事务。 经常引用每天的交易是因为它的数量更高，但就我而言，整天简化工作量听起来很奢侈。
某些系统可能以每秒的事务数为特征。 这可能意味着这些事务可以在一秒钟内开始并完成，但并非总是如此。 如果您有1000笔交易，并且每毫秒进行一次交易，那么您将获得均匀的响应时间。 我发现更有趣的是一天中最忙的一秒钟的交易数量。 这样可以指示系统应该能够处理的流速。
检查微脉冲
考虑一个系统，该系统在相同的100微秒内获得30个事件，而这些突发间隔为100毫秒。 这可能显示为每秒（30 / 0.1）300个事务，这听起来相对容易，如果我们需要做的只是跟上进度，但是如果我们希望尽快做出响应，则短期/突发吞吐量为100中的30微秒或每秒30万个事件。
换句话说，要尽可能快地处理微爆发，您将需要一个系统，该系统能够处理的吞吐量比您在几秒钟，几分钟或一天内预期的吞吐量高出多个数量级。 理想情况下，系统的吞吐量将是一天中最忙的一秒钟的100倍。 在不减慢对这些数据突发的处理速度的情况下，每秒处理最繁忙的10毫秒所需的时间。
编年史如何改善微爆的处理
低垃圾率
最小化垃圾是避免GC暂停的关键。 为了有效地使用L1和L2缓存，您需要将垃圾率保持在非常低的水平。 如果您没有有效地使用这些缓存，则您的应用程序速度可能会慢2-5倍。
Chronicle中的垃圾非常低，您可以处理一百万个事件，而jstat不会检测到您创建了任何垃圾。 jstat仅在分配了新的TLAB时显示4 KB的倍数。 编年史确实会产生垃圾，但是它非常低。 即每百万个事件过程中有几个对象。
一旦使GC暂停易于管理或不存在，您便开始看到系统中的其他延迟源。 拿走巨石，您开始看到岩石。 拿走岩石，您开始看到鹅卵石。
支持全部写入模型。
众所周知，如果保持DEBUG级别登录，则会大大降低应用程序的速度。 在记录您以后可能想要知道的一切与对您的应用程序的影响之间存在紧张关系。
编年史设计得足够快，您可以记录所有内容。 如果替换系统中的队列和IPC连接，则可以提高性能，并且可以免费甚至更好地“记录所有内容”。
能够记录所有内容意味着您可以在系统的每个阶段添加跟踪时间，然后监视系统，还可以深入研究系统中最糟糕的1％延迟。 这不是您可以使用剖析器为您提供平均值的方法。
通过编年史，您可以回答以下问题： 系统的哪些部分负责一天中最慢的20个事件？
记事本与操作系统的交互最少。
系统调用速度很慢，如果可以避免调用操作系统，则可以节省大量的延迟。
例如，如果在回送时通过TCP发送消息，则在写入和读取数据之间可能会增加10微秒的延迟。 您可以写入编年史，这是对内存的简单写操作，也可以从编年史中读取，这也是从内存中读取的内容，延迟为0.2微秒。 （正如我之前提到的，您也将获得持久性）
无需担心用完堆。
无限制队列的一个常见问题，这使用了一个开放式堆。
Chronicle通过不使用堆来存储数据，而是使用内存映射文件来解决此问题。 通过使数据更紧凑，可以提高内存利用率，但也意味着1 GB的JVM一天可以流1 TB的数据，而不必担心堆或您拥有多少主内存。 在这种情况下，无界队列变得更易于管理。
结论
通过基于不同的假设，Chronicle解决了其他解决方案避免的问题，例如需要流控制或使用消息（删除已处理消息）。
Chronicle旨在更有效地利用您的硬件，因此您不需要说30个服务器的云即可每秒处理约一百万个事件（如许多基于云的解决方案所称），您可以与开发人员联系以达到此事件率笔记本电脑。
翻译自: https://www.javacodegeeks.com/2014/05/chronicle-and-low-latency-in-java.html
