为什么电梯网框架可扩展？

Question

我想知道电梯网框架具有高性能和可扩展性的技术原因？我知道它使用scala，它有一个actor库，但根据安装说明，默认配置是jetty。那么它是否使用actor库来扩展？

现在开箱即用的可扩展性。只需添加额外的服务器和节点，它将自动扩展，它是如何工作的？它可以处理与支持服务器的500000多个并发连接。

我正在尝试为企业级创建一个Web服务框架，它可以胜过那里的内容，并且易于扩展，可配置和可维护。我对扩展的定义只是增加了更多的服务器，你应该能够容纳额外的负载。

由于

Answer 1

Lift的可扩展性方法在一台机器中。跨机器扩展是一个更大，更难的主题。简短的回答是：Scala和Lift不做任何事情来帮助或阻碍水平缩放。

就单个机器中的actor而言，Lift实现了更好的可伸缩性，因为单个实例可以处理比大多数其他服务器更多的并发请求。为了解释，我首先要指出经典的每线程请求处理模型中的缺陷。跟我说，这需要一些解释。

典型的框架使用线程来处理页面请求。当客户端连接时，框架会从池中分配一个线程。该线程然后做三件事：它从套接字读取请求;它做了一些计算（可能涉及到数据库的I / O）;它会在套接字上发送响应。几乎每一步，线程都会在一段时间内阻塞。在读取请求时，它可以在等待网络时阻塞。在进行计算时，它可以阻塞磁盘或网络I / O.它也可以在等待数据库时阻塞。最后，在发送响应时，它可以阻止客户端缓慢接收数据并填充TCP窗口。总体而言，该主题可能会占用30％-90％的时间。但是，它花费了100％的时间来处理这一请求。

JVM在真正减速之前只能支持这么多线程。线程调度，共享内存实体（如连接池和监视器）的争用以及本机操作系统限制都会对JVM可以创建的线程数量施加限制。

好吧，如果JVM的最大线程数受到限制，并且线程数决定了服务器可以处理的并发请求数，那么并发请求的数量将由线程数决定。

（还有其他问题可以施加下限 - 例如GC捶打。线程是一个基本的限制因素，但不是唯一的限制因素！）

提升将线程与请求分离。在Lift中，请求不绑定一个线程。相反，线程执行操作（如读取请求），然后向actor发送消息。演员是故事的重要组成部分，因为它们是通过“轻量级”线程安排的。线程池用于处理actor中的消息。避免在actor内部阻塞操作很重要，因此这些线程会迅速返回池中。 （请注意，此池对应用程序不可见，它是Scala对actor的支持的一部分。）例如，当前在数据库或磁盘I / O上被阻止的请求不会保留请求处理线程。几乎可以立即使用请求处理线程来接收更多连接。

这种用于从线程解耦请求的方法允许Lift服务器具有比每个请求线程服务器多得多的并发请求。 （我还想指出，Grizzly库支持没有actor的类似方法。）更多的并发请求意味着单个Lift服务器可以支持比常规Java EE服务器更多的用户。

Answer 2

at mtnyguard

“Scala和Lift不做任何事情来帮助或阻碍水平缩放”

不太对劲。 Lift是高度有状态的框架。例如，如果用户请求表单，那么他只能将请求发布到表单来自的同一台机器上，因为表单处理操作保存在服务器状态。

这实际上是一种在某种程度上阻碍可伸缩性的事情，因为这种行为对于无共享体系结构是不一致的。

毫无疑问，升力具有很高的性能，但性能和可扩展性是两回事。因此，如果您想通过电梯进行水平扩展，则必须在负载均衡器上定义粘性会话，这会在会话期间将用户重定向到同一台计算机。

Answer 3

Jetty可能是入门点，但是演员最终会为请求提供服务，我建议看一下twitter-esque示例，'skitter'，看看你将如何创建一个非常可扩展的服务。 IIRC，这是推特人注意的事情之一。

Answer 4

我非常喜欢@ dre的回复，因为他正确地指出了升力的状态是水平可扩展性的一个潜在问题。

问题 - 而不是我再次描述整个事情，请查看本文中的讨论（不是内容）。 http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html

解决方案是@dre在前面的负载均衡器上说粘性会话配置并添加更多实例。但是由于在lift + actor组合中完成了lift中的请求处理，你可以期望一个实例处理比普通框架更多的请求。这将优于其他框架中的粘性会话。即个别实例处理更多的能力可能有助于您扩展

• 你有Akka电梯整合，这将是另一个优势。