【Probleembeschrijving】
Wanneer gebruikers de APP gebruiken, zit de pagina erg vast en klikken ze willekeurig, omdat de interface geen herhaalde inzendingen doet, er zijn meerdere identieke verzoeken in de servicelaag, één thread voegt niet compleet in en de andere thread controleert leeg. Dus heb ik er ook een geplaatst. Oorspronkelijk had iedereen er één, maar een verkoper had er drie, wat leidde tot fouten in de bedrijfslogica. Voor het verwerken van kwaadaardige inzendingen kan dit in het front-end gedeelte gebeuren, en er kunnen ook volwassen oplossingen zijn in het back-end gedeelte.
【Oplossing】1. Gebruik uniciteitsbeperkingen om het idempotentieprobleem van transacties op te lossen, set uniciteitsbeperkingen, en als er een scenario is van herhaalde commits, worden uitzonderingen op uniciteitsbeperkingen op databaseniveau gegooid en wordt de bedrijfslogica niet vernietigd. Uniekheidsbeperkingen op de samenstelling van meerdere velden zijn ook acceptabel.
De hyperlink-login is zichtbaar.
Bovenstaande is bedoeld om anti-duplicate instellingen op databaseniveau te maken.
2. Realiser anti-duplicatie-instellingen op codeniveau. Vaak wordt gezegd dat de uniciteitsbeperking van de database de efficiëntie van gegevensinvoeging beïnvloedt, omdat elke invoeging een oordeel op databaseniveau vereist. Daarom is de gebruikelijke praktijk op codeniveau om eerst te selecteren en dan in te voegen, maar als er een scenario met hoge gelijktijdigheid is, zullen er nog steeds herhaalde commits zijn. Je kunt gesynchroniseerd toevoegen aan de logicacode, zodat in scenario's met hoge gelijktijdigheid eerst selecteren en dan inserten effect hebben. Maar de efficiëntie is niet hoog, en de parallel wordt seriël. DCL-vergrendelingsmechanisme kan worden gebruikt. (Heb je gemerkt dat de methode om één object te maken in de kopieercase-modus erg vergelijkbaar is, beoordeel eerst of het object bestaat, als het niet bestaat, maak het dan aan, anders maak het niet), het natuurlijke DCL-vergrendelingsmechanisme is efficiënter.
#分布式锁
Gedistribueerde sloten kunnen ook worden gebruikt om het probleem op te lossen, wat vaak wordt gebruikt door Redis en Zookeeper. Deze sectie legt uit hoe gedistribueerde sloten geïmplementeerd kunnen worden met Redis.
Er is een setNx-commandobewerking in Redis; als die niet bestaat, is het een vaste waarde en wordt 1 teruggegeven. Als het bestaat, zet het zich niet en geeft 0 terug.
Met behulp van de single-threading-functie van Redis wordt de high-concurrency scene via de berichtwachtrij omgezet in een seriële versie.
Er zijn echter valkuilen bij gedistribueerde sloten, dus je moet goed opletten.
De hyperlink-login is zichtbaar.
3. MVCC-mechanisme?
3.1 Wat is het MVCC-mechanisme?
MVCC is een multiversie-gelijktijdigheidscontrolemechanisme.
3.2 Welke problemen kunnen worden opgelost?
Het vergrendelingsmechanisme kan gelijktijdige operaties regelen, maar de systeemoverhead is groot, en MVCC kan in de meeste gevallen sloten op rijniveau vervangen, wat de systeemoverhead kan verminderen en de prestaties kan verbeteren.
De hyperlink-login is zichtbaar.
4. Er is ook een probleem van idempotentie in berichten
Hoe voorkom bijvoorbeeld herhaaldelijk het consumeren van berichten?
In de berichtmiddleware in MQ moeten deze begrepen en begrepen worden.
|
Geplaatst op 04-12-2018 13:29:37
|
|
|
Huisbaas