为Symfony2和Redis正名:基于PHP的10亿请求/周网站打造

控制台组件

　　开发和维护时，我们特别喜欢Symfony控制台组件，这个组件为创建CLI工具提供了很好的面向对象接口。应用大概添加了50%的新功能，这些新功能基于CLI指令，主要用作管理或分析应用内部构件。

　　控制台组件妥善的处理命令语句或选项—你可以设置默认值，可选值或所需的值。好的实践总是将这些恰当的记录为代码—你可以给命令和选项设置主要描述。命令通常是自我文档的，因为添加--help选项便能生成格式化的指令描述。

$ php app/console octivi:test-command --help
Usage:
 octivi:test-command [-l|--limit[="..."]] [-o|--offset[="..."]] table

Arguments:
 table                 Database table to process

Options:
 --limit (-l)          Limit per SQL query. (default: 10)
 --offset (-o)         Offset for the first statement(default: 0)

我们必须牢记在准确设置的环境下运行指令。默认的dev可能会导致一些问题，如内存泄漏（因为更多冗长的日志存储和保存调试信息）。

$ php app/console octivi:test-command --env=prod

想要更好的信息显示，添加-v选项。

$ php app/console octivi:test-command --env=prod -vvv

　　进度条是一个很好的帮手。进度条甚至考虑了信息显示详细程度，当程度比较低时，只显示基本信息，程度比较高时，还可以显示运行时间，内存消耗等信息。

　　此外，我们还有一些耗时大约两天的迁移过程—0内存泄漏—没有进度条，监控它们将是灾难。

数据层

　　对于Redis，数据层我们使用PredisBundle。

　　我们拒绝Doctrine ORM，因为它将添加额外费用，而且我们不需要任何高级的面向对象操作。我们使用Doctrine DBAL代替，Doctrine DBAL特征如下：

• 查询生成器
• 预处理语句

　　使用PredisBundle和Doctrine Bundle也允许我们在大量使用分析工具的时候监控弱查询。

总结

　　多亏Symfony2，这种设置在保持高性能和高可用性的同时保持了友善的开发环境——可维持，稳定。实际上这是用作电商网站的关键子系统的关键业务需求。

　　因此本文的最后我们可以纠正一些错误观点：

• 不能使用Redis作为主要存储——如我们先前所说的，当然是可以的！Redis是一项很稳定的技术，有一些持续性机制，你不会丢失关键数据。
• Symfony2功能很多以至于它很慢——当你不使用例如ORM的一些耗时/内存的工具时，你可以获得和Silex（是的，我们测试过它）微框架类似的性能。

原文链接：Handling 1 Billion requests a week with Symfony2（编译/ 蔡仁君　责编/仲浩）