ProHoster > blog > Gweinyddiaeth > Cloi wedi'i ddosbarthu gan ddefnyddio Redis

Cloi wedi'i ddosbarthu gan ddefnyddio Redis

Hei Habr!

Heddiw, rydyn ni'n tynnu eich sylw at gyfieithiad o erthygl gymhleth am weithredu cloi dosbarthedig gan ddefnyddio Redis ac yn eich gwahodd i siarad am ragolygon Redis fel pwnc. Dadansoddiad o'r algorithm Redlock dan sylw gan Martin Kleppmann, awdur y llyfr "Cymwysiadau Llwyth Uchel", wedi'i roi yma.

Mae cloi gwasgaredig yn ddefnydd cyntefig defnyddiol iawn a ddefnyddir mewn llawer o amgylcheddau lle mae'n rhaid i wahanol brosesau weithio ar adnoddau a rennir mewn modd sy'n annibynnol ar ei gilydd.

Mae yna nifer o lyfrgelloedd a swyddi ar gael sy'n disgrifio sut i weithredu DLM (Rheolwr Clo Dosbarthedig) gan ddefnyddio Redis, ond mae pob llyfrgell yn cymryd agwedd wahanol ac mae'r gwarantau a ddarperir ganddynt yn eithaf gwan o gymharu Γ’'r hyn y gellir ei gyflawni gyda dyluniad ychydig yn fwy soffistigedig.

Yn yr erthygl hon byddwn yn ceisio disgrifio algorithm canonaidd amodol sy'n dangos sut i weithredu cloi gwasgaredig gan ddefnyddio Redis. Byddwn yn siarad am algorithm o'r enw Cochglo, mae'n gweithredu rheolwr clo dosbarthedig ac, yn ein barn ni, mae'r algorithm hwn yn fwy diogel na'r dull un-achos arferol. Gobeithiwn y bydd y gymuned yn ei ddadansoddi, yn rhoi adborth, ac yn ei ddefnyddio fel man cychwyn ar gyfer prosiectau mwy cymhleth neu amgen.

Gweithredu

Cyn symud ymlaen at y disgrifiad o'r algorithm, rydym yn darparu sawl dolen i weithrediadau parod. Gellir eu defnyddio ar gyfer cyfeirio.

Gwarantau Diogelwch ac Argaeledd

Rydyn ni'n mynd i fodelu ein dyluniad gyda dim ond tri eiddo rydyn ni'n meddwl sy'n darparu'r gwarantau lleiaf sydd eu hangen i ddefnyddio cloi dosbarthedig yn effeithiol.

  1. Eiddo diogelwch: Gwaharddiad ar y cyd. Ar unrhyw adeg benodol, dim ond un cleient all ddal y clo.
  2. Argaeledd Eiddo A: Dim terfynau amser. Mae bob amser yn bosibl caffael clo yn y pen draw, hyd yn oed os yw'r cleient a gloodd yr adnodd yn methu neu'n glanio ar segment disg gwahanol.
  3. Argaeledd Eiddo B: Goddefgarwch Nam. Cyn belled Γ’ bod y mwyafrif o nodau Redis yn rhedeg, mae cleientiaid yn gallu caffael a rhyddhau cloeon.

Pam nad yw gweithredu yn seiliedig ar adferiad methiant yn ddigon yn yr achos hwn
Er mwyn deall yr hyn yr ydym yn mynd i'w wella, gadewch i ni ddadansoddi'r sefyllfa gyfredol gyda'r mwyafrif o lyfrgelloedd cloi dosbarthedig yn seiliedig ar Redis.

Y ffordd symlaf o gloi adnodd gan ddefnyddio Redis yw creu allwedd yn yr enghraifft. Yn nodweddiadol, mae allwedd yn cael ei chreu gydag oes gyfyngedig, cyflawnir hyn gan ddefnyddio'r nodwedd dod i ben a ddarperir yn Redis, felly yn hwyr neu'n hwyrach caiff yr allwedd hon ei rhyddhau (eiddo 2 yn ein rhestr). Pan fydd angen i'r cleient ryddhau'r adnodd, mae'n dileu'r allwedd.

