2 votes

Modèle pour un système d'ordonnancement

Nous avons construit un système de planification pour contrôler les rendez-vous de nos clients. Ce système système est similaire à celui utilisé par Prometric pour programmer un examen. Les principaux principales préoccupations sont les suivantes : garantir qu'il n'y a pas de surprogrammation, prendre en charge au moins cent mille rendez-vous. au moins cent mille rendez-vous par mois et permettre d'augmenter/diminuer facilement la capacité du centre d'examen.

Nous avons conçu la conception suivante basée sur les vecteurs de capacité. Nous avons supposé que chaque rendez-vous nécessite au moins cinq minutes. Un vecteur est composé de 288 créneaux (24 heures * 12 créneaux par heure), chacun étant représenté par un octet. Le site vecteur permet au système de représenter jusqu'à 255 rendez-vous toutes les cinq minutes. L'information utilisée est composée de deux vecteurs : un pour stocker la la capacité du centre d'examen (CAPACITÉ NOMINALE) et une autre pour stocker la capacité utilisée (CAPACITÉ UTILISÉE) . Pour récupérer la capacité actuelle (CAPACITÉ ACTUELLE) le système prend la CAPACITE NOMINALE du test et soustrait la CAPACITE UTILISEE.

La base de données a la structure suivante :

CAPACITÉ NOMINALE

La capacité nominale représente la capacité pour les jours ouvrables (lun-ven).

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

CAPACITÉ UTILISÉE

Ce tableau enregistre la capacité utilisée pour chaque jour / centre de test.

| 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

Après que le client a choisi le centre de test et une date, le système présente les créneaux disponibles en effectuant le calcul suivant. Par exemple :

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

Si le client décide de prendre un rendez-vous, le système verrouille l'option choisie. jour choisi (une ligne dans le tableau # CAPACITE UTILE) et augmente l'octet correspondant.

Le système fonctionne bien pour l'instant, mais nous prévoyons des problèmes de contention si les nombre de rendez-vous augmente trop.

Est-ce que quelqu'un a un meilleur/un autre modèle pour ce problème ou des suggestions pour l'améliorer ?

Nous avons pensé à éviter la contestation en submergeant la représentation d'un vecteur en heure et en passant à une stratégie de verrouillage optimiste. Par exemple :

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

De cette façon, il ne sera pas nécessaire de verrouiller une rangée et de réduire les événements de collision.

0voto

NaturalData Points 81

Voici une idée :

Vous pouvez utiliser le verrouillage optimiste avec votre conception actuelle. Au lieu d'utiliser un numéro de version ou un horodatage distinct pour vérifier si la ligne entière a été modifiée, enregistrez un souvenir du tableau used_capacity lorsque la ligne est lue. Vous ne verrouillez que lors de la mise à jour, auquel moment vous comparez juste l'octet modifié de la rangée pour voir s'il a été mis à jour. Si ce n'est pas le cas, vous pouvez intégrer la nouvelle valeur dans ce seul élément sans modifier les autres, conservant ainsi les modifications des autres slots effectuées par d'autres processus depuis votre lecture initiale.

Cela devrait fonctionner aussi bien sur un ensemble d'octets adjacents pour les rendez-vous de plus de 5 minutes.

Si vous connaissez le(s) slot(s) en question lors de la lecture initiale, alors vous pouvez simplement enregistrer l'index du tableau de départ et les valeurs saillantes au lieu du tableau entier.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X