低延迟应用程序与常规应用程序有何不同？

总览

我们得到的一个常见问题是： 低延迟应用程序有什么不同？ 读起来像什么？

在设计低延迟应用程序时有很多注意事项，它们与其他应用程序有所不同。

简洁是关键

使事情更快运行的最佳方法是使应用程序减少工作量。 这表示; 创建更少的垃圾，更少的数据转换时间，使应用程序所需的数据随时可用。

注意：我说您需要选择执行此操作，但这并不意味着您必须这样做。 您应该使用探查器来指导您哪些部分需要优化。

如果要保持一致的性能，简单性尤其重要。 如果您查看的是第99个百分位（百分之一，最差）或99.9个百分率（千分之一，最差），则说明大多数情况一下子出错了。 系统越复杂，出错的地方就越多。 如果吞吐量对您也很重要，那么您会发现一个缓慢的结果可能会产生重大的连锁反应，并且您必须担心99.99％或更高的百分位数，因为即使非常罕见的延迟也会影响系统运行之前的许多请求/事件再次正常。 即成百上千个并不罕见。

不要轻易添加，不要轻易删除。

您无需考虑添加代码有多么容易，而删除不需要做的事情有多容易。 许多框架的设计都是为了使其易于入门和添加功能而设计的，但是，如果您需要该框架为您做的事更少，尤其是不需要做的事情。

解决此问题的最佳方法是使用非常薄的库和框架（就调用堆栈和数据转换而言），并且只做很少的事情，如果不需要，可以选择做更少的事情。

您想从一个简单明了的解决方案开始，但是您还希望可以选择替换或删除不需要的任何功能。

减少数据转换时间

我常常惊讶于代码的复杂程度。 它通常像揉面团或揉捏数据那样实现。 相同的数据以一种方式转换，然后以另一种方式转换，有时又转换为另一种形式，最后经过一些定制，将其放入一个数据结构中，该数据结构用于构建另一个数据结构。 所有这些偶然的复杂性都会减慢应用程序的速度，并掩盖了应用程序的实际操作。

您需要设计您的应用程序，以便可以从头到尾查看数据发生了什么，从而可以删除实际上不需要的任何步骤（并且可能是错误的来源）

我已经看到过一个示例，其中Date是一个64位长的整数，它变成了Date对象，在MM / dd / yyyy中变成了字符串，在yyyy / MM / dd中又变成了Date对象，最后被用作64位长（以毫秒为单位）。 我已经看到一个64位的double变成了Double对象，变成了一个String，解析为Double，执行了一些不正确/复杂的舍入，最后使它开始的64位double变成了整数，因为它已经被舍入了。

这听起来很愚蠢，但是框架经常这样做。 不同的部分由不同的人编写，并且在每个库的每个级别，每个库使用的模型之间都会转换数据。

误导大卫·惠勒 ；

可以通过另一层间接抽象来解决计算机科学中的所有问题。

代码的可读性

为了以自然语言风格高层次描述应用程序，编写了许多代码。 即使我不知道如何编程，我也可以理解它在做什么。 这可以像魔术一样工作。 当您高水平编写的内容没有按照您认为的那样做时，就会出现问题。 通过良好的测试可以发现功能问题。 当您的设计掩盖了计算机真正要做的工作的细节时，如何检测到一段代码正常工作但性能很差。 甚至更难检测的是在大多数情况下都能正常执行但有时性能很差的代码。 甚至分析器在这里对您也无济于事。

低延迟代码的优先级是能够轻松读取计算机需要执行的操作，以实现您要求计算机执行的操作。 此操作是O（1），O（log N）还是O（N）？ 这个操作线程安全吗？如果我不需要它是线程安全的，那么使它变得不那么容易吗？

这个低级代码在某种程度上很有用，但是您仍然需要能够从高层次了解正在发生的事情。 应该始终有一段代码说明组件的功能。 这个高级组件会调用，因此您可以看到它是如何执行的。 反过来，这可能需要有关如何精确执行操作的低级详细信息。

业务代码和基础结构代码的分离。

业务代码是应用程序的基本复杂性。 这些是您必须满足的要求。 实际上，如何完成此操作应该是一个单独且可替换的问题。

您的基础结构代码是您的启动器代码，应该可以轻松替换它们而不更改应用程序的功能。

如果您的应用程序没有执行应做的工作，那么您应该能够更改业务逻辑以对其进行修复。 如果应用程序不工作应该的方式 ，你应该能够改变你的基础设施有信心，你的应用程序仍然会做什么，需要做的事。

在哪里可以看到低延迟编码示例？

首先是为低延迟而设计的开源库。 这些包括;

• Aeron – IPC消息传递
• 编年史 –低延迟持久性，分布式访问和数据转换库。

它能带来多少变化？

使用低延迟技术可以极大地提高应用程序的典型性能，还可以提高其吞吐量。 在一致性方面，通过消除应用程序的复杂性，可以将等待时间的百分之99％降低10、100甚至1000。

设计最快吗？

这不是我们正在从事的项目的关键优先事项。 这只是没有生产力。 主要优先事项是开发最简单的解决方案来解决所需性能的问题，但是可以选择付出一点点的努力使其更快，但前提是已经确定需要这样做。

简单性还可以提高可维护性

我们使用的经验法则是，一个成功的系统维护成本约为构建成本的三倍。 系统操作的简单性和透明性有助于长期降低成本，并有助于在较短的时间内交付工作正常的应用程序，从而降低风险。

如果简单性是如此出色，为什么不每个人都这样做呢？

制作大型，复杂的系统很容易，您只需不断添加位，直到它起作用。 使系统简单很难，并且需要经验。 您经常需要多年开发同一类型解决方案的经验，才能知道何时可以避免添加超出实际需要的内容。

翻译自: https://www.javacodegeeks.com/2016/02/low-latency-applications-differ-regular-applications.html