પાંચ વિદ્યાર્થીઓ અને ત્રણ વિતરિત કી-વેલ્યુ સ્ટોર્સ

અથવા કેવી રીતે અમે ZooKeeper, etcd અને Consul KV માટે ક્લાયંટ C++ લાઇબ્રેરી લખી

વિતરિત પ્રણાલીઓની દુનિયામાં, સંખ્યાબંધ લાક્ષણિક કાર્યો છે: ક્લસ્ટરની રચના વિશે માહિતી સંગ્રહિત કરવી, નોડ્સની ગોઠવણીનું સંચાલન કરવું, ખામીયુક્ત ગાંઠો શોધવી, નેતા પસંદ કરવા. અને અન્ય. આ સમસ્યાઓ ઉકેલવા માટે, ખાસ વિતરણ પ્રણાલીઓ બનાવવામાં આવી છે - સંકલન સેવાઓ. હવે અમને તેમાંથી ત્રણમાં રસ હશે: ZooKeeper, etcd અને Consul. કોન્સ્યુલની તમામ સમૃદ્ધ કાર્યક્ષમતામાંથી, અમે કોન્સ્યુલ KV પર ધ્યાન કેન્દ્રિત કરીશું.

સારમાં, આ બધી સિસ્ટમો ફોલ્ટ-સહિષ્ણુ, લાઇનરાઇઝેબલ કી-વેલ્યુ સ્ટોર્સ છે. તેમ છતાં તેમના ડેટા મોડેલોમાં નોંધપાત્ર તફાવતો છે, જેની આપણે પછી ચર્ચા કરીશું, તેઓ સમાન વ્યવહારિક સમસ્યાઓ હલ કરે છે. દેખીતી રીતે, દરેક એપ્લિકેશન કે જે સંકલન સેવાનો ઉપયોગ કરે છે તે તેમાંથી એક સાથે જોડાયેલી છે, જે એક ડેટા સેન્ટરમાં ઘણી સિસ્ટમોને સપોર્ટ કરવાની જરૂરિયાત તરફ દોરી શકે છે જે વિવિધ એપ્લિકેશનો માટે સમાન સમસ્યાઓ હલ કરે છે.

આ સમસ્યાનો ઉકેલ લાવવાનો વિચાર એક ઓસ્ટ્રેલિયન કન્સલ્ટિંગ એજન્સીમાં ઉદ્દભવ્યો હતો, અને તેને અમલમાં મૂકવા માટે વિદ્યાર્થીઓની એક નાની ટીમ અમારી પાસે આવી, જેના વિશે હું વાત કરવા જઈ રહ્યો છું.

અમે એક લાઇબ્રેરી બનાવવામાં વ્યવસ્થાપિત છીએ જે ZooKeeper, etcd અને Consul KV સાથે કામ કરવા માટે એક સામાન્ય ઇન્ટરફેસ પ્રદાન કરે છે. પુસ્તકાલય C++ માં લખાયેલ છે, પરંતુ તેને અન્ય ભાષાઓમાં પોર્ટ કરવાની યોજના છે.

ડેટા મોડલ્સ

ત્રણ અલગ-અલગ સિસ્ટમો માટે સામાન્ય ઈન્ટરફેસ વિકસાવવા માટે, તમારે તે સમજવાની જરૂર છે કે તેઓમાં શું સામ્ય છે અને તેઓ કેવી રીતે અલગ છે. ચાલો તેને આકૃતિ કરીએ.

ઝૂકીપર

