ProHoster > Блог > administratio > Distribuit densis usura Redis

Distribuit densis usura Redis

Heus Habr!

Hodie in animo tuo adferimus translationem articuli complexi de exsequendis densis uti Redis distributis et invitamus te loqui de exspectatione Redis ut thema. Analysis Algorithmi Redlock in quaestione a Martino Kleppmann, authore libri "High Load Applications", dedit hic.

Obstructio distributa valde utilis est primitivo usu in multis ambitibus in quibus diversi processus operari debent de facultatibus communibus modo mutuo exclusivo.

Plures bibliothecarum et epistolarum ibi sunt quae describent quomodo ad efficiendum DLM (Distributum Lock Manager) Redis utens, sed singulae bibliothecae diversos aditus sumit et cautiones, quas praebent, satis debiles comparantur ad id quod paulo urbanius consilio assequendum est.

In hoc articulo conabimur describere algorithm canonicum conditionalem demonstrantem quomodo efficiendi distributa densis utens redis. Dicemus de algorithmo nomine Redlockhoc algorithmus tutior est quam solitus instantiae accessus, ut nostra sententia, seriam distributam aggreditur. Speramus communitatem eam resolvere, feedback praebebit, eamque ut principium utemur complexionis vel alterius inceptis.

implementation

Priusquam ad descriptionem algorithmi accedamus, plures nexus ad exsecutiones paratas praeparamus. Ad secundum dicendum quod adhiberi possunt.

Security et Availability Guarantees

Consilium nostrum exemplar in tribus iustis proprietatibus pergimus quae putamus minimas cautiones praebere necessarias ad densis distributis uti efficaciter.

  1. Securitas proprietas: Mutua exclusio. Quovis tempore unus tantum cliens seram tenere potest.
  2. Availability Property A: Non deadlocks. Semper possibile est seram acquirere, etiam si cliens qui subsidio claudatur vel terras in alia segmenti disci parte deficiat.
  3. Availability Property B: Culpa TOLERATIO. Dum plures Nodi Redis currunt, clientes comas acquirere et dimittere possunt.

Cur exsecutio secundum defectum recuperationis non sufficit in hoc casu
Ut quid emendare incipimus intelligendum sit, hodiernam rerum statum perspiciamus cum densis bibliothecis in Redis positis distributis.

Simplicissima via ad subsidia claudendi utens Redis est clavem creare in instantia. Typice, clavis cum limitata vita creatur, hoc fit utens exspirat pluma in Redis, quo citius vel serius haec clavis emittitur (proprietas 2 in indice nostro). Cum cliens subsidii dimittere debet, clavem delet.

Primo aspectu, haec solutio satis bene operatur, sed quaestio est: architectura nostra unum punctum defectum creat. Quid accidit si instantia Redis hospes deficiat? Addamus ergo servum! Et hoc utemur, si praesens est unavailable. Donec id justo est. Hoc facto, mutuam exclusionem proprietatis ad effectum deduci non poterimus, quod securitatem praestare debeamus, quia replicatio in Redis asynchrona est.

Patet in tali exemplari sta- tio generis ;

  1. Cliens crinem domino acquirit.
  2. Dominus deficit ante clavem introitus ad servum transfertur.
  3. Secutus ad ducem promotus est.
  4. Cliens B idem subsidium acquirit crinem quo A iam clausum est. SECURITAS VIOLATION!

Aliquando est omnino consuetum quod in specialibus adiunctis, ut est defectus, multi clientes seram simul tenere possunt. His in casibus applicari potest solutio replicationis fundatae. Alioquin solutionem in hoc articulo descriptam commendamus.

Recta implementation cum unoquoque

Antequam defectus unius instantiae conformationis supra descriptae superare conor, intelligamus quomodo hunc casum simplicem probe tractandum, cum haec solutio actu valida sit in applicationibus ubi condicio gens interdum acceptabilis est, tum etiam quod obstruitur. una instantia inservit pro fundamento, quod adhibetur in algorithmo distributo hic descripto.

Parare seram, hoc fac;

SET resource_name my_random_value NX PX 30000

