我一直在阅读并开始设置一些不同的服务器群集环境。 我使用各种Linux发行版正常工作。
基本设置如下：
----- App Server 1 | Database Server 1 Load Balancer --| Database Server 2 | ----- App Server 2 正如你所看到的，这是一个基本的奴隶主设置。 我的问题我不确定复制应用程序服务器部分的最佳方式。 所以，如果新的脚本文件或更改是对应用程序服务器1，这些更改如何级联到第二个应用程序服务器？
数据库服务器运行MySQL，所以任何更新都会自动更新到其他的级联。
TL的DR版本是： 它取决于应用程序
作为现代软件应该如何build立的一个很好的参考，我强烈推荐阅读十二个因素的应用程序 。
脚本和代码不会被复制，而是“发布”到应用服务器（也可以通过向所有服务器释放所有服务器并使用另一种机制（例如符号链接）从旧代码切换到新的服务器来启动服务器）。
然而，如果客户端要正确地处理请求，客户端往往需要记住“状态”。
一般来说，为了使应用程序服务器可以横向扩展，你希望它们尽可能地“无状态”。 这意味着应用程序服务器没有任何东西可以记住，它全部存储在外部，任何请求都可以用请求中收到的数据来完成。 但是，您的客户端（Web浏览器）通常需要状态，例如正在login，所以您需要能够以某种方式处理状态数据。
一种解决方法是使用在负载均衡器上实现的“粘性会话”。 通常，这是通过注入负载均衡器用来logging哪个服务器应该发送请求的cookie来实现的。 这很容易实现，不需要更改代码，但是有一个相当大的缺点，即在重新启动应用程序服务器时，状态将会丢失。
另一种方法是通过在cookie中存储所有内容来使应用程序成为无状态的。 我不build议这样做，因为状态数据将在每个请求上传。 客户也可以修改这些数据并做出意想不到的事情，如果有人抓取cookie，可能会产生巨大的隐私影响。
这些都不能解决磁盘上的文件问题，因为它们依赖于用户可能会丢失的cookie，或者他们只能从其他地方login。
最后的推荐方法是将客户端状态存储在数据库（或键：值存储）中，以便任何应用程序实例在收到请求时都可以查询它。 您仍然需要客户端记住“会话ID”，但由于客户端存储的数据较less，因此它更安全。 传统上，具有一致哈希的memcached节点集群将执行此angular色，但是现在有更强大的解决scheme（如Redis） 。
关于磁盘上的文件 – 不要在应用程序服务器磁盘上存储任何内容，应用程序代码和可作为部署“发布”的静态资产除外。 日志是一个可能的例外，但将它们推送到远程系统日志服务器或类似logstash总是可取的。
如果您的应用程序必须存储文件（如客户端上传的文件），请将其存储在某种types的数据存储中（Cassandra不是一个错误的select），Openstack的swift或Amazon S3等存储服务大到足以certificate你自己做了。
如果应用程序规模较小，并且正确处理文件locking，则NFS或samba共享也可以工作，但在推出此路线之前，我会推荐使用Amazon S3。
一般情况下，你想要的是有一个环境，你可以testing出代码的变化，然后逐个展开到你的应用服务器（在你的图中，一台服务器，然后是另一台）。 但是，如果您有数据库模式更改，则会变得更复杂一点，您可能需要编写代码来考虑这一点。
如果您想要复制文件系统更改，可以使用DRBD或gluster之类的文件系统来共享文件系统。 或者，根据您的要求，使用rsync等创build您自己的定制解决scheme。