Życie Bez Transakcji

Obsługa transakcji właściwości ACID ale mimo, że nie ma transakcji w MongoDB, mamy operacje atomowe. Operacje atomowe oznaczają, że kiedy pracujesz nad jednym dokumentem, praca ta zostanie zakończona, zanim ktokolwiek inny zobaczy ten dokument. Zobaczą wszystkie zmiany, które wprowadziliśmy, albo żadnej z nich. Korzystając z operacji atomowych, często można osiągnąć to samo, co my, korzystając z transakcji w relacyjnym baza danych. Powodem jest to, że w relacyjnej bazie danych musimy wprowadzać zmiany w wielu tabelach. Zazwyczaj tabele, które muszą być połączone, a więc chcemy to zrobić wszystko na raz. Aby to zrobić, ponieważ istnieje wiele tabel, będziemy musieli rozpocząć transakcję i zrobić wszystkie te aktualizacje, a następnie zakończyć transakcję. Ale z MongoDB, będziemy osadzać dane, ponieważ mamy zamiar pre-join to w dokumentach i są te bogate dokumenty, które mają hierarchię. Często możemy / align = "left" / Na przykład w przykładzie na blogu, jeśli chcieliśmy upewnić się, że zaktualizowaliśmy post na blogu atomicznie, możemy to zrobić, ponieważ możemy zaktualizować cały post na blogu jednocześnie. Gdzie jakby to było kilka tabel relacyjnych, prawdopodobnie musielibyśmy otworzyć transakcję, abyśmy mogli zaktualizować kolekcję postów i kolekcji komentarzy.

Więc jakie są nasze podejścia, które możemy przyjąć MongoDB, aby przezwyciężyć brak transakcji?

• restrukturyzacja - zrestrukturyzować kod tak, abyśmy pracowali w ramach jednego dokumentu i wykorzystywali operacje atomowe, które oferujemy w tym dokumencie. A jeśli to zrobimy, to zazwyczaj jesteśmy gotowi.
• implementacja w oprogramowaniu - możemy zaimplementować blokowanie w oprogramowaniu, tworząc sekcję krytyczną. Możemy zbudować test, test i ustawić za pomocą find I modify. W razie potrzeby możemy zbudować semafory. I w pewnym sensie tak działa większy świat. Jeśli się nad tym zastanowimy, jeśli jeden bank musi przelać pieniądze do innego banku, nie żyją w tym samym systemie relacyjnym. I każdy z nich często ma własne relacyjne bazy danych. I muszą być w stanie koordynować tę operację, nawet jeśli nie możemy rozpocząć i zakończyć transakcji w tych systemach baz danych, tylko w ramach jednego systemu w jednym banku. Więc na pewno jest sposób w oprogramowaniu, aby obejść problem.
• tolerować - końcowe podejście, które często działa w nowoczesnych aplikacjach internetowych a inne aplikacje, które biorą w ogromnej ilości danych jest po prostu tolerować trochę niespójności. Przykładem może być to, że jeśli mówimy o kanale znajomych na Facebook ' u, nie ma znaczenia, czy wszyscy widzą aktualizację ściany jednocześnie. Jeśli okey, jeśli jedna osoba jest kilka uderzeń w tyle przez kilka sekund i dogonić. Często w wielu projektach systemowych nie ma krytycznego znaczenia, aby wszystko było idealnie spójne i aby każdy miał idealnie spójny i ten sam widok na baza danych. Więc możemy po prostu tolerować trochę niekonsekwencji, która jest trochę tymczasowa.

Update, findAndModify, $addToSet (w ramach aktualizacji) & $push (w ramach aktualizacji) operacje działają atomowo w ramach jednego dokumentu.

Od wersji 4.0, MongoDB będzie miał WIELODOKUMENTOWE transakcje ACID. Plan polega na tym, aby najpierw umożliwić te w zestawie replik, a następnie sharded clusters. Transakcje w MongoDB będą przypominać transakcje, które programiści znają z relacyjnych baz danych - będą wielotematyczne, z podobną semantyką i składnią(jak start_transaction i commit_transaction). Co ważne, zmiany w MongoDB, które umożliwiają transakcje, nie wpływają na wydajność obciążeń, które nie wymagają oni.