Hoc mandatum clavem tantum inaugurat si iam non est (optio NX), cum validitate triginta millium millium secundorum (PX optio). Clavis est profectus ad "myrandomvalue" Hic valor singularis debet esse per omnes clientes et omnes petitiones seram.
Plerumque, valor temere usus est ut seram dimitteret cum scripto Redis narrante: clavem tantum remove si existat et valor in ea reposita prorsus expectatur. Hoc fit utens sequenti scripto Luae:

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

Hoc magni momenti est ne seram ab alio cliente ablatam removeat. Exempli causa, cliens crinem acquireret, postea in aliqua operatione quae longior quam prima cincinno durat (ita ut clavem tempus habet exspirandi), postea seram removeat quam alius cliens posuit.
Simplex DEL usus non tutum est quia cliens crinem ab alio cliente tentum amovere potest. E contra, cum supra scriptum utens, quaeque cincinno chorda temere "signata" est, ita solus cliens qui antea posuerat eam auferre potest.

Quid hoc temere chorda? Coniicio 20 bytes ex /dev/urandom esse debere, sed vias minus pretiosas invenire potes ut chordam unicam satis ad proposita tua facias. Exempli gratia, esset finis semini RC4 cum /dev/urandom et tunc generare pseudo-passim rivum ex eo. Solutio simplicior implicat complexionem unix temporis in microsecond resolutionis plus clientis ID; non tam securus est, sed verisimile est ad negotium in plerisque contextibus.

Tempus quo utimur ut mensura vitae clavium "cincinnus vita" appellatur. Haec aestimatio tum temporis spatium ante seram sponte dimissa est et quantum temporis clientis operationem perficiendam habet antequam alius client potest vicissim illud auxilium cohibere, sine cautionibus exclusionis mutuae violatae. Haec cautio solum quadam fenestra temporis circumscribitur, quae a momento seram emitur.

Dictum est igitur bonam viam ad acquirendum et serae dimittendum. Ratio (si loquimur de systemate non distributo constans in una et semper instantia in promptu) tuta est. Hunc conceptum ad systema distributum extendamus, ubi tales cautiones non habemus.

Redlock algorithmus

Versio algorithm distributa sumit, quam habemus N. Redis ad tit. Nodi hi inter se omnino independentes sunt, ideo non utimur replicatione vel alia ratione coordinationis implicitae. Iam operuimus quomodo seram uno instantia acquirere et emittere. Hoc pro certo sumimus algorithmum, cum una instantia laborat, methodo exacte utendum. In exemplis nostris N ad V posuimus, quod est rationabilis valoris. Ideo magistros 5 Redis uti necesse est in diversis computatris vel machinis virtualibus utendum est ut late inter se agant.

Ad comparandum seram, cliens has operationes exercet;

  1. Tempus praesens in milliseconds accipit.
  2. Postea in omnibus instantiis N seram obtinere nititur, eodem nomine clavis adhibitis et valores incertis in omnibus casibus. In Stage 2, cum cliens seram in per- instantiae fundamento ponit, cliens mora utitur ad acquirendum illud quod satis breve est comparato tempori, quo seram sponte dimissa est. Exempli gratia, si interclusio duratio est 10 secundis, mora in latitudine 5-50 millisecondorum esse potuit. Haec condicionem eliminat in qua cliens obclusus diu manere potuit ut nodi Redis incassum pervenire conetur: si instantia perpendat, tunc quam primum alteri instantia coniungere conamur.
  3. Cliens sumere seram quantum temporis spatium est computat; Ad hoc faciendum, subtrahit ex actu temporis pretii indicationem quae in gradatim obtinetur 1. Si et solum si cliens seram in pluribus instantiis obtinere potuit (saltem 3), et totum tempus sumpsit. obti- seram, minus quam seram durationis, seram habitis existimatur.
  4. Si crinem acquisitum est, cincinnorum duratio capitur originalis durationis cincinnorum minus elapso tempore in gradu 3 computato.
  5. Si cliens ob aliquam causam seram non obtinet (vel instantias N/2+1 claudere nequivit, vel lock durationem negativam habebat), tunc omnia instantiae reserare conabitur (etiam quae obstruere non posse arbitrabatur. ).

Estne algorithmus asynchronus?

