1

我们公司在管理其网站方面非常成功，包括所有业务逻辑和内容。然而，今天也有很多静态内容页面使用模板系统提供服务，模板系统将内容存储在文件系统上的序列化 PHP 对象中。

我们现在正在考虑使用“真正的”CMS，但是我们有一些要求可以或多或少地排除所有常见的嫌疑人。最重要的要求是我们的托管环境：

我们有两个完全独立的托管位置，并采用“无共享”方法进行故障转移。这两个位置都有单独的 MySQL 实例，它们是位于我们总部现场的主数据库的从属 ()。这两个位置都有一定数量的 Web 服务器，每个服务器都存储完整的网站（同样，用于故障转移）。

从这个架构中，自然会产生两种可能的方法： - 数据库驱动的 CMS，在我们的总部进行管理并复制到我们的托管位置（以及使用我们的文件同步过程复制的图像和内容） - 文件驱动的 CMS其中不仅附件，而且内容文件都使用我们的文件同步进行同步

数据库驱动的方法对我来说似乎更灵活，但是我们找不到在“本地管理读/写数据库并仅使用只读从属设备提供内容”中工作的 CMS。例如，通常的嫌疑人（Typo3）需要一个数据库来写入其日志记录和会话管理，因此不是一种选择。其他 CMS 似乎也有这个问题。

那么，长话短说，有没有（PHP/MySQL-）CMS 可以处理这个问题？有什么建议么？

如果 CMS 可以轻松地与我们的 Zend Framework 应用程序集成（反之亦然），则加分。

4

2 回答 2

3

你应该看看 Percona，这是一家 MySQL 性能公司，它把 MySQL 放在了类固醇上。轻松支持 Master/Master/Master 环境，无需更改 master 到 master 的自动增量值即可轻松实现。

他们有一个产品叫做，XtraDB Cluster。它是一个免费的产品，就像 MySQL 一样工作，安装方式相同，但在数据库级别处理集群并且做得非常好。

一旦您控制了数据库，您就可以在其中一台服务器上安装 CMS，进行更改，将其复制到所有其他服务器，您的整个环境就可以进行故障转移了。

于 2012-07-24T17:33:48.897 回答
2

根据您评论中添加的信息，我们似乎在谈论静态内容。

现有系统

据我所知，您已经有一个稳定的系统，可以部署静态内容。从这个意义上说，制造更复杂的情况是没有意义的。保持简单会在大多数情况下最适合您的需求。

根据您的需要，您可以在数据库同步或文件同步之间做出选择。

文件同步

如果您可以发送完全静态的所有内容，您的文件同步就会做得很好。虽然我在那里看到了一个问题。例如：如果您需要最新新闻项目列表，您还必须生成并同步它。当您使用数据库同步时，您只需执行所需的简单查询 SELECT * FROM news ORDER BY created_at DESC LIMIT 0,10。

同步动作的数量

另一点是您需要做的同步量。例如，如果您的后端有一个屏幕，其中包含 10 条新闻。作者创建了 3 个帖子并开始单击每个帖子的发布按钮。基本上，您的文件同步将在第一个之后开始同步。所以它应该首先同步新的新闻项目。然后它应该更新最新的新闻项目列表，然后同步那个。

如果他们开始很好地编辑，那可能会有点糟糕。因为这也需要在例如标题更改时完成。

数据库解决方案

这是数据库更擅长的地方，您只需更新记录，它就会到达那里。当新记录可用时，最新新闻部分将自行更新。

相关静态内容的问题

现在您遇到了一个问题：您必须确保您的流程分两步进行： 1. 同步图像和其他静态内容 2. 同步和/或发布新闻项目

否则，您将看到损坏的图像。例如，这可以通过以下方式完成： 确保新图像的同步直接开始。所以当它上传到CMS时。然后它将在新闻项目发布之前出现。您可以根据您的需要进行验证。

备择方案

由于这是静态内容，您可能能够更好地处理它。这将需要您的堆栈采用新技术，因此首先验证它是否真的需要。新闻项目是一个工作流程。因此，它的步骤彼此相邻。通常，对于工作流程，您可以使用队列。因此，您创建一个包含新新闻项目的队列、一个用于发布的队列、一个用于同步静态项目的队列等。

队列与缓存系统配合得很好。我认为有一个非常有趣的部分需要回顾。目前有强大的缓存系统可用，可以使内容可用并同步它们。它们基于这样一个事实，即您有许多服务器提供相同的内容。它们可能是完成工作的非常稳定且简单的解决方案。但如前所述，如果您还没有它们，请考虑是否要为您的堆栈添加新的复杂性。

于 2012-07-25T07:51:41.877 回答