Ar yr olwg gyntaf, mae'r ateb hwn yn gweithio'n eithaf da, ond mae problem: mae ein pensaernΓ―aeth yn creu un pwynt o fethiant. Beth sy'n digwydd os bydd enghraifft y gwesteiwr Redis yn methu? Gadewch i ni ychwanegu caethwas wedyn! A byddwn yn ei ddefnyddio os na fydd y cyflwynydd ar gael. Yn anffodus, nid yw'r opsiwn hwn yn ymarferol. Drwy wneud hyn, ni fyddwn yn gallu gweithredu'n iawn yr eiddo allgΓ‘u cilyddol sydd ei angen arnom i sicrhau diogelwch, oherwydd mae dyblygu yn Redis yn anghydamserol.

Yn amlwg, mewn model o'r fath mae cyflwr hil yn digwydd:

  1. Cleient A yn caffael clo ar y meistr.
  2. Mae'r meistr yn methu cyn i'r mynediad allweddol gael ei drosglwyddo i'r caethwas.
  3. Mae'r dilynwr yn cael ei ddyrchafu'n arweinydd.
  4. Mae Cleient B yn cael clo ar yr un adnodd ag y mae A eisoes wedi'i gloi. TROSEDD DDIOGELWCH!

Weithiau mae'n gwbl normal mewn amgylchiadau arbennig, megis methiant, y gall llawer o gleientiaid ddal y clo ar yr un pryd. Mewn achosion o'r fath, gellir defnyddio datrysiad sy'n seiliedig ar atgynhyrchu. Fel arall, rydym yn argymell yr ateb a ddisgrifir yn yr erthygl hon.

Gweithredu cywir gydag un enghraifft

Cyn ceisio goresgyn diffygion y cyfluniad un enghraifft a ddisgrifir uchod, gadewch i ni ddeall sut i drin yr achos syml hwn yn iawn, gan fod yr ateb hwn yn ddilys mewn gwirionedd mewn cymwysiadau lle mae cyflwr hil yn dderbyniol o bryd i'w gilydd, a hefyd oherwydd blocio ar a enghraifft sengl yw'r sail a ddefnyddir yn yr algorithm dosbarthedig a ddisgrifir yma.

I gael clo, gwnewch hyn:

SET resource_name my_random_value NX PX 30000

Mae'r gorchymyn hwn yn gosod allwedd dim ond os nad yw'n bodoli eisoes (opsiwn NX), gyda chyfnod dilysrwydd o 30000 milieiliadau (opsiwn PX). Mae'r allwedd wedi'i osod i β€œmyrandomvalue" Rhaid i'r gwerth hwn fod yn unigryw ar draws pob cleient a phob cais clo.
Yn y bΓ΄n, defnyddir gwerth ar hap i ryddhau'r clo yn ddiogel, gyda sgript yn dweud wrth Redis: tynnwch yr allwedd dim ond os yw'n bodoli a'r gwerth sydd wedi'i storio ynddo yw'r union beth a ddisgwyliwyd. Cyflawnir hyn gan ddefnyddio'r sgript Lua ganlynol:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Mae hyn yn bwysig i atal clo sydd gan gleient arall rhag cael ei dynnu. Er enghraifft, efallai y bydd cleient yn cael clo, yna'n cael ei gloi mewn rhyw weithrediad sy'n para'n hirach na'r clo cyntaf (fel bod gan yr allwedd amser i ddod i ben), ac yn ddiweddarach yn tynnu'r clo yr oedd cleient arall wedi'i osod.
Nid yw defnyddio DEL syml yn ddiogel oherwydd gall cleient dynnu clo sydd gan gleient arall. Mewn cyferbyniad, wrth ddefnyddio'r sgript uchod, mae pob clo wedi'i β€œlofnodi” gyda llinyn ar hap, felly dim ond y cleient a'i gosododd yn flaenorol all ei dynnu.

Beth ddylai'r llinyn hap hwn fod? Rwy'n dyfalu y dylai fod yn 20 beit o /dev/urandom, ond gallwch ddod o hyd i ffyrdd llai costus o wneud y llinyn yn ddigon unigryw at eich dibenion chi. Er enghraifft, byddai'n iawn hadu RC4 gyda /dev/urandom ac yna cynhyrchu ffrwd ffug-hap ohono. Mae datrysiad symlach yn cynnwys cyfuniad o amser unix mewn cydraniad microsecond ynghyd Γ’'r ID cleient; nid yw mor ddiogel, ond mae'n debyg mai mater i'r dasg yw hi yn y rhan fwyaf o gyd-destunau.