Hoc algorithmus suppositione nititur quod, licet horologium non sit synchronum quo omnes processus operantur, localis in unoquoque processu tempus tamen eodem fere gressu fluit, et error parvus est respectu totius temporis, quo seram est. sponte dimisit. Haec assumptio valde similis est rei propriae pro communibus computatoribus: unumquemque computatorium horologium locale habet, ac plerumque eo numerare possumus quod temporis differentia inter diversos computatores exiguum est.

Hoc loco diligentius formare debemus regulam mutuam exclusionis: exclusio mutua praestatur tantum si cliens seram exitus tempore clavorum tenens validus est (hoc valore obtinetur in passu 3), minus aliquanto tempore (pauca summa. milliseconds pro tempore inter processuum differentiam compensare).

Articulus interesting sequens plura narrat de talibus systematibus quae temporum intervallis coordinationem requirunt: Addicit: efficiens mechanismum culpae patientis pro distributo lima cache constantia.

Retry in defectum

Cum cliens non acquirat crinem, iterum tentandum est post moras temere; hoc fit, ut plures clientes de-synchronizent, quae in eodem auxilio simul (quae ad "split-brain" condicionem ducere possunt, victores non sunt). Accedit, quo cliens citius in pluribus instantiis Redis seram acquirere conatur, eo angustior fenestra in qua res scissurae cerebri accidere potest (et minor retries opus est). Ideo, specimen, cliens instantias simul multiplices usus mittere conetur SET imperata ad N.

Illud extollendum est quanti momenti sit clientibus qui plures cincinnos acquirit crines acquirere non possunt, ita ut clavem exspirare ante seram subsidii non habeant ut denuo acquiri possint. (etsi in retis ruptio fiat, et client contactum cum instantiis Redis amittit, tunc tibi solvi disponibilitatem poenam exspectans clavem exspirandi).

Dimitte cincinno

Seram solvens est operatio simplex quae simpliciter requirit omnes instantias reserans, cuiuscumque instantia instantiam particularem feliciter conclusisse videtur.

Securitatis Considerationes

Salvusne est algorithmus? Studeamus fingere quae in diversis missionibus fiunt.

Imprimis, sumamus clientem in pluribus instantiis seram obtinere potuisse. Utraque instantia clavem eadem vita omnibus continebit. Quaelibet autem harum clavium diverso tempore instituta est, ut diversis temporibus exspirabunt. Sed, si prima clavis in tempore non peius T1 instituebatur (tempus quod ante primam servientium contingentem eligimus), postrema clavis non peius quam T2 tempore inaugurata est (tempus ad quem responsum receptum est. e servo ultimo), confidimus tunc primam clavem in statuto qui expirat, saltem superesse MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. Omnes aliae claves postea exspirabunt, ut certo scire possimus omnes claves eodem tempore saltem hoc tempore validas fore.

Tempore quo maxime claves validae manent, alius cliens seram acquirere non poterit, cum N/2+1 SET NX operationes succedere non possint nisi N/2+1 claves iam exstent. Ideo, sera acquisita, impossibile est eam iterum eodem momento acquirere (hoc enim mutuam exclusionem proprietatis violaret).
Attamen volumus efficere ut plures clientes seram acquirere conantes simul non posse simul succedant.

Si plures instantiarum circa vel plus quam maximam durationem lock concluserit hie, considerabit seram invalidam et instantias resera. Ideo solum oportet considerare casum in quo hic pluribus instantiis intercluderetur in tempore minus quam expirata. In hoc casu, ad argumentationem praedictam, tempore MIN_VALIDITY nullus cliens eam- crinem possit. Ideo plures clientes instantias N/2+1 eodem tempore (qui in fine sceni II finit) cohibere poterunt tantum cum tempus maioris claudendi fuit maius quam tempus TTL, quod crinem invalidum reddit.

Potesne formalem securitatis probationem praebere, similes algorithmos exsistere, vel cimex in superioribus invenire?

Accessibility considerations

Ratio disponibilitate pendet a tribus notis principalibus:

  1. Automatice crines emittunt (velut claves exspirant): Claves tandem praesto erunt iterum utendum pro cincinnis.
  2. Quod clientes plerumque se adiuvant sublatis cincinnis, cum probatum cincinno non acquisitum, vel acquisitum est, et officium expletum est; Verisimile est ergo nos non exspectaturos claves ad eam- que seram exspirandam.
  3. Quod cum cliens opus est ad reprimendum seram acquirendam, id exspectat longioris temporis comparate quam tempus, quo plus comae acquirant. Hoc probabilius redigit ad condicionem scissilis cerebri, cum certatim de opibus oritur.