ચાવીઓ વૃક્ષમાં ગોઠવવામાં આવે છે અને તેને નોડ્સ કહેવામાં આવે છે. તદનુસાર, નોડ માટે તમે તેના બાળકોની સૂચિ મેળવી શકો છો. znode બનાવવા (બનાવો) અને મૂલ્ય (setData) બદલવાની કામગીરીઓ અલગ કરવામાં આવી છે: માત્ર હાલની કી વાંચી અને બદલી શકાય છે. ઘડિયાળો નોડનું અસ્તિત્વ ચકાસવા, મૂલ્ય વાંચવા અને બાળકો મેળવવાની કામગીરી સાથે જોડી શકાય છે. વૉચ એ એક-વખતનું ટ્રિગર છે જે જ્યારે સર્વર પર સંબંધિત ડેટાનું સંસ્કરણ બદલાય છે ત્યારે ફાયર થાય છે. ક્ષણિક ગાંઠોનો ઉપયોગ નિષ્ફળતાને શોધવા માટે થાય છે. તેઓ ક્લાયંટના સત્ર સાથે જોડાયેલા છે જેણે તેમને બનાવ્યું છે. જ્યારે ક્લાયંટ સત્ર બંધ કરે છે અથવા તેના અસ્તિત્વ વિશે ZooKeeper ને સૂચિત કરવાનું બંધ કરે છે, ત્યારે આ ગાંઠો આપમેળે કાઢી નાખવામાં આવે છે. સરળ વ્યવહારો સમર્થિત છે - ઓપરેશન્સનો સમૂહ જે કાં તો તમામ સફળ થાય છે અથવા નિષ્ફળ જાય છે જો તેમાંથી ઓછામાં ઓછા એક માટે આ શક્ય ન હોય.

વગેરે

આ સિસ્ટમના વિકાસકર્તાઓ સ્પષ્ટપણે ZooKeeper દ્વારા પ્રેરિત હતા, અને તેથી બધું અલગ રીતે કર્યું. ત્યાં ચાવીઓનો કોઈ વંશવેલો નથી, પરંતુ તેઓ એક લેક્સિકોગ્રાફિકલી ઓર્ડર કરેલ સેટ બનાવે છે. તમે ચોક્કસ શ્રેણીની બધી કી મેળવી અથવા કાઢી શકો છો. આ માળખું વિચિત્ર લાગે છે, પરંતુ તે વાસ્તવમાં ખૂબ જ અભિવ્યક્ત છે, અને તેના દ્વારા વંશવેલો દૃષ્ટિકોણ સરળતાથી અનુકરણ કરી શકાય છે.

etcd પાસે પ્રમાણભૂત સરખામણી-અને-સેટ કામગીરી નથી, પરંતુ તેમાં કંઈક સારું છે: વ્યવહારો. અલબત્ત, તે ત્રણેય પ્રણાલીઓમાં અસ્તિત્વ ધરાવે છે, પરંતુ etcd વ્યવહારો ખાસ કરીને સારા છે. તેઓ ત્રણ બ્લોક્સ ધરાવે છે: તપાસ, સફળતા, નિષ્ફળતા. પ્રથમ બ્લોકમાં શરતોનો સમૂહ છે, બીજા અને ત્રીજા - ઓપરેશન્સ. વ્યવહાર પરમાણુ રીતે ચલાવવામાં આવે છે. જો બધી શરતો સાચી હોય, તો સફળતા બ્લોક ચલાવવામાં આવે છે, અન્યથા નિષ્ફળતા બ્લોક ચલાવવામાં આવે છે. API 3.3 માં, સફળતા અને નિષ્ફળતા બ્લોકમાં નેસ્ટેડ વ્યવહારો હોઈ શકે છે. એટલે કે, લગભગ મનસ્વી માળખાના સ્તરની શરતી રચનાઓ પરમાણુ રીતે ચલાવવાનું શક્ય છે. તમે ચેક્સ અને ઑપરેશન્સ અસ્તિત્વમાં છે તે વિશે વધુ જાણી શકો છો દસ્તાવેજીકરણ.

ઘડિયાળો અહીં પણ અસ્તિત્વમાં છે, જો કે તે થોડી વધુ જટિલ છે અને ફરીથી વાપરી શકાય તેવી છે. એટલે કે, કી રેન્જ પર ઘડિયાળ ઇન્સ્ટોલ કર્યા પછી, જ્યાં સુધી તમે ઘડિયાળ રદ ન કરો ત્યાં સુધી તમને આ શ્રેણીમાં તમામ અપડેટ્સ પ્રાપ્ત થશે, અને માત્ર પહેલી જ નહીં. વગેરેમાં, ZooKeeper ક્લાયન્ટ સત્રોના એનાલોગ લીઝ છે.