Gelwir yr amser a ddefnyddiwn fel mesur o oes yr allwedd yn "oes clo". Y gwerth hwn yw faint o amser cyn i'r clo gael ei ryddhau'n awtomatig a faint o amser sydd gan gleient i gwblhau gweithrediad cyn y gall cleient arall gloi'r adnodd hwnnw yn ei dro, heb dorri gwarantau allgΓ‘u ar y cyd mewn gwirionedd. Mae'r warant hon wedi'i chyfyngu i ffenestr amser benodol yn unig, sy'n dechrau o'r eiliad y prynir y clo.

Felly rydym wedi trafod ffordd dda o gaffael a rhyddhau clo. Mae'r system (os ydym yn sΓ΄n am system heb ei dosbarthu sy'n cynnwys un enghraifft sydd bob amser ar gael) yn ddiogel. Gadewch i ni ymestyn y cysyniad hwn i system ddosbarthedig, lle nad oes gennym unrhyw warantau o'r fath.

Algorithm Redlock

Mae fersiwn ddosbarthedig yr algorithm yn rhagdybio bod gennym ni feistri N Redis. Mae'r nodau hyn yn gwbl annibynnol ar ei gilydd, felly nid ydym yn defnyddio atgynhyrchu nac unrhyw system gydlynu ymhlyg arall. Rydym eisoes wedi ymdrin Γ’ sut i gaffael a rhyddhau clo yn ddiogel ar un achos. Rydym yn cymryd yn ganiataol y bydd yr algorithm, wrth weithio gydag un enghraifft, yn defnyddio'r dull hwn yn union. Yn ein henghreifftiau rydym yn gosod N i 5, sy'n werth rhesymol. Felly, bydd angen i ni ddefnyddio meistri 5 Redis ar wahanol gyfrifiaduron neu beiriannau rhithwir i sicrhau eu bod yn gweithredu'n annibynnol ar ei gilydd i raddau helaeth.

I gaffael clo, mae'r cleient yn cyflawni'r gweithrediadau canlynol:

  1. Yn cael yr amser presennol mewn milieiliadau.
  2. Yn ddilyniannol yn ceisio cael clo ar bob achos N, gan ddefnyddio'r un enw allweddol a gwerthoedd ar hap ym mhob achos. Yng Ngham 2, pan fydd y cleient yn gosod clo fesul achos, mae'r cleient yn defnyddio oedi i'w gaffael sy'n ddigon byr o'i gymharu Γ’'r amser y caiff y clo ei ryddhau'n awtomatig ar Γ΄l hynny. Er enghraifft, os yw hyd y blocio yn 10 eiliad, yna gallai'r oedi fod yn yr ystod o ~5-50 milieiliad. Mae hyn yn dileu'r sefyllfa lle gallai'r cleient barhau i gael ei rwystro am amser hir wrth geisio cyrraedd nod Redis a fethwyd: os nad yw'r enghraifft ar gael, yna rydym yn ceisio cysylltu ag achos arall cyn gynted Γ’ phosibl.
  3. I gymryd clo, mae'r cleient yn cyfrifo faint o amser sydd wedi mynd heibio; I wneud hyn, mae'n tynnu o'r gwerth amser gwirioneddol y stamp amser a gafwyd yng ngham 1. Os a dim ond os oedd y cleient yn gallu cael y clo ar y mwyafrif o achosion (o leiaf 3), a chyfanswm yr amser a gymerodd i cael y clo, llai na hyd y clo, ystyrir bod y clo wedi'i gael.
  4. Os cafwyd clo, cymerir mai hyd y clo yw hyd y clo gwreiddiol llai'r amser a aeth heibio a gyfrifwyd yng ngham 3.
  5. Os bydd y cleient yn methu Γ’ chael y clo am ryw reswm (naill ai nid oedd yn gallu cloi achosion N/2+1, neu roedd hyd y clo yn negyddol), yna bydd yn ceisio datgloi pob achos (hyd yn oed y rhai yr oedd yn meddwl na allai rwystro ).

A yw'r algorithm yn anghydamserol?

