微云 linux_编年史与微云

微云 linux

总览

我面临的一个常见问题是：如果是单个作者，多个读者，如何缩放基于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的垃圾，这是每毫秒就会充满垃圾。