કોન્સ્યુલ કે.વી.

અહીં કોઈ કડક અધિક્રમિક માળખું પણ નથી, પરંતુ કન્સ્યુલ તે અસ્તિત્વમાં છે તેવો દેખાવ બનાવી શકે છે: તમે ઉલ્લેખિત ઉપસર્ગ સાથે બધી કી મેળવી અને કાઢી શકો છો, એટલે કે, કીના "સબટ્રી" સાથે કામ કરી શકો છો. આવા પ્રશ્નોને પુનરાવર્તિત કહેવામાં આવે છે. વધુમાં, કોન્સ્યુલ ફક્ત તે જ કી પસંદ કરી શકે છે જેમાં ઉપસર્ગ પછી ઉલ્લેખિત અક્ષર શામેલ નથી, જે તાત્કાલિક "બાળકો" મેળવવા માટે અનુરૂપ છે. પરંતુ તે યાદ રાખવું યોગ્ય છે કે આ ચોક્કસ વંશવેલો બંધારણનો દેખાવ છે: જો તેના માતાપિતા અસ્તિત્વમાં ન હોય અથવા બાળકો ધરાવતી કીને કાઢી નાખે તો કી બનાવવી તદ્દન શક્ય છે, જ્યારે બાળકો સિસ્ટમમાં સંગ્રહિત થવાનું ચાલુ રાખશે.

ઘડિયાળોને બદલે, કોન્સુલે HTTP વિનંતીઓને અવરોધિત કરી છે. સારમાં, આ ડેટા રીડિંગ પદ્ધતિના સામાન્ય કૉલ્સ છે, જેના માટે, અન્ય પરિમાણો સાથે, ડેટાનું છેલ્લું જાણીતું સંસ્કરણ સૂચવવામાં આવ્યું છે. જો સર્વર પર સંબંધિત ડેટાનું વર્તમાન સંસ્કરણ ઉલ્લેખિત કરતા વધારે હોય, તો પ્રતિસાદ તરત જ પરત કરવામાં આવે છે, અન્યથા - જ્યારે મૂલ્ય બદલાય છે. એવા સત્રો પણ છે જે કોઈપણ સમયે કી સાથે જોડી શકાય છે. તે નોંધવું યોગ્ય છે કે etcd અને ZooKeeperથી વિપરીત, જ્યાં સત્રો કાઢી નાખવાથી સંબંધિત કીને કાઢી નાખવામાં આવે છે, ત્યાં એક મોડ છે જેમાં સત્ર ફક્ત તેમની પાસેથી અનલિંક કરવામાં આવે છે. ઉપલબ્ધ છે વ્યવહારો, શાખાઓ વિના, પરંતુ તમામ પ્રકારના ચેક સાથે.

તે બધા એકસાથે મૂકી

ZooKeeper પાસે સૌથી સખત ડેટા મોડલ છે. વગેરેમાં ઉપલબ્ધ એક્સપ્રેસિવ રેન્જ ક્વેરીઝ ZooKeeper અથવા Consul માં અસરકારક રીતે અનુકરણ કરી શકાતી નથી. તમામ સેવાઓમાંથી શ્રેષ્ઠનો સમાવેશ કરવાનો પ્રયાસ કરીને, અમે નીચે આપેલા નોંધપાત્ર અપવાદો સાથે ઝૂકીપર ઈન્ટરફેસની લગભગ સમકક્ષ ઈન્ટરફેસ સાથે સમાપ્ત થયા:

• ક્રમ, કન્ટેનર અને TTL નોડ્સ આધારભૂત નથી
• ACL સમર્થિત નથી
• જો તે અસ્તિત્વમાં ન હોય તો સેટ પદ્ધતિ કી બનાવે છે (ZK સેટડેટા આ કિસ્સામાં ભૂલ આપે છે)
• સેટ અને કેસ પદ્ધતિઓ અલગ કરવામાં આવે છે (ZK માં તે આવશ્યકપણે સમાન વસ્તુ છે)
• ભૂંસવાની પદ્ધતિ નોડને તેના સબટ્રી સાથે કાઢી નાખે છે (ZK ડિલીટમાં જો નોડમાં બાળકો હોય તો ભૂલ પરત કરે છે)
• દરેક કી માટે ફક્ત એક જ સંસ્કરણ છે - મૂલ્ય સંસ્કરણ (ZK માં તેમાંથી ત્રણ છે)

