内存数据管理的最佳选择[关闭]

Question

背景： 我正在开发一个使用 Spring MVC 和 Angular 构建的基于 Web 的应用程序。我们有一个帮助台模块，座席用来为客户服务工作。该应用程序部署在单个服务器上。我们有一个工单锁定机制，即当一个代理打开一个工单开始处理它时，工单被锁定到该代理，这样其他代理就不能同时处理同一个工单。一旦代理关闭票证，其他代理就可以在需要时打开和更新。为了锁定票证以避免过多的数据库调用，我们实现了ConcurrentHashMap，这样每个人都可以使用相同的地图更新锁定票证，这绝对可以正常工作。

问题： 现在应用程序部署在两台不同的服务器上，这个ConcurrentHashMap 不起作用，因为 MAP 由每台服务器维护。如果用户正在使用节点 1 锁定票证，并且如果第二个用户的请求转到节点 2，则此方法将不起作用。为了避免这种情况，我们计划更改流程，以便我们可以避免此类问题。同时，我们不希望将此锁定细节直接保存到 DB 以避免 DB IO，因为它是应用程序非常频繁使用的区域。

选项 在进行了一些研发之后，我得到了我们可以实施的以下选项，同时牢记持久性。

1. 我们可以使用 MSSQL 或 Redis 实现 In-Memory 表概念
2. RabbitMQ
3. 我们可以实现一个将部署在单个节点上的 API，我们的两个服务器都将使用它来维护锁定票证，但我们仍然有两个问题，这个调用 API 会花费时间，第二个是它没有持久化数据，如果服务器重新启动，我们将丢失数据。

任何人都可以告诉我哪种方法应该适合上述情况以及如何实施它。我只需要一个启动。

提前致谢。

Answer 1

我认为你真正的问题是这样的：

为了避免过多的 DB 调用而锁定票证 [您决定不使用数据库]。

IMO，那是个错误。为获取票证上的“锁定”而进行的数据库调用不太可能导致过多的数据库调用。

在分析这一点时，您需要考虑某人希望开始处理工单的频率，以及由于有人已经在处理工单而导致失败的频率。我不知道您的用例详细信息，但如果后一个事件发生的频率超过每秒一次，我会感到非常惊讶。

如果您的数据库无法维持每秒一次“小型”数据库操作（最坏的情况！）用于锁定，那么它将无法维持涉及创建票证、代理更新票证、用户读取票证以及以此类推。

所以建议是：

1. 计算出票证锁定的实际数据库负载将是……相对于数据库需要执行的所有其他操作。

2. 如果它很小，只需返回数据库进行票证锁定。保持简单！

3. 如果它很大；要么：

   • 向上或向外扩展现有数据库；例如使用分片。无论如何，您似乎都需要这样做。这也应该为您提供使用现有数据库进行锁定的“空间”。

   • 为锁定创建单独的数据库服务器。它不太可能需要很大，而且我无法想象它需要非常快。 （见下文！！）

   • 使用您提出的解决方案之一。

---

但我的主要建议是避免过早优化的陷阱。您似乎正在为您认为在没有任何明确证据的情况下存在的瓶颈进行设计。例如：

“我们可以实现一个将部署在单个节点上的 API，并且我们的两个服务器都将使用它来维护锁定票证，但我们仍然有 [问题] 使用此调用 API 会花费时间.. 。”

除非花费的时间是几秒钟，否则这不太可能是一个真正的问题。最好的策略是首先以简单的方式实施系统，然后测量性能，以了解 1) 是否需要优化工作，以及 2) 完整 系统中真正的瓶颈在哪里。

在您的情况下，我怀疑用户是否会关心是否需要（比如说）1 秒而不是 2 秒才能被告知其他人已经在处理工单。

---

最后，使用现有的现成票务系统不是更简单吗？那里有很多。商业产品、开源、托管等。 （好吧，这可能为时已晚，因为听起来您正致力于从头开始实施自己的票务系统。但重新考虑您的策略可能还为时不晚。）