深圳企业网站,免费主题大全软件下载,站酷素材,推广链接怎么做微云 linux总览 我面临的一个常见问题是#xff1a; 如果是单个作者#xff0c;多个读者#xff0c;如何缩放基于Chronicle的系统。 尽管有解决此问题的方法#xff0c;但很有可能根本不会有问题。 微云 这是我用来描述单个线程来完成当前由多个服务器完成的工作的术语。 … 微云 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的垃圾这是每毫秒就会充满垃圾。 结论 因此我开始使用术语“微云”。 即在一个线程中完成整个云的工作。 我有几个这样做的客户。 跨一个系统的许多JVM所做的工作只能通过一个非常快的线程来完成。 显然在一个工作站上测试一个线程要容易得多并且在生产中占用数据中心的机架空间要少得多。 参考 Vanilla Java博客上的JCG合作伙伴 Peter Lawrey撰写的编年史和微云 。 翻译自: https://www.javacodegeeks.com/2013/02/chronicle-and-the-micro-cloud.html微云 linux