ક્રમિક નોડ્સનો અસ્વીકાર એ હકીકતને કારણે છે કે etcd અને કોન્સ્યુલ પાસે તેમના માટે બિલ્ટ-ઇન સપોર્ટ નથી, અને તે પરિણામી લાઇબ્રેરી ઇન્ટરફેસની ટોચ પર વપરાશકર્તા દ્વારા સરળતાથી લાગુ કરી શકાય છે.

શિરોબિંદુને કાઢી નાખતી વખતે ZooKeeper જેવી જ વર્તણૂકનો અમલ કરવા માટે etcd અને Consul માં દરેક કી માટે અલગ ચાઈલ્ડ કાઉન્ટર જાળવવાની જરૂર પડશે. અમે મેટા માહિતી સંગ્રહિત કરવાનું ટાળવાનો પ્રયાસ કર્યો હોવાથી, સમગ્ર સબટ્રીને કાઢી નાખવાનો નિર્ણય લેવામાં આવ્યો હતો.

અમલીકરણની સૂક્ષ્મતા

ચાલો વિવિધ સિસ્ટમોમાં લાઇબ્રેરી ઇન્ટરફેસના અમલીકરણના કેટલાક પાસાઓ પર નજીકથી નજર કરીએ.

વગેરેમાં વંશવેલો

etcd માં વંશવેલો દૃષ્ટિકોણ જાળવવો એ સૌથી રસપ્રદ કાર્યોમાંનું એક બન્યું. રેંજ ક્વેરીઝ સ્પષ્ટ કરેલ ઉપસર્ગ સાથે કીની સૂચિ પુનઃપ્રાપ્ત કરવાનું સરળ બનાવે છે. ઉદાહરણ તરીકે, જો તમને દરેક વસ્તુની જરૂર હોય જે શરૂ થાય છે "/foo", તમે શ્રેણી માટે પૂછો છો ["/foo", "/fop"). પરંતુ આ કીનું આખું સબટ્રી પાછું આપશે, જે જો સબટ્રી મોટું હોય તો સ્વીકાર્ય નહીં હોય. પહેલા અમે મુખ્ય અનુવાદ મિકેનિઝમનો ઉપયોગ કરવાની યોજના બનાવી, zetcd માં અમલી. તેમાં કીની શરૂઆતમાં એક બાઈટ ઉમેરવાનો સમાવેશ થાય છે, જે વૃક્ષમાં નોડની ઊંડાઈ જેટલી હોય છે. ચાલો હું તમને એક ઉદાહરણ આપું.

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

પછી કીના તમામ તાત્કાલિક બાળકો મેળવો "/foo" શ્રેણીની વિનંતી કરીને શક્ય છે ["u02/foo/", "u02/foo0"). હા, ASCII માં "0" બરાબર પછી ઉભો છે "/".

પરંતુ આ કિસ્સામાં શિરોબિંદુને દૂર કરવાનું કેવી રીતે અમલમાં મૂકવું? તે તારણ આપે છે કે તમારે પ્રકારની તમામ શ્રેણીઓ કાઢી નાખવાની જરૂર છે ["uXX/foo/", "uXX/foo0") XX માટે 01 થી FF સુધી. અને પછી અમે અંદર દોડી ગયા ઓપરેશન નંબર મર્યાદા એક વ્યવહારમાં.

પરિણામે, એક સરળ કી રૂપાંતર પ્રણાલીની શોધ કરવામાં આવી, જેણે કીને કાઢી નાખવા અને બાળકોની સૂચિ મેળવવા બંનેને અસરકારક રીતે અમલમાં મૂકવાનું શક્ય બનાવ્યું. છેલ્લા ટોકન પહેલાં એક વિશિષ્ટ અક્ષર ઉમેરવા માટે તે પૂરતું છે. દાખ્લા તરીકે:

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