Mae'r algorithm hwn yn seiliedig ar y rhagdybiaeth, er nad oes cloc wedi'i gydamseru y byddai'r holl brosesau'n gweithio arno, mae amser lleol ym mhob proses yn dal i lifo tua'r un cyflymder, ac mae'r gwall yn fach o'i gymharu Γ’ chyfanswm yr amser y mae'r clo rhyddhau yn awtomatig. Mae'r rhagdybiaeth hon yn debyg iawn i'r sefyllfa sy'n nodweddiadol ar gyfer cyfrifiaduron cyffredin: mae gan bob cyfrifiadur gloc lleol, a gallwn fel arfer gyfrif ar y ffaith bod y gwahaniaeth amser rhwng gwahanol gyfrifiaduron yn fach.

Ar y pwynt hwn, mae'n rhaid i ni lunio ein rheol eithrio cilyddol yn fwy gofalus: dim ond os yw'r cleient sy'n dal yr allanfeydd clo yn cael ei warantu yn ystod yr amser y mae'r clo yn ddilys (sicrhawyd y gwerth hwn yng ngham 3), namyn mwy o amser (cyfanswm ychydig). milieiliadau i wneud iawn am y gwahaniaeth amser rhwng prosesau).

Mae'r erthygl ddiddorol ganlynol yn dweud mwy am systemau o'r fath sy'n gofyn am gydlynu cyfnodau amser: Prydlesi: mecanwaith effeithlon i oddef bai ar gyfer cysondeb storfa ffeiliau dosbarthedig.

Rhowch gynnig arall arni ar fethiant

Pan fydd cleient yn methu Γ’ chaffael clo, rhaid iddo geisio eto ar Γ΄l oedi ar hap; gwneir hyn i ddad-gydamseru cleientiaid lluosog sy'n ceisio caffael clo ar yr un adnodd ar yr un pryd (a all arwain at sefyllfa "hollti-ymennydd" lle nad oes unrhyw enillwyr). Yn ogystal, po gyflymaf y bydd cleient yn ceisio cael clo ar y mwyafrif o achosion Redis, y culaf yw'r ffenestr lle gall sefyllfa hollt-ymennydd ddigwydd (a'r lleiaf yw'r angen am ailgeisiadau). Felly, yn ddelfrydol, dylai'r cleient geisio anfon gorchmynion SET i achosion N ar yr un pryd gan ddefnyddio amlblecsio.

Mae'n werth pwysleisio yma pa mor bwysig yw hi i gleientiaid sy'n methu Γ’ chaffael mwyafrif y cloeon ryddhau'r cloeon a gaffaelwyd (yn rhannol), fel nad oes rhaid iddynt aros i'r allwedd ddod i ben cyn y gellir caffael y clo ar yr adnodd eto. (er os bydd darnio rhwydwaith yn digwydd, a bod y cleient yn colli cysylltiad ag achosion Redis, yna mae'n rhaid i chi dalu cosb argaeledd wrth aros i'r allwedd ddod i ben).

Rhyddhewch y clo

Mae rhyddhau clo yn weithrediad syml sy'n gofyn yn syml am ddatgloi pob achos, ni waeth a yw'n ymddangos bod y cleient wedi cloi achos penodol yn llwyddiannus.

Ystyriaethau Diogelwch

A yw'r algorithm yn ddiogel? Gadewch i ni geisio dychmygu beth sy'n digwydd mewn gwahanol senarios.

I ddechrau, gadewch i ni dybio bod y cleient wedi gallu cael clo ar y mwyafrif o achosion. Bydd pob enghraifft yn cynnwys allwedd gyda'r un oes i bawb. Fodd bynnag, gosodwyd pob un o'r allweddi hyn ar amser gwahanol, felly byddant yn dod i ben ar wahanol adegau. Ond, os gosodwyd yr allwedd gyntaf ar amser nad yw'n waeth na T1 (yr amser a ddewiswn cyn cysylltu Γ’'r gweinydd cyntaf), a gosodwyd yr allwedd olaf ar amser nad yw'n waeth na T2 (yr amser y derbyniwyd yr ymateb o'r gweinydd olaf), yna rydym yn hyderus y bydd yr allwedd gyntaf yn y set sy'n dod i ben yn goroesi o leiaf MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. Bydd yr holl allweddi eraill yn dod i ben yn ddiweddarach, felly gallwn fod yn sicr y bydd pob allwedd yn ddilys ar yr un pryd am o leiaf yr amser hwn.

