我们的应用程序的用户群已达到200万用户，我们计划使用AWS扩展该应用程序。
我们面临的主要问题是共享数据的处理，包括缓存，上传，模型，会话等。
AWS EFS是一个选项，但由于文件非常小，范围从几字节到几MB，并且更新非常频繁，因此它会破坏应用程序的性能。
我们可以将Memcache / Redis用于会话，而将S3用于上传，但仍然需要管理缓存，模型和其他一些共享文件。
在小文件频繁更新的情况下，是否可以使用EFS替代方法或使EFS工作？
答案 0 :(得分：1)
对于EFS，小的文件和频繁的更新应该不是问题。
某些用户在原始版本中遇到的问题是，它的两个维度紧密结合在一起-可用吞吐量的多少取决于您所支付的金额，而您所支付的金额则取决于总数的函数文件系统的大小（所有文件组合在一起，而不管单个文件的大小如何）...因此，越大，速度越快。
但是从那以后，他们就引入了“预设吞吐量”，使您可以将这两个维度解耦。
此默认Amazon EFS吞吐量突发模式可提供适用于大多数应用程序的简单体验。现在，借助预置吞吐量，吞吐量要求高于Amazon EFS默认吞吐量突发模式所允许的应用程序可以立即且始终独立于数据量而达到所需的吞吐量水平。
https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-efs-now-supports-provisioned-throughput/
如果使用此功能，则需要根据数据大小来支付所配置的吞吐量和应包括的吞吐量之间的差额。
另请参见 Amazon Elastic File System用户指南中的Amazon EFS Performance。
可以激活和取消激活预定的吞吐量，因此不要将其与以下两种性能模式混淆：称为通用的 和最大I / O ，在创建文件系统时必须选择其中一项，以后不能更改此选择。这些与基础架构中的可选折衷有关，建议的做法是根据观察到的指标选择 General Purpose （除非您有理由不这样做）。 最大I / O 模式的元数据一致性模型与通用模型不同。