પછી કી કાઢી નાખવું "/very" કાઢી નાખવામાં ફેરવાય છે "/u00very" અને શ્રેણી ["/very/", "/very0"), અને તમામ બાળકોને મેળવવા - શ્રેણીમાંથી ચાવીઓ માટેની વિનંતીમાં ["/very/u00", "/very/u01").

ZooKeeper માં કી દૂર કરી રહ્યા છીએ

મેં પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, ZooKeeper માં તમે નોડને કાઢી શકતા નથી જો તેમાં બાળકો હોય. અમે સબટ્રી સાથે કીને કાઢી નાખવા માંગીએ છીએ. મારે શું કરવું જોઈએ? અમે આ આશાવાદ સાથે કરીએ છીએ. પ્રથમ, અમે એક અલગ ક્વેરી સાથે દરેક શિરોબિંદુના બાળકો મેળવીને, ઉપવૃક્ષને વારંવાર પસાર કરીએ છીએ. પછી અમે એક વ્યવહાર બનાવીએ છીએ જે સબટ્રીના તમામ નોડ્સને યોગ્ય ક્રમમાં કાઢી નાખવાનો પ્રયાસ કરે છે. અલબત્ત, સબટ્રી વાંચવા અને તેને કાઢી નાખવા વચ્ચે ફેરફારો થઈ શકે છે. આ કિસ્સામાં, વ્યવહાર નિષ્ફળ જશે. વધુમાં, વાંચન પ્રક્રિયા દરમિયાન સબટ્રી બદલાઈ શકે છે. આગલા નોડના બાળકો માટેની વિનંતી ભૂલ પરત કરી શકે છે જો, ઉદાહરણ તરીકે, આ નોડ પહેલેથી જ કાઢી નાખવામાં આવ્યો હોય. બંને કિસ્સાઓમાં, અમે ફરીથી સમગ્ર પ્રક્રિયાને પુનરાવર્તિત કરીએ છીએ.

આ અભિગમ કીને કાઢી નાખવાને ખૂબ જ બિનઅસરકારક બનાવે છે જો તેને બાળકો હોય, અને તેથી પણ વધુ જો એપ્લિકેશન સબટ્રી સાથે કામ કરવાનું ચાલુ રાખે, કાઢી નાખવું અને કી બનાવવી. જો કે, આનાથી અમને etcd અને કોન્સ્યુલમાં અન્ય પદ્ધતિઓના અમલીકરણમાં જટિલતા ટાળવાની મંજૂરી મળી.

ZooKeeper માં સેટ કરો

ZooKeeper માં અલગ પદ્ધતિઓ છે જે ટ્રી સ્ટ્રક્ચર (ક્રિએટ, ડીલીટ, ગેટચિલ્ડર) સાથે કામ કરે છે અને તે નોડમાં ડેટા સાથે કામ કરે છે (setData, getData). વધુમાં, બધી પદ્ધતિઓમાં કડક પૂર્વશરતો છે: જો નોડ પહેલાથી જ હોય ​​તો Create એ ભૂલ પરત કરશે. ડેટા બનાવવામાં આવ્યો છે, કાઢી નાખો અથવા સેટ કરો - જો તે પહેલાથી અસ્તિત્વમાં નથી. અમને એક સેટ પદ્ધતિની જરૂર હતી જેને કીની હાજરી વિશે વિચાર્યા વિના કૉલ કરી શકાય.

એક વિકલ્પ એ છે કે કાઢી નાખવાની જેમ આશાવાદી અભિગમ અપનાવવો. નોડ અસ્તિત્વમાં છે કે કેમ તે તપાસો. જો અસ્તિત્વમાં હોય, તો સેટડેટાને કૉલ કરો, અન્યથા બનાવો. જો છેલ્લી પદ્ધતિ ભૂલ આપે છે, તો તેને ફરીથી પુનરાવર્તન કરો. નોંધનીય પ્રથમ વસ્તુ એ છે કે અસ્તિત્વ પરીક્ષણ અર્થહીન છે. તમે તરત જ બનાવો કૉલ કરી શકો છો. સફળ સમાપ્તિનો અર્થ એ થશે કે નોડ અસ્તિત્વમાં નથી અને તે બનાવવામાં આવ્યું હતું. નહિંતર, બનાવો યોગ્ય ભૂલ આપશે, જેના પછી તમારે setData કૉલ કરવાની જરૂર છે. અલબત્ત, કૉલ્સ વચ્ચે, સ્પર્ધાત્મક કૉલ દ્વારા શિરોબિંદુને કાઢી નાખવામાં આવી શકે છે, અને સેટડેટા પણ ભૂલ આપશે. આ કિસ્સામાં, તમે તે બધું ફરીથી કરી શકો છો, પરંતુ શું તે મૂલ્યવાન છે?