Po Więcej szczegółów zobacz tutaj.

Przejdźmy do rzeczy: jeśli integralność transakcji jest musi, to nie używaj MongoDB, ale używaj tylko komponentów w systemie obsługujących transakcje. Niezwykle trudno jest zbudować coś na komponencie, aby zapewnić podobną do kwasu funkcjonalność Dla komponentów niezgodnych z kwasem. W zależności od indywidualnych przypadków użycia sensowne może być rozdzielenie akcji na akcje transakcyjne i nietransakcyjne...

W czym problem? MongoDB może dokonywać aktualizacji atomowych tylko w jednym dokumencie. W poprzednim przepływie może się zdarzyć, że jakiś błąd wkrada się i wiadomość zostanie zapisana w bazie danych, ale saldo użytkownika nie zostanie zmniejszone i / lub transakcja nie zostanie zalogowana.

Prawdziwym problemem jest to, że użytkownik może wykorzystać stan rasy i wysłać więcej wiadomości, niż pozwala na to jego równowaga. Dotyczy to również RDBMS, chyba że robisz wysyłanie SMS-ów wewnątrz transakcji z blokowaniem pola równowagi (co byłoby wielkim wąskim gardłem). Jako możliwym rozwiązaniem dla MongoDB byłoby użycie findAndModify najpierw do zmniejszenia salda i sprawdzenia go, jeśli jest ujemne, uniemożliwienie wysłania i zwrotu kwoty (przyrost atomowy). Jeśli wynik jest pozytywny, Kontynuuj wysyłkę, a w przypadku niepowodzenia zwróć kwotę. Można również zachować kolekcję historii salda, aby pomóc naprawić / zweryfikować pole salda.

Projekt jest prosty, ale trzeba obsługiwać transakcje płatności, co utrudnia całość. Tak więc, na przykład, złożony system portalowy z setkami kolekcji (forum, czat, reklamy itp...) jest pod pewnym względem prostsze, bo jeśli stracisz wpis na forum lub czacie, nikogo to naprawdę nie obchodzi. Jeśli z drugiej strony przegrasz transakcję płatniczą, to jest to poważny problem.

Tak więc, jeśli naprawdę chcesz mieć projekt pilotażowy dla MongoDB, wybierz taki, który jest prosty w , że szacunek.

Transakcje są nieobecne w MongoDB z ważnych powodów. To jedna z tych rzeczy, które sprawiają, że MongoDB jest szybszy.

W Twoim przypadku, jeśli transakcja jest koniecznością, mongo wydaje się nie pasować.

Może być RDMBS + MongoDB, ale to doda złożoności i utrudni zarządzanie i obsługę aplikacji.

To chyba najlepszy blog jaki znalazłem dotyczący implementacji funkcji transakcyjnej dla mongodb .!

Flaga synchronizacji: najlepsza do kopiowania danych z dokumentu głównego

Kolejka Zadań: bardzo ogólny cel, rozwiązuje 95% przypadków. Większość systemów i tak musi mieć co najmniej jedną kolejkę zadań!

Commit dwufazowy: ta technika zapewnia, że każda jednostka zawsze ma wszystkie informacje potrzebne do uzyskania spójnego stanu

Logowania: najbardziej solidne technika, idealna dla systemów finansowych

Wersjonowanie: zapewnia izolację i obsługuje złożone struktury

Przeczytaj to, aby uzyskać więcej informacji: https://dzone.com/articles/how-implement-robust-and

Jest późno, ale myślę, że to pomoże w przyszłości. Używam Redis do tworzenia kolejki , aby rozwiązać ten problem.

• Wymagania:
  Poniższy obrazek pokazuje, że 2 akcje muszą być wykonywane jednocześnie, ale faza 2 i faza 3 Akcji 1 muszą zostać zakończone przed rozpoczęciem fazy 2 Akcji 2 lub odwrotnie (faza może być żądaniem REST api, żądaniem bazy danych lub wykonaniem kodu javascript...).

