问CodeIgniter 3 Redis支持的会话性能和可扩展性

EN

我用托管在亚马逊网络服务中的基于tomcat / java的应用程序做了类似的事情，我们从基于DynamoDB的会话管理转移到了亚马逊网络服务管理的memcached。根据我的经验，下面是我可以提供的一些建议。

1. Setup自动故障转移：因为DynamoDB是一个托管服务，所以我们不必担心故障转移/冗余。但使用托管elasticache时，您必须启用冗余和多az复制，因为默认情况下它不在那里。如果您希望在redis节点故障转移时保持无缝的用户体验，请确保在您的Redis集群上启用了自动故障转移的Multi-AZ。
2. Choosing实例大小

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

写道：，你没有提到任何关于有多少新用户登录的信息，但我认为可以放心地假设它不会像阅读量那么高。如果您灵活地管理会话长度，则可以轻松地管理写入。就目前而言，可以放心地假设它将低于读取吞吐量。

这意味着您可以使用cache.t3.small (具有自动故障转移功能的多可用区)，它具有2vCPU和1.37 if，足以容纳您的吞吐量和100MB会话存储needs.

• Selecting正确的缓存轮换策略：您想知道缓存是否正确轮换，以及当elasticache饱和时用户性能会发生什么变化。确保添加正确的TTL，该TTL与您的会话长度匹配。

• Know限制和瓶颈：确保在推出此更改之前对应用程序进行负载测试。a)了解您的应用程序在迁移到ElastiCache后可以按原样处理的当前登录请求。准备好升级策略，以防流量增长。b)在缓存过期时验证最终用户影响c)在缓存已满时验证对新登录的影响并向发出警报:至少针对elasticache信号和当elasticache延迟启动超过可接受的阈值时设置监视。

AWS有一份文件涵盖了以下内容-

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/nodes-select-size.html

这真的取决于你拥有的数据量(也试着估计你的增长)，你的应用程序是不是写得很重等等。

我建议您也阅读一下"Configure Amazon ElastiCache for Redis for higher availability“文档，并将其纳入您的考虑范围。

这个问题很有趣。我用NGINX做了一些很接近的事情，只有2 2GB的内存。我建议的第一件事是如果可能的话，实现大量的缓存逻辑。您可以同时使用redis作为缓存和会话驱动程序，但除非必要，否则确保这1700个连接不会全部命中DB，这一点非常重要。

其次，您需要确保您的服务器和数据库配置为能够正确管理该数量的连接。为此，有三个特别有用的资源：https://gist.github.com/denji/8359866 (对阅读https://www.nginx.com/blog/tuning-nginx/也很有用)、MySqlTuner和PHP FPM High Performance Tuning。

同样根据经验，由于unix内核的限制(可以是tweaked for improvement)，在端口上运行FPM比在套接字中运行它更可靠。

最后，我还添加了cloudflare，以防止基本的ddos攻击等，并知道您只需担心真正的用户。