转载

低延迟应用与普通应用之间有何不同

概述我们遇到的一个常见问题：是什么让一个低延迟应用有所不同？这是我们真正想要读到的吗？

设计低延迟应用时需要考虑很多因素，也正是这些因素将其与其它应用区分开来。

简单性是关键

如果我们想让一样东西执行得更快，最好的方式是让它做更少的工作。也就是说，要产生更少的垃圾，转换更少次数的数据，让应用需要的数据随时可获取。

值得注意的是：我说你需要做这些选项，但这并不意味着你必须这样做。你应该使用一个分析器来指导你完成需要优化的部分。

如果你想获得稳定的性能，简单性尤其重要。如果你期待99%或者99.9％的准确率，那么如果你看到系统出错，此时肯定是绝大多数事情都在变糟。系统越复杂，事情就会变得越糟糕。如果吞吐量也对你很重要，你会发现一个缓慢的输出会对结果产生很不好的影响，你有必要开始担心99.99%或更高的准确率，因为在系统再次处于正常运行状态之前，即使一个非常不常见的延迟也会影响许多请求或事件，何况很多时候，数百或数千个延迟也并不少见。

不要考虑容易添加，而要考虑容易移除

你不需要考虑太多如何方便地添加代码的事情，而是要考虑怎么轻松地剔除那些不需要做的事情。许多框架在设计的时候就会考虑让其能够轻松上手，也很容易添加功能，这样如果你需要框架少做一些事情，那么它就可以少做一些事情。

解决这一点的最好方法是使用非常轻薄的库和框架（在调用堆栈和数据变换的方面），如果不需要甚至可以做得更少。

你想要一个清晰简单的解决方案，但你也想有选项可以替换或删除你不需要的任何功能。

转换更少次数的数据

我常常对代码的错综复杂感到惊讶。它经常像揉面或揉数据一样被执行。相同的数据被转换一次又一次，然后还会再返回来转换为另一种形式，最后与某些自定义数据放入一种数据结构中，被用来构建另一种数据结构。所有这些复杂过程都减慢了应用程序的运行速率，并掩盖了应用程序实际做的事情。

你需要设计自己的应用程序，这样你可以看到数据从一端到另一端发生了什么，以致你可以删除你实际上不需要的一些步骤（并且可能是错误的来源）。

我见过一个日期的例子，要将一个64位长整数转换成一个日期对象，然后再转换为一个MM / DD / YYYY的字符串，再转换为一个yyyy / MM / DD的字符串，再转换为日期类型，并最终转换回64位长整形。我也见过另一个例子，要将64位double型转换为一个double型对象，转换为字符串类型后又解析为double型，进行一些不正确的或复杂的四舍五入，最后转化为了最初的64位double型。

这听起来很傻，但是有些框架经常会这样做。每个库中每种层次的部分由不同的人写入，数据在每个库所使用的模型之间转换。

计算机科学中的所有问题都可以从抽象层面来解决。

代码的可读性

很多代码是以一种自然语言的风格，在高层次上对应用程序进行描述。即使我不懂编程，我也知道代码要做的事情。这工作就像魔术。但问题是，代码虽然在高层次上编写，但是执行的时候并不是像你想象的那样。虽然功能性问题可以通过好的测试被发现。当你的设计掩盖了计算机实际执行的有关细节的时候，虽然代码正确执行，但是该如何判断它执行的很差呢？有些代码在大部分情况下执行得很好，只在很少的时候表现不好，此时更难检测。即使性能分析工具也帮不了太多。

低延迟代码的优越性是它能够轻易地读出你让计算机需要实现的事情。这个操作是O(1)，O(log N)或者O(N)？这个操作是线程安全的吗？如果我不需要让它是线程安全的，是不是不会这么容易？

这种低层次的代码是有用的，但你仍然需要从高层次上理解代码要做的工作。总存在一部分代码告诉你组件是用来干什么的。这种高层次的组件调用往下，以致你可以看到它是怎么工作的。反过来又可以看到代码在低层次上工作的细节。