• Jak pomoc w kolejce ty
  Queue upewnij się, że każdy kod blokowy pomiędzy lock() i release() w wielu funkcjach nie będzie działał w tym samym czasie, spraw, aby był izolowany.

  function action1() {
    phase1();
    queue.lock("action_domain");
    phase2();
    phase3();
    queue.release("action_domain");
  }
  
  function action2() {
    phase1();
    queue.lock("action_domain");
    phase2();
    queue.release("action_domain");
  }
  

• Jak zbudować kolejkę
  Skupię się tylko na tym, jak uniknąć wyścigu conditon podczas budowania kolejki na stronie zaplecza. Jeśli nie znasz podstawowej idei kolejki, przyjdź tutaj .
  Poniższy kod pokazuje tylko koncepcję, trzeba wdrożyć w poprawny sposób.

  function lock() {
    if(isRunning()) {
      addIsolateCodeToQueue(); //use callback, delegate, function pointer... depend on your language
    } else {
      setStateToRunning();
      pickOneAndExecute();
    }
  }
  
  function release() {
    setStateToRelease();
    pickOneAndExecute();
  }
  

Ale potrzebujesz isRunning() setStateToRelease() setStateToRunning() odizoluj to samo albo znów staniesz w obliczu rasy. W tym celu wybieram Redis dla ACID cel i skalowalność.
Redis dokument mówi o transakcji:

Wszystkie polecenia w transakcji są serializowane i wykonywane kolejno. Nigdy nie może się zdarzyć, że wniosek złożony przez innego klient jest obsługiwany w trakcie realizacji Redis transakcja. Gwarantuje to, że polecenia są wykonywane jako pojedyncza izolowana operacja.

P/S:
Używam Redis, ponieważ mój serwis już go używa, możesz użyć dowolnego innego sposobu izolacji wsparcia, aby to zrobić.
action_domain w moim kodzie jest powyżej, gdy potrzebujesz tylko działania 1 wywołania przez użytkownika a blok działania 2 Użytkownika A, nie blokuj innego użytkownika. Pomysł jest umieścić unikalny klucz do blokady każdego użytkownika.

Transakcje są już dostępne w MongoDB 4.0. Próbka Tutaj

// Runs the txnFunc and retries if TransientTransactionError encountered

function runTransactionWithRetry(txnFunc, session) {
    while (true) {
        try {
            txnFunc(session);  // performs transaction
            break;
        } catch (error) {
            // If transient error, retry the whole transaction
            if ( error.hasOwnProperty("errorLabels") && error.errorLabels.includes("TransientTransactionError")  ) {
                print("TransientTransactionError, retrying transaction ...");
                continue;
            } else {
                throw error;
            }
        }
    }
}

// Retries commit if UnknownTransactionCommitResult encountered

function commitWithRetry(session) {
    while (true) {
        try {
            session.commitTransaction(); // Uses write concern set at transaction start.
            print("Transaction committed.");
            break;
        } catch (error) {
            // Can retry commit
            if (error.hasOwnProperty("errorLabels") && error.errorLabels.includes("UnknownTransactionCommitResult") ) {
                print("UnknownTransactionCommitResult, retrying commit operation ...");
                continue;
            } else {
                print("Error during commit ...");
                throw error;
            }
       }
    }
}

// Updates two collections in a transactions

function updateEmployeeInfo(session) {
    employeesCollection = session.getDatabase("hr").employees;
    eventsCollection = session.getDatabase("reporting").events;

    session.startTransaction( { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } } );

    try{
        employeesCollection.updateOne( { employee: 3 }, { $set: { status: "Inactive" } } );
        eventsCollection.insertOne( { employee: 3, status: { new: "Inactive", old: "Active" } } );
    } catch (error) {
        print("Caught exception during transaction, aborting.");
        session.abortTransaction();
        throw error;
    }

    commitWithRetry(session);
}

// Start a session.
session = db.getMongo().startSession( { mode: "primary" } );

try{
   runTransactionWithRetry(updateEmployeeInfo, session);
} catch (error) {
   // Do something with error
} finally {
   session.endSession();
}