mboost-dp1
SKAT
Coney (1) skrev:Hvis det ikke tog længere tid at fikse det så undrer det mig at man ikke bare valgte den sikre løsning til at starte med??
Det har været en tanketorsk. Det er den slags fejl man lave når man er grøn udvikler, og sådan nogle tror jeg ikke arbejdet på den del af systemet.
Begyndere tror ofte at Murphys lov ikke gælder. Men på et aktivt system er det et spørgsmål om tid. De der "én gang ud af en million" vil altså ske før eller siden.
Jeg bruger også tit den slags tidskoder, men jeg smider altid ét eller andet unikt ind i samme forbindelse, eksempelvis en email-adresse, et brugernavn, brugerens ip-adresse, session-id eller lign.
På den måde ville jeg få noget der fx minder om
[email protected]
1257490757-testbruger
1257490757-194.82.72.24
1257490757-545544488775
i stedet for bare 1257490757 (som der er en meget minimal risiko for, at flere brugere får)
Det er ikke så svært :-)
Men ja, det er en ærlig fejl...
På den måde ville jeg få noget der fx minder om
[email protected]
1257490757-testbruger
1257490757-194.82.72.24
1257490757-545544488775
i stedet for bare 1257490757 (som der er en meget minimal risiko for, at flere brugere får)
Det er ikke så svært :-)
Men ja, det er en ærlig fejl...
#6 Jeg tror mere at problemet er, at webserveren som giver ud disse tidskoder til at identificere den enkelte session, ikke har været med som en del af systemdesignet, hvilket er helt normalt.
Man har simpelthen gået ud fra at sådan en fejl ikke kunne opstå på webserveren.
Det er vel nærmere en tekniker / opsætningsfejl end programmering. Men programmøerne burde også havde lavet et ekstra check alligevel.
Man har simpelthen gået ud fra at sådan en fejl ikke kunne opstå på webserveren.
Det er vel nærmere en tekniker / opsætningsfejl end programmering. Men programmøerne burde også havde lavet et ekstra check alligevel.
Coney (6) skrev:Så burde det simpelthen fremgå af systemdesignet at den kode skal være unik...
Hvordan vil du garantere at en stump data er unik? Med mindre man bruger et stykke dedikeret hardware, der kun kan benyttes af én tråd af gangen, så er det meget svært. Og hvis man laver ressourcen så der kun er én der kan læse af gangen, så går det (med al sandsynlighed) ud over performance.
#3 det er ikke en ærlig fejl.. Det er amatør agtig at benytte tiden som en unikt id, det må man aldrig regne med, det er logisk.
#7 tvivler nu på at webserveren bruger denne metode til at identificere sine sessioner, så tror jeg problemet ville være kommet frem i lyset i før, om muligheden for at brugere overtager hinandens sessioner hvis man logger ind på samme tid. Og desuden ville det være mega nemt at hijacke andres sessioner.
#8 det behøver vel kun være unikt for hver enkelte webserver.
#7 tvivler nu på at webserveren bruger denne metode til at identificere sine sessioner, så tror jeg problemet ville være kommet frem i lyset i før, om muligheden for at brugere overtager hinandens sessioner hvis man logger ind på samme tid. Og desuden ville det være mega nemt at hijacke andres sessioner.
#8 det behøver vel kun være unikt for hver enkelte webserver.
Angelenglen (3) skrev:Jeg bruger også tit den slags tidskoder, men jeg smider altid ét eller andet unikt ind i samme forbindelse, eksempelvis en email-adresse, et brugernavn, brugerens ip-adresse, session-id eller lign.
Selvom du mindsker chancen for, at 2 (eller flere) bruger har den samme "kode" - Så har du lige lavet en "SKAT". Rigtig mange computere, optræder på nettet med samme IP, da de ligger bag en NAT. Selvom chancen er MEGET lille, så kan 2 bruger med samme offentlige IP, godt logge sig på, på samme mikrosekund.
Angelenglen (3) skrev:Men ja, det er en ærlig fejl...
Ja.
HAHA!! nice ;)
Det jeg ser, er at de ikke har lavet intervallet lille nok ;)
Rent praktisk ville man ikke kunne få t ens id'er, hvis intervallet er så lille, at der ikke kan genereres to ens, og ja, vi taler interval på nanosekunder, hvis der arbejdes med single thread proces på en GHz cpu ;)
Og den plan vil ikke fungere, så snart vi kommer over i multicore med flere threads. Så kan to folk altid logge samtidig på.. i teorien ;)
Det jeg ser, er at de ikke har lavet intervallet lille nok ;)
Rent praktisk ville man ikke kunne få t ens id'er, hvis intervallet er så lille, at der ikke kan genereres to ens, og ja, vi taler interval på nanosekunder, hvis der arbejdes med single thread proces på en GHz cpu ;)
Og den plan vil ikke fungere, så snart vi kommer over i multicore med flere threads. Så kan to folk altid logge samtidig på.. i teorien ;)
Jeg har oplevet i flere virksomheder, at man bruger timestamp som "unik" id på mainframes.
Jeg har hørt, men vil ikke hænges op på det, at det var en idé der blev født i TDC for mange mange år tilbage, og resten af DK har så bare sagt "sikke en smart idé - det vil vi også "
Det er så noget vi kan hygge os med at rette op på nu :)
Jeg har hørt, men vil ikke hænges op på det, at det var en idé der blev født i TDC for mange mange år tilbage, og resten af DK har så bare sagt "sikke en smart idé - det vil vi også "
Det er så noget vi kan hygge os med at rette op på nu :)
ulrikl (9) skrev:#3 det er ikke en ærlig fejl.. Det er amatør agtig at benytte tiden som en unikt id, det må man aldrig regne med, det er logisk.
Beklager, tastefejl fra min side, der skulle have stået "ærgelig fejl" og ikke "ærlig fejl".
Så kan jeg lære ikke at skrive poster her, og snakke i telefon samtidig ;-)
DusteD (14) skrev:Det var alligevel en amatørfejl af kaliber. :D
Ja helt vildt. Jeg synes godt nok det var en elendig fejl, det første jeg tænker når man skal lave et id er at det skal være unik, det siger så også at de ikke har en primary key, eller uniq field i databasen. Hvis de nu havde lavet det, ville timekoden stadig virke - den ene af dem, ville nok bare få en fejl.
Hmm... Jeg kan lige som fornemme på det hele, at jeg sidder med de meget få promiller af software udviklere i verden der lever i sus og dus herinde. Jeg mener folk der kan udvikle så komplekse app uden at lave fejl...Det er godt nok flot.
Vi kan hurtigt blive enige om at det burde have været en fejl der ikke skulle have opstået. Men har selv siddet med software udvikling i 12år nu. Men jeg laver da også stadig fejl en gang imellem... Man har vel også sine dage hvor hovedet ikke kører 100%? Eller er det kun os mennesker der har det sådan?
Vi kan hurtigt blive enige om at det burde have været en fejl der ikke skulle have opstået. Men har selv siddet med software udvikling i 12år nu. Men jeg laver da også stadig fejl en gang imellem... Man har vel også sine dage hvor hovedet ikke kører 100%? Eller er det kun os mennesker der har det sådan?
Cyrack (8) skrev:Hvordan vil du garantere at en stump data er unik? Med mindre man bruger et stykke dedikeret hardware, der kun kan benyttes af én tråd af gangen, så er det meget svært. Og hvis man laver ressourcen så der kun er én der kan læse af gangen, så går det (med al sandsynlighed) ud over performance.
Jamen jeg vil da bare lave et tjek under login for at se om der er en klient med samme kode online pt... Er der det sendes den nye klient retur med en fejlmeddelelse og må generere en ny kode... Det behøver ikke være så sindsygt indviklet, og for at være helt ærligt så skal et system som det her bare være i orden på den front... Det er bare ikke godt nok...
shadowsurfer (10) skrev:Rigtig mange computere, optræder på nettet med samme IP, da de ligger bag en NAT.
Det har du ret i, hvorfor jeg oftest bruger session-id.
Så skal det være to brugere, der bruger samme browser-instans (altså på samme computer) i samme mikrosekund.
Den tror jeg ikke helt på.
For mig at se vil det altid være en fejl at bruge systemclocken til ID.
Ville altid selv bruge et unikt løbenummer, alternativt skal systemet lukkes hvergang uret skal stilles.
Arbejder selv med programmering for medicom industrien, og her kan det slå folk ihjel.
Håber ikke det er standarden i resten af programmet.
Ville altid selv bruge et unikt løbenummer, alternativt skal systemet lukkes hvergang uret skal stilles.
Arbejder selv med programmering for medicom industrien, og her kan det slå folk ihjel.
Håber ikke det er standarden i resten af programmet.
#13
timestamp er en meget praktisk "unik" nøgle for en udvikler. Laver man random tal, så er man nødt til hver gang at kigge hele sin database igennem for at sikre at den ikke tidligere er blevet gennereret. Hvorimod timestamp altid er fortløbende, og derfor aldrig kommer igen. Derudover er den stort set altid tilgængelig uanset hvilken sprog eller udviklingsværktøj man bruger.
men som udvikler skal man bare selv sørge for at den ikke bruges vigtige steder, eller der sørges for den forbliver unik.
timestamp er en meget praktisk "unik" nøgle for en udvikler. Laver man random tal, så er man nødt til hver gang at kigge hele sin database igennem for at sikre at den ikke tidligere er blevet gennereret. Hvorimod timestamp altid er fortløbende, og derfor aldrig kommer igen. Derudover er den stort set altid tilgængelig uanset hvilken sprog eller udviklingsværktøj man bruger.
men som udvikler skal man bare selv sørge for at den ikke bruges vigtige steder, eller der sørges for den forbliver unik.
#22
Problemet er bare, at det ikke er unikt. De implenenteringer jeg har set, hvor man har brugt timestamt, er som unik id i en db2 tabel. Hvorfor man har valgt det frem for at bruge autoincrement, der garantere at nøglen er unik, er mig en gåde ...
Og en random nøgle der er da helt hen i skoven, hvis man bagefter blive nødt til at checke at den ikke er blevet brugt før.
Problemet er bare, at det ikke er unikt. De implenenteringer jeg har set, hvor man har brugt timestamt, er som unik id i en db2 tabel. Hvorfor man har valgt det frem for at bruge autoincrement, der garantere at nøglen er unik, er mig en gåde ...
Og en random nøgle der er da helt hen i skoven, hvis man bagefter blive nødt til at checke at den ikke er blevet brugt før.
18# Men er vi enige og at sådan noget vigtigt som login transaktionen, er ikke noget man sidder og kaster sammen mandag imens man stadig har lidt tømmermænd.
Da jeg er menneske ved jeg at jeg også begår fejl, derfor ville jeg nok have designet den del af systemet først, og kigget det igennem sammen med nogle andre.
Da jeg er menneske ved jeg at jeg også begår fejl, derfor ville jeg nok have designet den del af systemet først, og kigget det igennem sammen med nogle andre.
excentrikkeren (21) skrev:Ville altid selv bruge et unikt løbenummer...
Ja, vi er helt enige om at nummeret skal være unikt (det er hele pointen), men har du overvejet konsekvensen ved at bruge løbenumre?
Jeg ved naturligvis ikke hvilken type systemer, du arbejder med, men hvis du anvender løbenumre mod en database, så skal du hele tiden få databasen til at søge på maksimal værdi og lægge én til. Ja, databasen kan sikkert vedligeholde de max. nummer, men det ændrer ikke ved at arbejdet skal udføres.
Derudover skal man tænke på, at hvis to parallele klienter forsøger at indsætte en række samtidigt, hvilket ikke er usandsynligt på f.eks. SKAT's side (jeg antager her, at de på peak har -ret- mange brugere online), så kan den ene få samme løbenummer som den anden - indsættelsen af data vil dog fejle for nr. 2, og han kan så søge en ny nøgle og indsætte...
Min point er, at det vil virke, og det vil være sikkert. Men jeg ville gøre mig nogle kraftige overvejelser omkring typen af system, før jeg vælger en sådan løsning. Jeg er bange for, at det ikke vil performe særligt godt med mange parallele handlinger.
http://en.wikipedia.org/wiki/GUIDUnbound (22) skrev:timestamp er en meget praktisk "unik" nøgle for en udvikler.
Ikke timestamps :p
Synes der er mange der knævrer om performance ved at lave et synkroniseret unikt løbenr.
Det er altså på ingen måde et problem, det er så uhyggeligt lille en del af den samlede processeringstid for en request der vil gå med at assigne det her nr at risikoen for at skulle vente det der nano sekund på at en anden får snøvlet sig færdig med at tage en nummer er næsten nul og konsekvensen når det sker er praktisk ikke eksisterende.
Nu har jeg arbejdet med højt belastede meget samtidige systemer i nogen år efterhånden og tildelingen af et unik nr. er altså ikke noget problem før vi bevæger os ud i nogle systemer der er mindst titusinde gange så store som SKAT, og så er det altså ikke sværere end at segmentere sine numre så man har mere end en serie at tage fra.
En fejl som den SKAT har lavet her lugter langt væk af manglende erfaring og viden omkring samtidighed, og mit gæt vil være at der er et hav af samtidighedsproblemer i deres system, som heldigvis viser sig så sjældent at systemet fungerer i praksis.
Det er altså på ingen måde et problem, det er så uhyggeligt lille en del af den samlede processeringstid for en request der vil gå med at assigne det her nr at risikoen for at skulle vente det der nano sekund på at en anden får snøvlet sig færdig med at tage en nummer er næsten nul og konsekvensen når det sker er praktisk ikke eksisterende.
Nu har jeg arbejdet med højt belastede meget samtidige systemer i nogen år efterhånden og tildelingen af et unik nr. er altså ikke noget problem før vi bevæger os ud i nogle systemer der er mindst titusinde gange så store som SKAT, og så er det altså ikke sværere end at segmentere sine numre så man har mere end en serie at tage fra.
En fejl som den SKAT har lavet her lugter langt væk af manglende erfaring og viden omkring samtidighed, og mit gæt vil være at der er et hav af samtidighedsproblemer i deres system, som heldigvis viser sig så sjældent at systemet fungerer i praksis.
Jeg tror at udvikleren har stukket Skat en lille hvid løgn. Det er altså temmeligt usandsynligt at 2 brugere får samme nøgle, hvis nøglen generes med mikrosekunder som præcision: 2009-06-11:12:00:00:123456 er ganske præcist.
Mon ikke udvikleren har opdatet at han har glemt mikrosekunderne i hans nøgler, skyndt sig at rette fejlen og så bare sagt at nu er der en unik identifier på nøglen?
Jeg kender da mere end én udvikler der kunne finde på at sige sådan.
Mon ikke udvikleren har opdatet at han har glemt mikrosekunderne i hans nøgler, skyndt sig at rette fejlen og så bare sagt at nu er der en unik identifier på nøglen?
Jeg kender da mere end én udvikler der kunne finde på at sige sådan.
synchronized int sessionCnt;
int getNewId() {
return sessionCnt++;
}
Hvor svært kan det være? Ja, det går ud over performance at der kun er en tråd der kan tilgå en variabel af gangen, men nok ikke særligt meget i dette tilfælde, da det vel ikke kan tage særligt mange cycles at inkrementere et tal med 1. Og det lille performancetab er nok godt givet ud i situationer som denne.
Jeg mindes et system som havde løst det på en interessant måde.
Et tilfældigt id genereres.
Hvis id'et allerede er i databasen, start forfra.
Det virkede fint i test. Gæt hvad der sker med svartiden, når 50% af id'erne er i brug. Eller 90%.
Det positive er, at man kigger på sagen inden man løber helt tør for id'er.
Et tilfældigt id genereres.
Hvis id'et allerede er i databasen, start forfra.
Det virkede fint i test. Gæt hvad der sker med svartiden, når 50% af id'erne er i brug. Eller 90%.
Det positive er, at man kigger på sagen inden man løber helt tør for id'er.
#32 Du har sandsynligvis også simplificeret problemet en hel del. Det skal sandsynligvis være unikt på tværs af flere webservere og måske endda flere database servere.
Måske deres tidsbaseret id er deres forsøg på at lave en simpel løsning, der ikke kræver for meget synkronisering mellem serverne.
Måske deres tidsbaseret id er deres forsøg på at lave en simpel løsning, der ikke kræver for meget synkronisering mellem serverne.
Jamen så har man bare ID-generatoren på en enkelt server, som de andre kalder.spectual (34) skrev:Du har sandsynligvis også simplificeret problemet en hel del. Det skal sandsynligvis være unikt på tværs af flere webservere og måske endda flere database servere.
I forhold til hvad? .NET?Windcape (35) skrev:Performanstabet ved at bruge Java er det største problem i den kode der!
Mr.Weasel (11) skrev:Er det ikke derfor man normalt bruger UUIDer til den slags?
Jo det er det da ;) UUID/GUID... Øhm sjovt nok der ikke er nogen der tænker på en caching server - såsom MS Velocity.
Troede efterhånden at n-Tier også var blevet dagligdag i web verdenen såsom f.eks. Amazon's services.
kr00z0r (36) skrev:Jamen så har man bare ID-generatoren på en enkelt server, som de andre kalder.
Sandt, og det vil sikkert også virke det meste af tiden, men der er nogle problemstillinger, der ikke er taget højde for.
F.eks. skal alle sessions, der skal have genereret sådan et ID, lave et kald til denne maskine. Jeg siger ikke, at det ikke kan virke, men det kan give en flaskehals.
Hvis systemet er tilpas vigtigt (og det vurderer jeg, at SKAT's systemer er), så kan du ikke tillade dig at have 'en enkelt server' til at gøre noget som helst. Det er en single point of faillure, og går den ned, så er der ikke nye sessioner, der åbnes. Øv øv... Så smider vi den i et cluster (aktiv - passiv ud fra denne case), men så stiger kompleksiteten voldsomt, for hvordan sikrer man den tilstand generatoren er i, sendes videre til ny server uden duplikering af nøgler...
Jeg kan godt forstå, at der sker sådan en fejl engang imellem, for der er mange faldgrupper, og som ansat i IT-branchen ved jeg også godt at nogle beslutninger skal træffes hurtigt, og så er der større fare for fejl. Det positive er jo, at fejlen blev rettet hurtigt og der er (sandsynligvis) ikke sket den store skade - det er trods alt en usandsynlig fejl...
#40 etc.: Ok, kan godt se det kan blive lidt mere indviklet end først antaget. Jeg er glad for at de systemer jeg koder hidtil har været små nok til at køre på en enkelt server, og ikke har været mere vigtige end at hvis den fejlede så måtte brugerne vente på at den blev genstartet.
Men jeg tvivler dog på at Skat synes det er livsvigtigt at deres systemer har en oppetid på 99,999999999%. Det er jo trods alt det offentlige. ;)
Men jeg tvivler dog på at Skat synes det er livsvigtigt at deres systemer har en oppetid på 99,999999999%. Det er jo trods alt det offentlige. ;)
Hvor virker det da bare ENORMT tåbeligt at lave et login på baggrund af et tidspunkt.
Godt nok må man sige at sandsynligheden er minimal, men når noget i teorien kan ske ( og nu også i virkeligheden ) må man da bare ikke lave det på den måde. Helt til grin.
Men godt de er blevet klogere .....
Godt nok må man sige at sandsynligheden er minimal, men når noget i teorien kan ske ( og nu også i virkeligheden ) må man da bare ikke lave det på den måde. Helt til grin.
Men godt de er blevet klogere .....
Regus (43) skrev:Mht. til flere servere så kan man bare give dem hver deres serie at tildele IDer fra, behøver altså ikke blive kompliceret
Det bliver stadig mere kompliceret end bare at have én server til at spytte dem ud. Hvem styrer f.eks., hvad der sker, når en af serverne løber tør for numre i den serie? Uanset hvad svaret er, tilfører det noget nyt, der kan gå galt... Murphy anyone?
Der er ingen af de problemstillinger, der er taget op her, der ikke kan løses. Der er heller ikke én løsning, der er mere rigtig eller forkert end en anden set ud fra et generelt synspunkt. Problemet med at sidde og være klog her, er at vi ikke kender de problemstillinger, der ligger bag SKAT's system. Ja, de har implementeret en løsning, der viste sig ikke at virke, men betyder det, at nogle af de gode forslag herinde ikke har været overvejet og er blevet afvist?
Jeg har gjort det her en del (det har været og er til dels stadig mit job), og det er rigtigt nemt at tage en beslutning. Det er bare rigtigt svært at tage den rigtige beslutning i et større perspektiv. Det kan godt være at den simple løsning er perfekt for nu, men om 6 mdr. hvor din kunde fussionerer med/opkøber et andet firma og måden systemet bliver brugt på ændrer sig, har man så stadig valgt den rigtige løsning? Man behøver ikke tage højde for den slags, men det sender sgu et godt signal til kunden at sige, at man har...
Hvis det her var nemt, var der nok ikke så mange, der kunne leve af det ;-D
#44: Hvis du har en 64-bit integer og du bruger de første 2 bytes til at betegne server-serien (hermed kan vi dele systemet ud over 65536 servere), så har vi stadig 2^48 id'er tilbage til hver enkelt server - hvilket er 281.474.976.710.656 sessions pr. server.
Lad os sige at den enkelte server opretter 10.000 sessions i sekundet i gennemsnit, så løber vi tør om:
2 ^ 48 / 10.000 / 60 / 60 / 24 / 365 = 892 år :-)
Jeg tror dit problem er ret hypotetisk :)
Lad os sige at den enkelte server opretter 10.000 sessions i sekundet i gennemsnit, så løber vi tør om:
2 ^ 48 / 10.000 / 60 / 60 / 24 / 365 = 892 år :-)
Jeg tror dit problem er ret hypotetisk :)
Jeg mindes at man, når man designer ticket IDs ofte benytter mindst 2 - og gerne flere faktorer.
De mest populære (som jeg kan huske) er:
Tid (brugt)
Primtal (ej brugt - antaget)
Unikt ID baseret på land, kundetype eller anden sær data umiddelbart tilgængelig uden yderligere operation som SQL-forespørgelser (ej brugt - antaget)
Hash-tricks o.l. (ej brugt - antaget)
Dette skulle gerne sætte sandsynligheden så langt ned - selv på systemer med flere tusinde brugere (endda millioner) - at det bliver gående mod umuligt (men, selvfølgelig ikke 100%). :-)
De mest populære (som jeg kan huske) er:
Tid (brugt)
Primtal (ej brugt - antaget)
Unikt ID baseret på land, kundetype eller anden sær data umiddelbart tilgængelig uden yderligere operation som SQL-forespørgelser (ej brugt - antaget)
Hash-tricks o.l. (ej brugt - antaget)
Dette skulle gerne sætte sandsynligheden så langt ned - selv på systemer med flere tusinde brugere (endda millioner) - at det bliver gående mod umuligt (men, selvfølgelig ikke 100%). :-)
#47: Hm - så du vil have en central database hvor hver server henter deres ID'er fra, også markerer SQL-serveren dette ID som "brugt"?
Det kan man også - men der kan stadig forekomme fejl - plus for god kotume skal du have to DB-servere, også kommer synkroniseringsfejl pludselig ind i billedet.
Dette er selvfølgelig uden at tænke på at du mister performance ved at skulle lave en SQL-forespørgelse, fremfor at lave noget programmatisk.
Så, begge løsninger er valide; De har hver deres fordele og ulemper.
"Min" løsning (som selvfølgelig ikke er min) er hurtig, men kompliceret at lave, holde styr på og forstå, og et forholdsvist lavt fejlforhold, mens
"Din" løsning er en anelse langsommere, nem at lave, holde styr på og forstå, og har et meget lavt fejlforhold (men har dog et).
Det kan man også - men der kan stadig forekomme fejl - plus for god kotume skal du have to DB-servere, også kommer synkroniseringsfejl pludselig ind i billedet.
Dette er selvfølgelig uden at tænke på at du mister performance ved at skulle lave en SQL-forespørgelse, fremfor at lave noget programmatisk.
Så, begge løsninger er valide; De har hver deres fordele og ulemper.
"Min" løsning (som selvfølgelig ikke er min) er hurtig, men kompliceret at lave, holde styr på og forstå, og et forholdsvist lavt fejlforhold, mens
"Din" løsning er en anelse langsommere, nem at lave, holde styr på og forstå, og har et meget lavt fejlforhold (men har dog et).
#48
Nej hvorfor skulle jeg dog bruge et centralt system??
Du indeler bare en 64 bit int i nogle segmenter, et segment pr server og så lægger de bare én til i en synkroniseret metode hver gang de skal bruge en ny ID og viola unikke ID'er.
og som mstify pointerer er 64 bit rigeligt til at håndtere 65.000 servere under et totalt urealistisk højt load i næsten 1000 år, det skulle vist være tilstrækkeligt til langt de fleste systemer.
Så min løsning er lynende hurtig, giver ID'er på sølle 8 byte og garanterer at de er unikke over hele mit system.
Nej hvorfor skulle jeg dog bruge et centralt system??
Du indeler bare en 64 bit int i nogle segmenter, et segment pr server og så lægger de bare én til i en synkroniseret metode hver gang de skal bruge en ny ID og viola unikke ID'er.
og som mstify pointerer er 64 bit rigeligt til at håndtere 65.000 servere under et totalt urealistisk højt load i næsten 1000 år, det skulle vist være tilstrækkeligt til langt de fleste systemer.
Så min løsning er lynende hurtig, giver ID'er på sølle 8 byte og garanterer at de er unikke over hele mit system.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund