为具有不同地域用户的应用程序设置后端数据库答案

【问题标题】：backend db setup for an app with geographically diverse users为具有不同地域用户的应用程序设置后端数据库
【发布时间】：2009-06-24 06:08:07
【问题描述】：

我工作的内部开发软件通过我们的 devexpress orm (XPO) 直接连接到我们办公室的 mysql 服务器。性能很棒。

我们正在开设另一个办事处......越野。性能：不太好。要求是软件在两个办公室中的响应速度与在本办公室中一样，并且来自一个办公室的数据可以“实时”提供给另一个办公室。

这种规模的东西对我来说是全新的。我并不反对聘请一位以前做过类似事情的顾问，但我想先对这些选项有一个很好的了解。我确信这是一种常见的情况。

复制是个好主意吗？速度够快吗？够稳定吗？

如果复制不起作用，是否有解决这种情况的开发模式？

哎呀，我什至不知道如何标记这个，所以如果有人知道更好......请随时重新标记

编辑 > 数据详情

我想，与某些企业软件相比，我们不会移动大量数据。该软件管理客户帐户、约会等，每个用户每分钟处理大约 2-5 个单独的帐户（目前为 50 个用户，计划扩展后为 200-400 个），每次更新数据。

当办公室 A 中的某人为办公室 B 中的某人创建约会时，实时方面开始发挥作用，理想情况下，该约会需要能够立即查看其详细信息（

【问题讨论】：

【解决方案1】：

如果不创建无法解决和破坏的复制冲突，您不能在两个方向上使用异步复制。

因此，您的明显选择是使用读/写分离 - 让应用程序从（只读）本地数据库执行非关键读取，并将所有写入定向到主数据库。这样做的缺点是，这意味着您无法立即回读自己的写入内容。

MySQL 复制并不完美，需要一些努力来设置和持续监控来维护；您必须经常检查从站中的数据是否相同。一些查询被错误地复制；您需要了解这些并避免它们。

【讨论】：

【解决方案2】：

你们中的一个最后的手段当然是确保所有繁重的工作都在后台线程中完成，这样 GUI 线程就不会被阻塞。

拥有实时数据取决于数据，我错过了详细的描述，例如每个请求我们谈论多少数据（即对象有多大），您的互联网连接速度有多快（可能是瓶颈？），mysql服务器和您控制的所有基础设施是否配置良好？数据的静态/动态程度如何，如果实时数据一天发生一次变异，或者一天发生数十亿次变异，这对于“解决方案”很重要

【讨论】：

已更新以阐明正在使用的数据的种类和数量，以及它的变异频率。我们目前使用的网络连接是 5mb 的线路，这可能是慢点，但到目前为止，它只支持远程办公室的 3 个用户。