Модель для системы планирования - PullRequest
Новая
       9

Модель для системы планирования

2 голосов
/ 16 марта 2010

Мы создали систему планирования для контроля назначений наших клиентов. это Система аналогична той, которая используется Prometric для планирования экзамена. Главный Проблемы: гарантия отсутствия перепланирования, поддержка по крайней мере одного сто тысяч назначений в месяц и позволяют увеличить / уменьшить вместимость испытательного центра легко.

Мы разработали следующий дизайн на основе векторов емкости. Мы предположили, что Каждое назначение требует не менее пяти минут. Вектор состоит из 288 слоты (24 часа * 12 слотов в час), каждый из которых представлен одним байтом. вектор позволяет системе представлять до 255 встреч каждые пять минут. Используемая информация состоит из двух векторов: один для хранения Емкость испытательного центра (НОМИНАЛЬНАЯ ЕМКОСТЬ) и другая для хранения использованной емкости (ИСПОЛЬЗОВАННАЯ ЕМКОСТЬ) . Для восстановления текущей емкости (CURRENT CAPACITY) система берет НОМИНАЛЬНУЮ ЕМКОСТЬ тестирования и вычитает ИСПОЛЬЗОВАННУЮ ЕМКОСТЬ.

База данных имеет следующую структуру:

НОМИНАЛЬНАЯ ЕМКОСТЬ

Номинальная вместимость представляет собой производительность в рабочие дни (пн-пт). 

| 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 CAPACITY) и увеличивает соответствующий байт.

Система работает хорошо, но мы предвидим проблемы с конкуренцией, если количество встреч увеличивается слишком сильно.

Есть ли у кого-нибудь лучшая / другая модель для этой проблемы или предложения по улучшить это?

Мы подумали, чтобы избежать раздоров, поднакопив представление вектор в час и переход к оптимистичной стратегии блокировки. Например: 

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

Таким образом, не нужно блокировать строку и уменьшать количество событий столкновения.

1 Ответ

0 голосов
/ 29 марта 2014

Вот одна идея:

Вы можете использовать оптимистическую блокировку с вашим текущим дизайном. Вместо использования отдельного номера версии или отметки времени для проверки того, была ли изменена вся строка, сохраните памятку из массива used_capacity при чтении строки. Вы блокируете только обновление, в это время вы сравниваете только модифицированный байт слота, чтобы увидеть, было ли оно обновлено. Если нет, вы можете встроить новое значение в этот один элемент, не изменяя другие, тем самым сохраняя изменения в других слотах, выполняемых другими процессами с момента вашего начального чтения.

Это также должно работать для набора смежных байтов для встреч продолжительностью более 5 минут.

Если при первом чтении вы знаете, о каких слотах идет речь, вы можете просто сохранить начальный индекс массива и значимые значения вместо всего массива.

...