具有不同地理位置的用户的应用程序的后端数据库设置
我工作的内部开发软件通过 devexpress orm (XPO) 直接连接到我们办公室的 mysql 服务器。 性能很棒。
我们将开设另一个办事处……跨国办事处。 性能：不是很好。 要求是软件在两个办公室中的响应速度与在该办公室中的响应速度相同，并且一个办公室的数据可以“实时”提供给另一个办公室。
这种规模的东西对我来说是全新的。 我并不反对聘请一位以前做过类似事情的顾问，但我想首先对这些选择有一个全面的了解。 我确信这是一种常见情况。
复制是个好主意吗？ 够快吗？ 够稳定吗？
如果复制不起作用，是否有解决这种情况的开发模式？
哎呀，我什至不知道如何标记它，所以如果有人更了解......请随时重新标记
编辑> > 有关数据的详细信息
我想，与某些企业软件相比，我们没有移动大量数据。 该软件管理客户帐户、约会等，每个用户每分钟处理大约 2-5 个单独的帐户（当前 50 个用户，计划扩展后为 200-400 个），每次更新数据。
当办公室 A 中的某人为办公室 B 中的某人创建约会时，实时方面就开始发挥作用，理想情况下，该约会需要能够立即（<2 分钟）查看其详细信息。 也就是说，每条记录通常每天最多只会发生 5 次变异。 但这只是我的怀疑； 我实际上没有任何关于我的使用统计数据。
The in-house developed software where I work connects directly to a mysql server here in our office via our devexpress orm (XPO). Performance is great.
We're opening another office... cross country. Performance: not so great. The requirement is that the software be as responsive in both offices as it is in this office and that the data from one office be available to the other 'in real time'.
Something of this scale is totally new to me. I'm not averse to bringing in a consultant who's done something like this before, but I'd like to get a good picture of the options first. I'm sure that this is a common situation.
Is replication a good idea? Is it fast enough? stable enough?
Are there development patterns that tackle this kind of situation if replication won't work?
Heck, I'm not even sure how to tag this, so if someone knows better... please, feel free to re-tag
EDIT > Details about the data
I guess, compared to some enterprise software, we're not moving lots of data. The software manages customer accounts, appointments etc. and each user works on about 2-5 separate accounts/minute (50 users currently, 200-400 after planned expansion), updating data each time.
The real-time aspect comes into play when someone in office A creates an appointment for someone in office B who, ideally, needs to be able to view its details near immediately (<2 mins). That said, each record usually only gets mutated a maximum of 5 times a day. But that's only what I suspect; I don't actually have any usage statistics on me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不能在两个方向上使用异步复制而不产生复制冲突，而复制冲突是不可能解决和破坏的。
因此，您显而易见的选择是使用读/写拆分 - 让应用程序从（只读）本地数据库执行非关键读取，并将所有写入定向到主数据库。 这样做的缺点是，这意味着您无法立即读回自己的写入。
MySQL复制并不完美，需要付出一些努力来设置和持续监控来维护； 您必须经常检查从站中的数据是否相同。 有些查询复制不正确； 你需要了解这些并避免它们。
You can't use asynchronous replication in both directions without creating replication conflicts which are impossible to resolve and break things.
Therefore, your obvious choice is to use read/write splitting - have the application do noncritical reads from a (readonly) local DB, and direct all writes to the master. The disadvantage of this is that it will mean that you can't immediately read back your own writes.
MySQL replication isn't perfect and requires some effort to set up and continuous monitoring to maintain; you must frequently check the data are the same in the slaves. Some queries get replicated incorrectly; you'll need to understand those and avoid them.
最后的手段之一当然是确保所有繁重的工作都在后台线程中完成，这样 GUI 线程就不会被阻塞。
拥有实时数据取决于数据，我错过了详细的描述，例如我们谈论每个请求有多少数据（即对象有多大），您的互联网连接速度有多快（可能是瓶颈？ ），您控制的 mysql 服务器和所有基础设施是否配置良好？ 数据的静态/动态程度如何，如果实时数据每天突变一次或每天突变无数次，这对于“解决方案”很重要
One of you're last resorts is of course to make sure that all heavy duty work is done in background threads such that the GUI thread is never blocked.
Having real-time data depends on the data, I miss a detailed description such as how much data are we talking about per request (i.e. how large are the objects), how fast is you're internet connection (could be the bottle neck?), is the mysql server and all infrastructure in between that you control well configured? How static/dynamic is the data, if the real-time data gets mutated one time a day or it gets mutated a zillion times a day is important for the "solution"