જો બંને પદ્ધતિઓ ભૂલ આપે છે, તો અમે ખાતરીપૂર્વક જાણીએ છીએ કે સ્પર્ધાત્મક કાઢી નાખવામાં આવ્યું હતું. ચાલો કલ્પના કરીએ કે કોલિંગ સેટ પછી આ કાઢી નાખવામાં આવ્યું છે. પછી આપણે જે પણ અર્થ સ્થાપિત કરવાનો પ્રયાસ કરી રહ્યા છીએ તે પહેલેથી જ ભૂંસી નાખવામાં આવે છે. આનો અર્થ એ છે કે આપણે ધારી શકીએ છીએ કે સેટ સફળતાપૂર્વક એક્ઝિક્યુટ થયો હતો, પછી ભલેને હકીકતમાં કંઈપણ લખવામાં ન આવ્યું હોય.

વધુ તકનીકી વિગતો

આ વિભાગમાં આપણે વિતરિત સિસ્ટમમાંથી વિરામ લઈશું અને કોડિંગ વિશે વાત કરીશું.
ગ્રાહકની મુખ્ય આવશ્યકતાઓમાંની એક ક્રોસ-પ્લેટફોર્મ હતી: ઓછામાં ઓછી એક સેવાઓ Linux, MacOS અને Windows પર સમર્થિત હોવી જોઈએ. શરૂઆતમાં, અમે ફક્ત Linux માટે જ વિકસાવ્યું, અને પછીથી અન્ય સિસ્ટમ્સ પર પરીક્ષણ કરવાનું શરૂ કર્યું. આનાથી ઘણી સમસ્યાઓ ઊભી થઈ, જે થોડા સમય માટે સંપૂર્ણપણે અસ્પષ્ટ હતી કે કેવી રીતે સંપર્ક કરવો. પરિણામે, ત્રણેય સંકલન સેવાઓ હવે Linux અને MacOS પર સમર્થિત છે, જ્યારે Windows પર માત્ર Consul KV સપોર્ટેડ છે.

શરૂઆતથી જ, અમે સેવાઓ મેળવવા માટે તૈયાર પુસ્તકાલયોનો ઉપયોગ કરવાનો પ્રયાસ કર્યો. ZooKeeper ના કિસ્સામાં, પસંદગી પર પડી ઝૂકીપર C++, જે આખરે વિન્ડોઝ પર કમ્પાઈલ કરવામાં નિષ્ફળ ગયું. જો કે, આ આશ્ચર્યજનક નથી: લાઇબ્રેરી ફક્ત લિનક્સ તરીકે સ્થિત છે. કોન્સ્યુલ માટે એકમાત્ર વિકલ્પ હતો પીપીકોન્સલ. તેમાં આધાર ઉમેરવો પડ્યો સત્રો и વ્યવહારો. વગેરે માટે, પ્રોટોકોલના નવીનતમ સંસ્કરણને ટેકો આપતી સંપૂર્ણ સુવિધાયુક્ત લાઇબ્રેરી મળી નથી, તેથી અમે ફક્ત જનરેટ કરેલ grpc ક્લાયંટ.

