调度系统模型

Question

我们已经建立了一个调度系统来控制客户的预约。这个系统类似于普罗米克公司用来安排考试的系统。主要考虑的问题是:保证不存在过度调度，每月至少支持10万次预约，并允许轻松地增加/减少测试中心的容量。

我们设计了以下基于容量矢量的设计。我们假定每次约会至少需要五分钟。向量由288个时隙(每小时24小时*12个时隙)组成，每个时隙由一个字节表示。该向量允许系统每5分钟最多代表255次预约。所使用的信息由两个向量组成:一个用于存储测试中心容量(标称容量)，另一个用于存储已使用容量(使用容量)。为了恢复电流容量(电流容量)，系统采用测试标称容量并减去使用容量。

该数据库具有以下结构：

标称容量

名义容量代表工作日的能力(星期一-星期五)。

| TEST_CENTER_ID | NOMINAL_CAPACITY
| 1          | 0000001212121212....0000
| 2          | 0000005555555555....0000
...
| N          | 0000000000010101....0000

使用容量

此表存储每天/测试中心的使用容量。

| TEST_CENTER_ID | DATE       | USED_CAPACITY
| 1          | 01/01/2010 | 0000001010101010...0000
| 1          | 01/02/2010 | 0000000202020202...0000
| 1          | 01/03/2010 | 0000001010101010...0000
...
| 2          | 01/01/2010 | 0000001010101010...0000
...
| N          | 01/01/2010 | 0000000000000000...0000

客户端选择测试中心和日期后，系统将显示可用的时隙，并进行以下计算。例如：

TEST_CENTER_ID   1
DATE             01/01/2010
NOMINAL_CAPACITY 0000001212121212...0000
USED_CAPACITY    0000001010101010...0000
AVAILABLE_CAPAC  0000000202020202...0000

如果客户端决定安排约会，系统将锁定选定的日期(在# USED容量表中的一行)并增加相应的字节。

这个制度现在运作良好，但如果委任人数增加太多，我们预计会出现争拗的问题。

是否有人对此问题有更好的/另一种模式或改进建议？

为了避免这一争论，我们已经考虑过将向量的表示以小时为单位，并转换为乐观的锁定策略。例如：

| TEST_CENTER_ID | DATE       | USED_CAPACITY_0 | USED_CAPACITY_1 | ... | USED_CAPACITY_23
| 1             | 01/01/2010 | 000000101010    | 1010...         | ... | ...0000

这样就不需要锁定一行并减少碰撞事件。

Answer 1

这里有一个想法：

您可以在当前设计中使用乐观锁定。不要使用单独的版本号或时间戳来检查整个行是否已被修改，而是在读取行时保存used_capacity数组的一个备忘录。您只锁定update，此时您只需要比较修改过的槽字节，以查看它是否已被更新。如果没有，您可以将新值嵌入到该元素中，而无需修改其他元素，从而保留对其他进程自初始读取以来执行的其他插槽的修改。

对于超过5分钟的约会，这也应该适用于一组相邻的字节。

如果您在最初读取时知道有问题的时隙，那么您可以只保存起始数组索引和显式值，而不是整个数组。