Yn ystod yr amser y mae'r rhan fwyaf o allweddi'n parhau'n ddilys, ni fydd cleient arall yn gallu caffael y clo, gan na all gweithrediadau N/2+1 SET NX lwyddo os yw bysellau N/2+1 eisoes yn bodoli. Felly, unwaith y bydd clo wedi'i gaffael, mae'n amhosibl ei gaffael eto ar yr un pryd (byddai hyn yn torri'r eiddo gwahardd cilyddol).
Fodd bynnag, rydym am sicrhau na all cleientiaid lluosog sy'n ceisio caffael clo ar yr un pryd lwyddo ar yr un pryd.

Os yw'r cleient wedi cloi'r mwyafrif o achosion am tua neu fwy na hyd y clo, bydd yn ystyried bod y clo yn annilys ac yn datgloi'r achosion. Felly, dim ond yr achos lle llwyddodd y cleient i rwystro'r mwyafrif o achosion mewn amser llai na'r dyddiad dod i ben y mae'n rhaid i ni ei ystyried. Yn yr achos hwn, ynghylch y ddadl uchod, yn ystod yr amser MIN_VALIDITY ni ddylai unrhyw gleient allu adennill y clo. Felly, bydd llawer o gleientiaid yn gallu cloi achosion N/2+1 yn yr un amser (sy'n dod i ben ar ddiwedd cam 2) dim ond pan fydd yr amser i gloi'r mwyafrif yn fwy na'r amser TTL, sy'n gwneud y clo yn annilys.

A allwch chi ddarparu prawf ffurfiol o ddiogelwch, nodi algorithmau tebyg sy'n bodoli eisoes, neu ddod o hyd i fyg yn yr uchod?

Ystyriaethau Hygyrchedd

Mae argaeledd system yn dibynnu ar dair prif nodwedd:

  1. Rhyddhau cloeon yn awtomatig (wrth i allweddi ddod i ben): Bydd allweddi ar gael eto yn y pen draw i'w defnyddio ar gyfer cloeon.
  2. Y ffaith bod cleientiaid fel arfer yn helpu ei gilydd trwy dynnu cloeon pan nad yw'r clo dymunol wedi'i gaffael, neu wedi'i gaffael a bod y swydd wedi'i chwblhau; felly mae'n debygol na fydd yn rhaid i ni aros i'r allweddi ddod i ben i adennill y clo.
  3. Y ffaith, pan fydd angen i gleient ail geisio caffael clo, ei fod yn aros am amser cymharol hirach na'r cyfnod sydd ei angen i gaffael y rhan fwyaf o gloeon. Mae hyn yn lleihau'r tebygolrwydd y bydd sefyllfa hollt-ymennydd yn codi wrth gystadlu am adnoddau.

Fodd bynnag, mae cosb argaeledd hafal i TTL y segmentau rhwydwaith, felly os oes segmentau cyffiniol, gall y gosb fod yn amhenodol. Mae hyn yn digwydd pryd bynnag y bydd cleient yn caffael clo ac yna'n rhwygo i segment arall cyn y gall ei ryddhau.

Mewn egwyddor, o ystyried segmentau rhwydwaith cyffiniol anfeidrol, gall system aros heb fod ar gael am gyfnod anfeidrol o amser.

Perfformiad, methu drosodd a fsync

Mae llawer o bobl yn defnyddio Redis oherwydd bod angen perfformiad gweinydd clo uchel arnynt o ran yr hwyrni sydd ei angen i gaffael a rhyddhau cloeon, a nifer y caffaeliadau/rhyddhau y gellir eu cwblhau fesul eiliad. Er mwyn bodloni'r gofyniad hwn, mae strategaeth i gyfathrebu Γ’ gweinyddwyr N Redis i leihau hwyrni. Strategaeth amlblecsio yw hon (neu "amlblecsio dyn tlawd", lle mae'r soced yn cael ei rhoi yn y modd di-flocio, yn anfon pob gorchymyn, ac yn darllen y gorchmynion yn ddiweddarach, gan dybio bod yr amser taith gron rhwng y cleient a phob achos yn debyg) .

Fodd bynnag, mae'n rhaid i ni hefyd ystyried yr ystyriaeth sy'n gysylltiedig Γ’ storio data hirdymor os ydym yn ymdrechu i greu model sy'n adfer yn ddibynadwy o fethiannau.