ZooKeeper C++ લાઇબ્રેરીના અસુમેળ ઈન્ટરફેસથી પ્રેરિત થઈને, અમે અસુમેળ ઈન્ટરફેસનો અમલ કરવાનું પણ નક્કી કર્યું છે. ZooKeeper C++ આ માટે ભવિષ્ય/વચન આદિમનો ઉપયોગ કરે છે. STL માં, કમનસીબે, તેઓ ખૂબ જ નમ્રતાથી લાગુ કરવામાં આવે છે. ઉદાહરણ તરીકે, ના પછી પદ્ધતિ, જે પાસ કરેલ કાર્યને ભવિષ્યના પરિણામ પર લાગુ કરે છે જ્યારે તે ઉપલબ્ધ થાય છે. અમારા કિસ્સામાં, પરિણામને અમારી લાઇબ્રેરીના ફોર્મેટમાં કન્વર્ટ કરવા માટે આવી પદ્ધતિ જરૂરી છે. આ સમસ્યાનો સામનો કરવા માટે, અમારે અમારા પોતાના સરળ થ્રેડ પૂલને અમલમાં મૂકવો પડ્યો, કારણ કે ગ્રાહકની વિનંતી પર અમે બૂસ્ટ જેવી ભારે તૃતીય-પક્ષ લાઇબ્રેરીઓનો ઉપયોગ કરી શકતા નથી.

અમારા પછી અમલીકરણ આ રીતે કામ કરે છે. જ્યારે બોલાવવામાં આવે છે, ત્યારે વધારાના વચન/ભવિષ્યની જોડી બનાવવામાં આવે છે. નવું ભવિષ્ય પરત કરવામાં આવે છે, અને પાસ થયેલને અનુરૂપ કાર્ય અને કતારમાં વધારાના વચન સાથે મૂકવામાં આવે છે. પૂલમાંથી એક થ્રેડ કતારમાંથી કેટલાક ફ્યુચર્સ પસંદ કરે છે અને wait_for નો ઉપયોગ કરીને મતદાન કરે છે. જ્યારે પરિણામ ઉપલબ્ધ થાય છે, ત્યારે અનુરૂપ કાર્ય કહેવામાં આવે છે અને તેનું વળતર મૂલ્ય વચનને પસાર કરવામાં આવે છે.

અમે એક જ થ્રેડ પૂલનો ઉપયોગ etcd અને કોન્સ્યુલને પ્રશ્નો ચલાવવા માટે કર્યો હતો. આનો અર્થ એ છે કે અંતર્ગત પુસ્તકાલયોને બહુવિધ વિવિધ થ્રેડો દ્વારા ઍક્સેસ કરી શકાય છે. ppconsul થ્રેડ સલામત નથી, તેથી તેના પરના કૉલ્સ તાળાઓ દ્વારા સુરક્ષિત છે.
તમે બહુવિધ થ્રેડોમાંથી grpc સાથે કામ કરી શકો છો, પરંતુ તેમાં સૂક્ષ્મતા છે. વગેરેમાં ઘડિયાળો grpc સ્ટ્રીમ દ્વારા લાગુ કરવામાં આવે છે. આ ચોક્કસ પ્રકારના સંદેશાઓ માટે દ્વિદિશ ચેનલો છે. લાઇબ્રેરી બધી ઘડિયાળો માટે એક થ્રેડ બનાવે છે અને એક જ થ્રેડ જે આવનારા સંદેશાઓ પર પ્રક્રિયા કરે છે. તેથી grpc સ્ટ્રીમમાં સમાંતર લખાણને પ્રતિબંધિત કરે છે. આનો અર્થ એ છે કે ઘડિયાળ શરૂ કરતી વખતે અથવા કાઢી નાખતી વખતે, તમારે આગલી મોકલતા પહેલા અગાઉની વિનંતી મોકલવાનું પૂર્ણ ન થાય ત્યાં સુધી રાહ જોવી આવશ્યક છે. અમે સિંક્રનાઇઝેશન માટે ઉપયોગ કરીએ છીએ શરતી ચલો.

પરિણામ

તમારા માટે જુઓ: liboffkv.

અમારી ટીમ: રાયડ રોમાનોવ, ઇવાન ગ્લુશેન્કોવ, દિમિત્રી કમલદીનોવ, વિક્ટર ક્રાપિવેન્સ્કી, વિટાલી ઇવાનિન.

સોર્સ: www.habr.com