Attamen poena disponibilitate est aequalis TTL segmentorum retis, ergo si segmenta contigua sunt, poena potest esse indefinita. Hoc evenit, quoties cliens crinem acquirit et deinde in aliud segmentum discindit antequam eam dimittere possit.

Principio, infinitis contiguis segmentis retis datis, ratio in infinitum temporis spatium unavailable manere potest.

Euismod, failover et fsync

Multi homines Redis utuntur propterea quod opus est summo cincinno servo perficiendi secundum latency opus comam acquirendi et dimittere, et numerus acquisitionum / solvo qui per alterum compleri potest. Ut huic postulationi occurrat, consilium est communicare cum N Redis servientibus ad latency reducendi. Hoc consilium multiplex est (vel "multiplicatio pauperum hominis", ubi nervus modus in non-obstructione ponitur, omnia mandata mittit, et mandata postea legit, si tempus rotundum inter clientem et singularem instantiam est simile) .

Sed nos quoque considerare debemus considerationem cum diuturno tempore datae repositionis, si exemplum certae recuperationis ex defectis creare studemus.

Basically, ad rem illustrandam, sumamus nos Redis configurare cum nulla diuturna notitia omnino reposita. Cliens efficit ut 3 extra 5 instantias intercluderent. Una ex instantiis, quae cliens interclusum administravit, restaretur, et hoc momento exstant 3 instantiae denuo pro eadem subsidio, quam impedire possumus, et alius cliens invicte potest obsistere instantiam restarted, salvam possessionem securitatis quae supponit exclusivum cincinnos.

Si notitias praemisit (AOF), res leviter emendabit. Exempli gratia, servo misso shutdown mandatum potes promovere et relegere. Cum operationes exspirationis in Redis semantically perficiantur ita ut tempus fluere pergat etiam cum ministri avertit, omnia nostra requisita denique sunt. Hoc normale est dum shutdown normali servetur. Quid ageret in casu virtutis outages? Si Redis per defaltam configuratur, cum fsync synchronum in disco secundo secundo, fieri potest ut post sileo clavem nostram non habebimus. Cogitatione, si velimus seram securitatem spondere in quolibet instantia sileo, nobis dare operam debemus fsync=always in uncinis ad longum tempus data repono. Haec perficiendi perfecte necabit, usque ad ambitum systematum CP, quae tradito crines distributa ad efficiendum secure adhibentur.

Sed aliter se res habet quam prima facie videtur. In principio, securitas conservatur algorithm quia cum instantia post defectum restatitur, iam non participat aliquam lock quae actu agente est.

Ad hoc assequendum, modo operam dabimus ut post defectum instantiae remaneat unavailable per aliquod temporis spatium leviter excedentes maximum TTL quo utimur. Hoc modo exspectabimus usque ad diem expirationis et emissionem latae omnium clavium, quae tempore defectionis activae erant.

Utens sileo moratus, in principio potest securitatem consequi etiam in nulla diuturna permanentia in Redis. Sciendum tamen est, hoc in fine inveniri posse ad accessibilitatem violati. Exempli gratia, si plures instantiarum defecerint, ratio globally unavailable pro TTL fiet (nec resource hoc tempore obstrui potest).

Praefixio algorithm augemus: interclusionem extendimus

Si opera clientium ex parvis gradibus consistunt, potest reducere defaltam cincinnorum durationem et ma- chinam machinam ad comas extendendas. In principio, si cliens computando occupatus est et clausura exspiratio pretii periculose gravis est, potes litteras Lua mittere ad omnes instantias quae TTL clavis extenduntur si adhuc clavem existit et eius valor adhuc valoris temere consecutus est. cincinno acquiritur.

Cliens solum considerare debet seram quaerendam, si plures instantias intra validitatem periodi claudere curaverit.

Verum, algorithmus technice non mutat, ideo numerus maximus repetitorum conatum acquirendi crines limitandus est, alioquin proprietatibus accessibilitas violabitur.

Source: www.habr.com

Add a comment