本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 无状态数
要在自动扩展配置中利用多个 Web 服务器，您的 Web 层必须处于无状态状态。无状态应用程序是指不需要知道以前的交互并且不存储会话信息的应用程序。如果是 WordPress，这意味着无论哪个 Web 服务器处理了他们的请求，所有最终用户都会收到相同的响应。无状态应用程序可以横向扩展，因为任何请求都可以由任何可用的计算资源（即 Web 服务器实例）提供服务。当不再需要该容量时，可以安全地终止任何单个资源（在耗尽正在运行的任务之后）。这些资源不需要意识到同行的存在——所需要的只是一种将工作量分配给他们的方法。
在用户会话数据存储方面， WordPress 核心是完全无状态的，因为它依赖于存储在客户端 Web 浏览器中的 Cookie。除非您安装了任何依赖本机会话的自定义代码（例如 WordPress 插件），否则不会考虑PHP会话存储。
但是， WordPress 最初是为在单台服务器上运行而设计的。因此，它将一些数据存储在服务器的本地文件系统上。在多服务器配置 WordPress 中运行时，这会产生问题，因为各个 Web 服务器之间存在不一致性。例如，如果用户上传了一张新图像，则该图像仅存储在其中一台服务器上。
这说明了为什么我们需要改进默认的 WordPress运行配置才能将重要数据移动到共享存储。最佳实践架构将数据库作为 Web 服务器之外的独立层，并利用共享存储空间来存储用户上传的内容、主题和插件。
# 共享存储（亚马逊 S3 和亚马逊EFS）
默认情况下，将用户上传的内容 WordPress 存储在本地文件系统上，因此不是无状态的。因此，我们需要将 WordPress 安装和所有用户自定义设置（例如配置、插件、主题和用户生成的上传）转移到共享数据平台中，以帮助减少 Web 服务器的负载并使 Web 层处于无状态状态。
[Amazon Elastic File](https://aws.amazon.com/efs/details/) System（亚马逊EFS）提供可扩展的网络文件系统，用于EC2实例。Amazon EFS 文件系统分布在数量不受限制的存储服务器上，使文件系统能够弹性增长，并允许从实例进行大规模并行访问EC2。Amazon 的分布式设计EFS避免了传统文件服务器固有的瓶颈和限制。
通过将整个 WordPress 安装目录移动到EFS文件系统上，并在每个实例启动时将其安装到每个EC2实例中，您的 WordPress 站点及其所有数据将自动存储在不依赖任何一个EC2实例的分布式文件系统上，从而使您的 Web 层完全处于无状态状态。这种架构的好处是，您无需在每次启动新实例时都安装插件和主题，并且可以显著加快 WordPress 实例的安装和恢复。如本文档的 “部署注意[事项” 部分所述 WordPress，在中部署](appendix-a-cloudfront-configuration.md)对插件和主题的更改也更加容易。
为确保您的网站在EFS文件系统上运行时获得最佳性能，请查看 Amaz OPcache on EFS 和[AWS参考架构的](https://github.com/awslabs/aws-refarch-wordpress#opcache)推荐配置设置 WordPress。
您还可以选择将所有静态资产（例如图像和 JavaScript 文件）卸载到前面有 CloudFront 缓存的 S3 存储桶。CSS如本白皮书的 “[静态内容](accelerating-content-delivery.md)” 部分所述，在多服务器架构中执行此操作的机制与单服务器架构完全相同。其好处与单服务器架构相同，您可以将与提供静态资产相关的工作转移到 Amazon S3，从而使您的 Web 服务器能够仅专注于生成动态内容 CloudFront，并在每台 Web 服务器上处理更多用户请求。
# 数据层（亚马逊 Aurora 和亚马逊 ElastiCache）
通过将 WordPress 安装存储在分布式、可扩展、共享的网络文件系统上，并由 Amazon S3 提供静态资产，您可以将注意力集中在剩下的有状态组件：数据库。与存储层一样，数据库不应依赖于任何一台服务器，因此不能将其托管在其中一个 Web 服务器上。而应将 WordPress 数据库托管在亚马逊 Aurora 上。
[Amazon Aurora](https://aws.amazon.com/rds/aurora) 是一种与 My SQL 和 Postgre SQL 兼容的关系数据库，结合了高端商用数据库的性能和可用性，同时还具有开源数据库的简单性和成本效益。Aurora My 将数据库引擎与由专门构建的分布式存储系统紧密集成，来SQL提高我的SQL性能和可用性。SSD它具有容错能力和自我修复功能，可在三个可用区复制六个数据副本，可用性超过 99.99%，并且可以持续备份您在 Amazon S3 中的数据。Amazon Aurora 旨在自动检测数据库崩溃并重新启动，无需进行崩溃恢复或重新构建数据库缓存。
Amazon Aurora 提供了[多种实例类型](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html)，以适应不同的应用程序配置，包括内存优化型实例和可突发实例。要提高数据库的性能，您可以选择大型实例类型来提供更多CPU和内存资源。
Amazon Aurora 会自动处理主实例和 [Aurora 副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Replication.html)之间的故障转移，以便应用程序尽快恢复数据库操作而无需手动管理干预。失效转移到失效转移通常可在不到 30 秒的时间内完成。
创建至少一个 Aurora 副本后，使用集群终端节点连接到您的主实例，以便在主实例出现故障时您的应用程序能够自动进行故障转移。您可以跨三个可用区域创建多达 15 个低延迟只读副本。
随着数据库的扩展，数据库缓存也需要扩展。如前面的 “[数据库缓存](database-caching.md)” 部分所述， ElastiCache 它具有跨 ElastiCache 集群中的多个节点以及跨区域的多个可用区扩展缓存的功能，以提高可用性。在扩展 ElastiCache 集群时，请确保将缓存插件配置为使用配置终端节点进行连接，以便 WordPress 可以在添加新集群节点时使用它们，并在移除旧集群节点后停止使用它们。您还必须将 Web 服务器设置[为使用ElastiCache群集客户端](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Appendix.PHPAutoDiscoverySetup.html)，PHP并更新您的服务器AMI以存储此更改。