SUPEE-6788（可能）缓存问题

自从我们在客户的站点上应用SUPEE-6788补丁以来，该站点每天约有一次宕机，而且似乎唯一可以恢复的就是清除缓存。我们查看了日志，其中许多日志似乎包含“前端控制器达到了100个路由器匹配迭代”。在应用补丁之前，不会发生此问题。任何人都不知道是什么原因造成的吗？有人说这可能是magento问题中的缓存错误，但我无法确定。任何输入都会有所帮助！

一些附加说明：

• 发生故障时，服务器上没有任何繁重的负载，因此这不是一个因素。
• 是的，以前的所有补丁均已成功应用。
• 我们正在使用内存缓存来存储缓存。

我自己和另一个开发人员也遇到了类似的问题，但是我们似乎通过应用此GitHub中存在的补丁已解决了该问题：https : //github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

原因似乎是某种竞争状况，其中缓存由一个进程清除，而由另一个进程重新实例化，我已经能够通过遵循该GitHub上列出的步骤来重现它。

我已经与Magento开通了有关此问题的支持票，并且怀疑自补丁程序以来是什么原因引起的，但是我一直在等待回音。

您可以在以下问题上阅读更多有关它的信息：应用SUPEE-6788补丁后，页面样式不正确，路径错误，布局配置丢失。

3个站点版本1.8.1存在相同的问题。它在SUPEE 6788之后开始出现。从上面的修复不能解决问题。实际上，似乎有些变化。修复之前，网站每天崩溃两次，而最近一次崩溃发生在2天之后。但是可能与负载有关。这三个站点很小，负载也不大。对于版本为1.6.2和SUPEE 6788的大型站点，不会出现此问题。所有站点都在同一台服务器上-版本1.8.1的三个站点和版本1.6.2的大站点

我们将站点缓存从memcache切换到Redis，然后添加了一个cronjob来每12小时转储一次缓存。它从每天一次崩溃到大约4-5天才崩溃。然后，我们对cronjob进行了调整，使其每6小时转储一次，自那以来一直没有下降（至今已经3-4天了）。我们或托管公司都无法跟踪实际问题，但这似乎对我们来说是一个可行的解决方案。希望能对某人有所帮助。

我今天早上添加了AmpersandHQ调试代码，并且刚刚在2分钟内发生了“前端控制器达到100个路由器匹配迭代”的异常，发生了大约75次。但是这一次，大概是因为调试代码没有保存损坏的缓存条目，该站点仍在正常运行，而没有所有人都获得异常（我没有刷新缓存）。

我尚未对此进行调查，但是rupture-cache.log包含：

2015-11-22T03:42:42+00:00 DEBUG (7):
#0 app/code/core/Mage/Core/Model/App.php(1147): Mage_Core_Model_Cache->save('<admin><design>...', 'config_global_s...', Array, NULL)
#1 app/code/core/Mage/Core/Model/Config.php(552): Mage_Core_Model_App->saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#2 app/code/core/Mage/Core/Model/Config.php(474): Mage_Core_Model_Config->_saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#3 app/code/core/Mage/Core/Model/App.php(421): Mage_Core_Model_Config->saveCache()
#4 app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#5 app/Mage.php(683): Mage_Core_Model_App->run(Array)
#6 index.php(87): Mage::run('', 'store')
#7 {main}

这是在Magento 1.7.0.2上的，该版本具有Redis缓存和AmpersandHQ的SUPEE-4755补丁。

2015年12月2日更新：以下是完整堆栈跟踪的另一个错误：

2015-12-02T20:02:27+00:00 DEBUG (7):
#0 app/code/local/Mage/Core/Model/App.php(1156): save('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#1 app/code/local/Mage/Core/Model/Config.php(552): saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#2 app/code/local/Mage/Core/Model/Config.php(474): _saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#3 app/code/local/Mage/Core/Model/App.php(430): saveCache()
#4 app/code/local/Mage/Core/Model/App.php(343): _initModules()
#5 app/Mage.php(683): run(Array)
#6 index.php(87): run('', 'store')

数周以来，我们在各个Magento CE网站上都遇到了同样的问题。但是，这里发布的建议均无济于事。经过数周令人沮丧的调试会议之后，我们终于设法解决了这一问题。

总而言之，我们发现问题是由于SUPEE-6788补丁，Magento <1.9.2.0和PHP> = 5.5.22的组合造成的，潜在的攻击者甚至安全扫描程序都可以按需关闭站点。我们已经在博客上发布了完整的详细信息，包括修复程序。我真正希望这能帮助其他遭受同样问题困扰的可怜人。

自发布SUPEE6788以来，我们一直在遇到此问题以及我们的网站，似乎对xmlrpc Web服务的欺诈性调用可能导致缓存损坏。

由于我们不使用前端服务器+应用SUPEE 4755，因此我们阻止了前端服务器进行的Web服务调用，我会及时通知您。