我正在开发一个在用户群和功能方面都有所增长的网站，以至于某些管理任务应该与公共网站分开。我想知道最好的办法是什么。
例如，该网站有一个很大的社交组件和一个公共销售界面。但与此同时，管理部分还有后台任务，批量上传处理，仪表板（长时间运行的查询）和客户关系工具，我希望不会受到公共交通高峰的影响（或影响公众 - 面对响应时间）。
该站点运行在一个相当标准的Rails / MySQL / Linux堆栈上，但我认为这更像是一个架构问题，而不是一个实现问题：主要是，如何在这些不同的应用程序之间保持数据和业务逻辑同步？
我正在评估的一些策略：
1）在另一台机器上创建面向公众的数据库的从属数据库。提取出所有模型和库代码，以便可以在应用程序之间共享。为管理界面创建新的控制器和视图。
我对复制的经验有限，甚至不确定它是否应该以这种方式使用（大部分时间我都看过它，它是用于扩展同一应用程序的读取功能，而不是具有多个不同的）。如果从站不在同一网络上，我也担心潜在的延迟问题。
2）创建新的更多任务/部门特定的应用程序，并使用面向消息的中间件来集成它们。我读了一段时间的企业集成模式，他们似乎主张分布式系统。 （或者，在某些情况下，基本的Rails风格的RESTful API功能可能就足够了。）但是，我有关于数据同步问题的噩梦以及这将带来的大规模重新架构。
3）两者的混合。例如，某些后台任务所需的唯一公共信息是只读完成时间或状态。将它放在一个完全独立的系统并将数据发送给公众是否有意义？同时，用户/组管理功能将在共享数据库的单独系统上运行？缺点是，这似乎保留了我对前两个问题的许多担忧，尤其是重新构建。
我确信答案将高度依赖于网站的特定需求，但我很想听听成功（或失败）的故事。
答案 0 :(得分：3)
据我所知，如果您确实希望确保面向公众的性能和管理性能不会相互影响，则必须在不同的服务器上使用单独的数据库。
关键是要充分了解在过程中涉及数据的位置和方式使用的数据。如果您可以这样做，那么尝试确定是否可以将一个数据库设置为“前导”数据库。这将是您的实时数据，而另一个数据库将是您的操作数据存储（ODS）。 ODS始终是您的实时数据的衍生产品。从实时数据更新ODS的过程可以间隔发生，既可以简化数据又可以进行额外处理，使其更适合使用ODS的应用程序。
现在，如果您发现这对于您当前的情况有很大的飞跃，您可以尝试并至少分离数据库中的数据，这样您就不会处理表锁等性能问题。如果您将来需要转移到类似ODS的ODS，它也可以是朝着正确方向迈出的一步。
答案 1 :(得分：0)
我不喜欢复制不需要的东西。我会标记什么是管理员，并将该部分构建为具有内部IP或不同端口的单独数据库。然后与公共站点建立外键关系以进行管理员访问。像索引表一样处理它将更容易管理而不是复制，并且当您不与遗留系统交谈时，API开发是一项不必要的任务。另外，为什么要在保持系统分离的情况下进行复制。 他们我的两分钱。