amazon-web-services - CodeIgniter 3 Redis 支持的 session 性能和可扩展性

Question

我将在我的 codeigniter 3 应用程序中使用 aws elasticache Redis。我收到了相当多的流量，想知道在设置方面是否需要注意什么？我一分钟收到 1700 个请求，并将其用于 php session 。我想知道什么弹性缓存实例大小才有效(AWS)

我正在放弃数据库支持的 session ，因为这会导致 GET_LOCK 出现问题，导致大量连接堆积。

根据我的初步测试，它似乎工作得很好而且很快。我查询了 session 表的大小(多个应用程序实例)，并且 session 数据有 100MB。

Answer 1

我对 aws 中托管的基于 tomcat/java 的应用程序做了类似的操作，我们从基于 DynamoDB 的 session 管理转向 AWS 托管的 memcached。以下是我根据我的经验可以提供的一些建议。

1. 设置自动故障转移:由于 DynamoDB 是一项托管服务，我们不必担心故障转移/冗余。但是，使用托管Elasticache，您可以启用冗余和多可用区复制，因为默认情况下它并不存在。如果您希望在 Redis 节点故障转移时保持无缝的用户体验，请确保在 Redis 集群上启用具有自动故障转移功能的多可用区。

2. 选择实例大小

   读取:高峰时段每分钟收到 1700 个请求。假设在峰值秒期间，每秒大约有 1700/60 = ~30 个请求，这是所选 Elasticache 实例应该能够处理的最小读取吞吐量。

   写入:您没有提到有关有多少新用户登录的任何信息，但我认为可以安全地假设它不会像读取一样高。如果您能够灵活地管理 session 长度，则可以轻松管理写入。目前可以安全地假设它将小于读取吞吐量。

   这意味着您可以使用 cache.t3.small(具有自动故障转移功能的多可用区)，它具有 2 个 vCPU 和 1.37GB，足以满足您的吞吐量和 100MB session 存储需求。

3. 选择正确的缓存轮换策略:您想知道缓存是否正确轮换，以及弹性疼痛饱和时用户性能会发生什么情况。确保添加与您的 session 长度相匹配的正确 TTL。

4. 了解限制和瓶颈:确保在推送此更改之前对应用程序进行负载测试。 a) 了解您的应用程序可以按原样处理哪些当前登录请求，以及迁移到 Elasticache 后的情况。准备好升级策略，以防流量增长。 b)验证缓存过期时对最终用户的影响c)验证elasticache中缓存已满时对新登录的影响

5. 设置监控和警报:至少针对 Elasticache 故障转移信号以及 Elasticache 延迟开始超出可接受阈值时设置监控。