使用数据库作为通信总线时如何避免并发问题？
有些人告诉我，由于并发问题，我们应该避免多个应用程序读取/写入同一数据库。他们坚持让我相信，可靠的架构只允许单个应用程序访问数据库。我不知道这样的问题是由 READ 操作并发引起的，还是仅与 WRITE 操作有关。
我担心的是，对于某些系统（例如我正在开发的系统）来说，数据库是一种出色的通信总线。是否有关于如何在避免并发问题的同时做到这一点的指南？
Some people tell me that we should avoid multiple apps reading/writing to the same database, because of concurrency issues. They were insistent to the point where they convinced me that a solid architecture only allows a single application to access the database. I don't know if such problems arise from READ operations concurrency, or if they are related only to WRITE operations.
My concern is that the DB is an excelent communication bus for some systems, like the one I'm developing. Are there any guidelines about how to do that while avoiding concurrency issues?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
(1) 除非确实必要，否则不要使用数据库作为通信总线。鉴于可用的开源消息队列系统，我怀疑您确实需要这样做。
(2) 如果您有事务数据库，那么并发读写访问应该没问题，只要您的数据库具有必要的约束和触发器来强制执行数据完整性（并且所有应用程序都经过适当的测试以确保尽可能他们没有插入垃圾）。
(3) 如果您不理解(1) 或(2)，那么您还没有准备好使用数据库作为通信总线。去阅读有关数据库、并发和事务的内容。
(1) Do not use a database as a communication bus unless you really have to. Given the open source message queuing systems available, I doubt that you do need to.
(2) If you have a transactional database, then concurrent read and write access should be fine, as long as your database has the necessary constraints and triggers to enforce data integritry (and all applications are appropriately tested to ensure in so far as possible that they are not inserting garbage).
(3) If you did not understand (1) or (2), you are not ready to use a database as a communications bus. Go read about databases, concurrency, and transactions.