Konsumpcja ze współdzielonego zasobu

W świecie usług telco (połączenia telefoniczne, użycie danych itd.) dla klientów biznesowych zdarzają się różne wydumane produkty. Zdarza się, że firma, która ma np. kilkuset pracowników kupuje jakieś współdzielone produkty typu pula X gigabajtów do wykorzystania na internet krajowy przez wszystkich pracowników. Pracownicy wykonują połączenia współbieżnie, które są rozliczane w czasie rzeczywistym i mamy do czynienia z konsumpcją z jednego zasobu. Problemem od strony technicznej jest "długie" czekanie na takim zasobie współdzielonym.

Prostym rozwiązaniem jest podejście typu:

// bierzemy z puli odpowiednio duży kawałek
resource.lock();
resource.reserve_chunk(BIG_ENOUGH);
resource.unlock);
...
// oddajemy niewykorzystaną część
resource.lock();
resource.return_unused(leftOvers);
resource.unlock();

Problemów jest co najmniej kilka:
a) "długa" kolejka do lock()

b) rezerwacja "dużych" kawałków może prowadzić do "wirtualnego" wyczerpania zasobu. Nieco przerysowany przykład:

• pula = 10MB, 10 sesji zarezerwuje po 1 MB
• 11. sesja nie ma z czego rezerwować, więc jest rozliczana za $
• 10 sesji zwraca po 0,5MB i pula ma 5MB
• klient jest nieszczęśliwy, że został naliczony, bo przecież miał jeszcze 5MB

c) mniejsze kawałki rezerwacji -> częstsze locki -> sesje czekają częściej

Na chwilę obecną myślę o rozbiciu zasobu na pulę pul (wodę z wiaderka rozlewamy do słoików), co powinno zmniejszyć długość kolejek (bo kolejka nie do wiaderka, a do słoika, których jest wiele) jak i pozwolić na zmniejszenie bloku rezerwacji (częstsze locki, ale w krótszej kolejce). Generuje to jednak kolejny problem. Taka pula pul powinna być samo organizująca się (jak jeden słoik będzie pusty, to trzeba by przelać wszystko do wiaderka i znowu rozlać po słoikach, ewentualnie mieć jakąś sprytną strukturę danych).

Jakieś ciekawe pomysły jak realizować konsumpcję ze współdzielonego zasobu przy dużej liczbie konsumentów, tak by:

1. minimalizować czas oczekiwania
2. minimalizować fałszywe "braki zasobu"

Dla uproszczenia można przyjąć, że klienci i zasoby są na jednej maszynie.

Założyć, że może się zdarzyć mały "deficyt" i przyjąć, że mogą być ujemny bilans. Tak np. masz w banku, że czasem możesz wejść w deficyt "przypadkowo". Wpisać ile tych pakietów może być "przypadkowo" na minusie w koszty i masz rozwiązanie bez locków.

Dzięki za inne spojrzenie, dobry materiał do przemyśleń. Na pierwszy rzut oka, wydaje mi się, że im dłużej rozwiązanie będzie działać na tej zasadzie tym większy utracony dochód operatora (dostęp do usług świadczony za free - ile będzie tego utraconego dochodu, to nie da się sensownie oszacować, bo każdy operator ma inną bazę klientów i różną charakterystykę użycia usług), ale koncept "deficytu" może być elementem jakiegoś "większego rozwiązania".

Zawsze możesz przenosić deficyt na następny miesiąc (czyli jak w miesiącu N okazało się, że deficytu było 3 MiB to w przyszłym zabierasz na starcie to 3 MiB jako już wykorzystane), lub zwyczajnie doliczyć "po cichu" parę mega, które może się "prześlizgnąć", i ich koszt dodać do kosztów pakietu jako całości.

Oczywiście to wszystko zakłada, że te "nadmiary" będą wyłapywane odpowiednio szybko, tak, że nie wygeneruje to astronomicznego transferu, przykładowo liczysz (bo to już statystyka), że średni "nadużycie" będzie nie większe niż 2% całości, bo synchronizujesz na tyle często, że to jest maks.