【Problembeskrivelse】 Når brukere bruker APPEN, sitter siden veldig fast, og de klikker tilfeldig, fordi grensesnittet ikke gjør gjentatte innsendinger, det vil være flere identiske forespørsler, i tjenestelaget setter ikke én tråd inn fullført, og den andre tråden sjekker tom. Så jeg satte også inn en. Opprinnelig hadde alle én, men en selger hadde tre, noe som resulterte i forretningslogikkfeil. For behandling av ondsinnede innsendinger kan det gjøres i front-end-delen, og det kan også finnes modne løsninger i back-end-delen.
【Løsning】1. Bruk unikhetsbegrensninger for å løse idempotensproblemet for transaksjoner, sett unikhetsbegrensninger, og hvis det oppstår et scenario med gjentatte commits, vil unntak fra unikhetsbegrensninger bli kastet på databasenivå, og forretningslogikken vil ikke bli ødelagt. Unikhetsbegrensninger på sammensetningen av flere felter er også akseptable.
Innloggingen med hyperkoblingen er synlig.
Ovenstående er for å lage anti-duplikatinnstillinger på databasenivå.
2. Realiser anti-dupliseringsinnstillinger på kodenivå. Mange ganger sies det at unikhetsbegrensningen i databasen vil påvirke effektiviteten av datainnsetting, fordi hver innsetting krever en vurdering på databasenivå. Derfor, ut fra kodenivået, er vanlig praksis på kodenivå å velge først og deretter sette inn, men hvis det er et scenario med høy samtidighet, vil det fortsatt være gjentatte commits. Du kan legge til synkronisert i logikkoden, slik at i situasjoner med høy samtidighet vil velge først og deretter sette inn i kraft. Men effektiviteten er ikke høy, og parallellen blir seriel. DCL-låsemekanismen kan brukes. (Har du funnet ut at metoden for å lage et enkelt objekt i kopieringsmodus er veldig lik, først vurder om objektet eksisterer, hvis det ikke eksisterer, lag det, ellers ikke lag det), den naturlige DCL-låsemekanismen er mer effektiv.
#分布式锁 Distribuerte låser kan også brukes til å løse problemet, som ofte brukes av Redis og Zookeeper. Denne delen forklarer hvordan man implementerer distribuerte låser ved bruk av Redis. Det finnes en setNx-kommandooperasjon i Redis, hvis den ikke eksisterer, er det en settverdi, og 1 returneres. Hvis den eksisterer, setter den seg ikke, og returnerer 0. Ved å bruke enkelttrådingsfunksjonen i Redis, gjøres høy-samtidighetsscenen om til en seriell gjennom meldingskøen. Det finnes imidlertid fallgruver med distribuerte låser, så du må være oppmerksom.
Innloggingen med hyperkoblingen er synlig. 3. MVCC-mekanisme?
3.1 Hva er MVCC-mekanismen? MVCC er en flerversjons samtidighetskontrollmekanisme.
3.2 Hvilke problemer kan løses? Låsemekanismen kan kontrollere samtidige operasjoner, men systemoverheaden er stor, og MVCC kan i de fleste tilfeller erstatte radlåser, noe som kan redusere systemoverhead og forbedre ytelsen.
Innloggingen med hyperkoblingen er synlig.
4. Det er også et problem med idempotens i meldingene
For eksempel, hvordan forhindre gjentatt konsum av meldinger?
I meldingsmellomvaren i MQ må disse forstås og forstås.
|