Yn y bΓ΄n, i egluro'r mater, gadewch i ni dybio ein bod yn ffurfweddu Redis heb unrhyw storfa ddata hirdymor o gwbl. Mae'r cleient yn llwyddo i rwystro 3 allan o 5 achos. Mae un o'r achosion y llwyddodd y cleient i'w rhwystro yn cael ei ailgychwyn, ac ar hyn o bryd mae yna 3 achos eto ar gyfer yr un adnodd, y gallwn ei rwystro, a gall cleient arall, yn ei dro, rwystro'r enghraifft wedi'i hailgychwyn, gan dorri'r eiddo diogelwch sy'n yn tybio detholusrwydd cloeon.

Os ydych chi'n galluogi data ymlaen llaw (AOF), bydd y sefyllfa'n gwella ychydig. Er enghraifft, gallwch chi hyrwyddo gweinydd trwy anfon y gorchymyn SHUTDOWN a'i ailgychwyn. Gan fod gweithrediadau dod i ben yn Redis yn cael eu gweithredu'n semantig yn y fath fodd fel bod amser yn parhau i lifo hyd yn oed pan fydd y gweinydd wedi'i ddiffodd, mae ein holl ofynion yn iawn. Mae hyn yn normal cyn belled Γ’ bod cau arferol yn cael ei sicrhau. Beth i'w wneud rhag ofn y bydd toriadau pΕ΅er? Os yw Redis wedi'i ffurfweddu'n ddiofyn, gyda fsync yn cydamseru ar ddisg bob eiliad, yna mae'n bosibl na fydd gennym ein allwedd ar Γ΄l ailgychwyn. Yn ddamcaniaethol, os ydym am warantu diogelwch clo yn ystod unrhyw achos o ailgychwyn, dylem alluogi fsync=always yn y gosodiadau ar gyfer storio data hirdymor. Bydd hyn yn lladd perfformiad yn llwyr, i lawr i lefel y systemau CP a ddefnyddir yn draddodiadol i weithredu cloeon dosbarthedig yn ddiogel.

Ond mae'r sefyllfa yn well nag y mae'n ymddangos ar yr olwg gyntaf. Mewn egwyddor, mae diogelwch yr algorithm yn cael ei gadw oherwydd pan fydd yr enghraifft yn cael ei ailgychwyn ar Γ΄l methiant, nid yw bellach yn cymryd rhan mewn unrhyw glo sy'n weithredol ar hyn o bryd.

Er mwyn sicrhau hyn, y cyfan sydd angen i ni ei wneud yw sicrhau, ar Γ΄l methiant, nad yw'r enghraifft ar gael am gyfnod ychydig yn fwy na'r uchafswm TTL a ddefnyddiwn. Fel hyn byddwn yn aros tan y dyddiad dod i ben a rhyddhau awtomatig yr holl allweddi a oedd yn weithredol ar adeg y methiant.

Gan ddefnyddio ailgychwyniadau gohiriedig, mae'n bosibl mewn egwyddor sicrhau diogelwch hyd yn oed yn absenoldeb unrhyw ddyfalbarhad hirdymor yn Redis. Sylwch, fodd bynnag, y gallai hyn arwain at ddirwy am dorri hygyrchedd. Er enghraifft, os bydd y mwyafrif o achosion yn methu, ni fydd y system ar gael yn fyd-eang ar gyfer y TTL (ac ni ellir rhwystro unrhyw adnodd yn ystod y cyfnod hwn).

Rydym yn cynyddu argaeledd yr algorithm: rydym yn ymestyn y blocio

Os yw'r gwaith a gyflawnir gan gleientiaid yn cynnwys camau bach, mae'n bosibl lleihau hyd y clo rhagosodedig a gweithredu mecanwaith ar gyfer ymestyn cloeon. Mewn egwyddor, os yw'r cleient yn brysur yn cyfrifiadura a bod gwerth dod i ben y clo yn beryglus o isel, gallwch anfon sgript Lua i bob achos sy'n ymestyn TTL yr allwedd os yw'r allwedd yn dal i fodoli ac mae ei werth yn dal i fod yn werth ar hap a gafwyd pan fydd y clo ei gaffael.

Dim ond os yw wedi llwyddo i gloi'r rhan fwyaf o achosion o fewn y cyfnod dilysrwydd y dylai cleient ystyried bod clo yn cael ei adennill.

Yn wir, yn dechnegol nid yw'r algorithm yn newid, felly mae'n rhaid cyfyngu ar y nifer fwyaf o ymdrechion ailadroddus i gaffael cloeon, fel arall bydd yr eiddo hygyrchedd yn cael ei dorri.

Ffynhonnell: hab.com

Ychwanegu sylw