మనందరికీ కథలు ఇష్టం. మేము అగ్ని చుట్టూ కూర్చుని మా గత విజయాలు, యుద్ధాలు లేదా మా పని అనుభవం గురించి మాట్లాడాలనుకుంటున్నాము.
ఈరోజు అలాంటి రోజు మాత్రమే. మరియు మీరు ప్రస్తుతం మంటల వద్ద లేకపోయినా, మీ కోసం మా వద్ద ఒక కథ ఉంది. మేము టరాన్టూల్‌లో స్టోరేజ్‌తో ఎలా పని చేయడం ప్రారంభించాము అనే కథ.
ఒకప్పుడు, మా కంపెనీకి రెండు "ఏకశిలాలు" మరియు ఒక "పైకప్పు" ఉన్నాయి, ఈ ఏకశిలాలు నెమ్మదిగా కానీ ఖచ్చితంగా చేరుకుంటాయి, మా కంపెనీ యొక్క విమానాన్ని, మా అభివృద్ధిని పరిమితం చేస్తాయి. మరియు స్పష్టమైన అవగాహన ఉంది: ఒక రోజు మేము ఈ పైకప్పును గట్టిగా కొట్టాము.
పరికరాల నుండి వ్యాపార తర్కం వరకు ప్రతిదీ మరియు ప్రతి ఒక్కరినీ వేరు చేయడం ఇప్పుడు ప్రబలంగా ఉన్న భావజాలం. ఫలితంగా, మేము, ఉదాహరణకు, నెట్‌వర్క్ స్థాయిలో ఆచరణాత్మకంగా స్వతంత్రంగా ఉండే రెండు DCలను కలిగి ఉన్నాము. ఆపై ప్రతిదీ పూర్తిగా భిన్నంగా ఉంది.
నేడు, CI/CD, K8S మొదలైన వాటి రూపంలో మార్పులు చేయడానికి చాలా సాధనాలు మరియు సాధనాలు ఉన్నాయి. "ఏకశిలా" సమయంలో, మాకు చాలా విదేశీ పదాలు అవసరం లేదు. డేటాబేస్లో "నిల్వ" సరిదిద్దడానికి ఇది సరిపోతుంది.
కానీ సమయం ముందుకు సాగింది మరియు అభ్యర్థనల సంఖ్య దానితో పాటు ముందుకు సాగింది, కొన్నిసార్లు మన సామర్థ్యాలకు మించి RPSని షూట్ చేస్తుంది. మార్కెట్‌లోకి CIS దేశాల ప్రవేశంతో, మొదటి ఏకశిలా యొక్క డేటాబేస్ ప్రాసెసర్‌పై లోడ్ 90% కంటే తగ్గలేదు మరియు RPS 2400 స్థాయికి చేరుకుంది. మరియు ఇవి కేవలం చిన్న సెలెక్టర్లు మాత్రమే కాదు, భారీ ప్రశ్నలు పెద్ద IO నేపథ్యానికి వ్యతిరేకంగా దాదాపు సగం డేటాను అమలు చేయగల చెక్‌లు మరియు JOINల సమూహం.
పూర్తి స్థాయి బ్లాక్ ఫ్రైడే అమ్మకాలు దృశ్యంలో కనిపించడం ప్రారంభించినప్పుడు - మరియు రష్యాలో వాటిని పట్టుకున్న మొదటి వాటిలో వైల్డ్‌బెర్రీస్ ఒకటి - పరిస్థితి పూర్తిగా విచారంగా మారింది. అన్ని తరువాత, అటువంటి రోజులలో లోడ్ మూడు సార్లు పెరుగుతుంది.
ఓహ్, ఈ "ఏకశిలా కాలాలు"! మీరు ఇలాంటిదే అనుభవించారని నేను ఖచ్చితంగా అనుకుంటున్నాను మరియు ఇది మీకు ఎలా జరుగుతుందో మీరు ఇప్పటికీ అర్థం చేసుకోలేరు.
మీరు ఏమి చేయవచ్చు - ఫ్యాషన్ సాంకేతికతలో అంతర్లీనంగా ఉంటుంది. సుమారు 5 సంవత్సరాల క్రితం, మేము .NET మరియు MS SQL సర్వర్‌లో ఇప్పటికే ఉన్న సైట్ రూపంలో ఈ మోడ్‌లలో ఒకదానిని పునరాలోచించవలసి వచ్చింది, ఇది సైట్ యొక్క అన్ని లాజిక్‌లను జాగ్రత్తగా నిల్వ చేస్తుంది. నేను దానిని చాలా జాగ్రత్తగా ఉంచాను, అలాంటి ఏకశిలాను కత్తిరించడం చాలా కాలం మరియు అంత సులభం కాదు.
ఒక చిన్న డైగ్రెషన్.
వివిధ కార్యక్రమాలలో నేను ఇలా అంటాను: "మీరు ఏకశిలాను చూడకపోతే, మీరు ఎదగలేదు!" ఈ విషయంపై మీ అభిప్రాయంపై నాకు ఆసక్తి ఉంది, దయచేసి వ్యాఖ్యలలో వ్రాయండి.
ఎ సౌండ్ ఆఫ్ థండర్
మన "భోగి మంట"కి తిరిగి వెళ్దాం. "మోనోలిథిక్" ఫంక్షనాలిటీ యొక్క లోడ్ను పంపిణీ చేయడానికి, ఓపెన్సోర్స్ టెక్నాలజీల ఆధారంగా సిస్టమ్ను మైక్రోసర్వీస్లుగా విభజించాలని మేము నిర్ణయించుకున్నాము. ఎందుకంటే, కనిష్టంగా, అవి స్కేల్ చేయడానికి చౌకగా ఉంటాయి. మరియు మేము స్కేల్ చేయవలసి ఉంటుందని (మరియు చాలా) 100% అవగాహన కలిగి ఉన్నాము. అన్ని తరువాత, ఇప్పటికే ఆ సమయంలో పొరుగు దేశాల మార్కెట్లలోకి ప్రవేశించడం సాధ్యమైంది మరియు రిజిస్ట్రేషన్ల సంఖ్య, అలాగే ఆర్డర్ల సంఖ్య మరింత బలంగా పెరగడం ప్రారంభమైంది.
మోనోలిత్ నుండి మైక్రోసర్వీస్‌కు బయలుదేరడానికి మొదటి అభ్యర్థులను విశ్లేషించిన తరువాత, వాటిలో 80% రచనలు బ్యాక్ ఆఫీస్ సిస్టమ్‌ల నుండి మరియు ఫ్రంట్ ఆఫీస్ నుండి చదవడం నుండి వస్తాయని మేము గ్రహించాము. అన్నింటిలో మొదటిది, ఇది మాకు రెండు ముఖ్యమైన ఉపవ్యవస్థలకు సంబంధించినది - వినియోగదారు డేటా మరియు అదనపు కస్టమర్ డిస్కౌంట్లు మరియు కూపన్ల గురించి సమాచారం ఆధారంగా వస్తువుల తుది ధరను లెక్కించే వ్యవస్థ.
ఇండెంట్ చేయబడింది. ఇప్పుడు ఊహించుకోవడానికే భయంగా ఉంది, కానీ పైన పేర్కొన్న సబ్‌సిస్టమ్‌లతో పాటు, ఉత్పత్తి కేటలాగ్‌లు, వినియోగదారు షాపింగ్ కార్ట్, ఉత్పత్తి శోధన సిస్టమ్, ఉత్పత్తి కేటలాగ్‌ల కోసం ఫిల్టరింగ్ సిస్టమ్ మరియు వివిధ రకాల సిఫార్సు సిస్టమ్‌లు కూడా మా ఏకశిలా నుండి తీసివేయబడ్డాయి. వాటిలో ప్రతి ఒక్కటి ఆపరేషన్ కోసం, ఇరుకైన అనుకూలమైన వ్యవస్థల యొక్క ప్రత్యేక తరగతులు ఉన్నాయి, కానీ ఒకప్పుడు వారందరూ ఒకే "ఇల్లు" లో నివసించారు.
మేము వెంటనే మా క్లయింట్‌ల గురించిన డేటాను షార్డ్ సిస్టమ్‌కు బదిలీ చేయాలని ప్లాన్ చేసాము. వస్తువుల యొక్క తుది ధరను లెక్కించడానికి కార్యాచరణను తీసివేయడానికి చదవడానికి మంచి స్కేలబిలిటీ అవసరం, ఎందుకంటే ఇది గొప్ప RPS లోడ్ను సృష్టించింది మరియు డేటాబేస్ కోసం అమలు చేయడం చాలా కష్టం (గణన ప్రక్రియలో చాలా డేటా పాల్గొంటుంది).
ఫలితంగా, మేము టరాన్టూల్‌కు బాగా సరిపోయే పథకాన్ని రూపొందించాము.
ఆ సమయంలో, మైక్రోసర్వీస్ యొక్క ఆపరేషన్ కోసం, వర్చువల్ మరియు హార్డ్‌వేర్ మెషీన్‌లపై అనేక డేటా సెంటర్‌లతో పనిచేయడానికి పథకాలు ఎంపిక చేయబడ్డాయి. బొమ్మల్లో చూపినట్లుగా, మాస్టర్-మాస్టర్ మరియు మాస్టర్-స్లేవ్ మోడ్‌లలో టరాన్టూల్ రెప్లికేషన్ ఎంపికలు వర్తింపజేయబడ్డాయి.
ఆర్కిటెక్చర్. ఎంపిక 1. వినియోగదారు సేవ
ప్రస్తుత సమయంలో, 24 ముక్కలు ఉన్నాయి, వీటిలో ప్రతి ఒక్కటి 2 సందర్భాలు (ప్రతి DCకి ఒకటి), అన్నీ మాస్టర్-మాస్టర్ మోడ్‌లో ఉన్నాయి.
డేటాబేస్ పైన డేటాబేస్ ప్రతిరూపాలను యాక్సెస్ చేసే అప్లికేషన్లు ఉన్నాయి. Tarantool Go డ్రైవర్ ఇంటర్‌ఫేస్‌ని అమలు చేసే మా అనుకూల లైబ్రరీ ద్వారా అప్లికేషన్లు Tarantoolతో పని చేస్తాయి. ఆమె అన్ని ప్రతిరూపాలను చూస్తుంది మరియు చదవడానికి మరియు వ్రాయడానికి మాస్టర్‌తో కలిసి పని చేయగలదు. ముఖ్యంగా, ఇది రెప్లికా సెట్ మోడల్‌ను అమలు చేస్తుంది, ఇది ప్రతిరూపాలను ఎంచుకోవడం, మళ్లీ ప్రయత్నించడం, సర్క్యూట్ బ్రేకర్ మరియు రేట్ పరిమితి కోసం లాజిక్‌ను జోడిస్తుంది.
ఈ సందర్భంలో, షార్డ్‌ల సందర్భంలో ప్రతిరూప ఎంపిక విధానాన్ని కాన్ఫిగర్ చేయడం సాధ్యపడుతుంది. ఉదాహరణకు, రౌండ్రోబిన్.
ఆర్కిటెక్చర్. ఎంపిక 2. వస్తువుల తుది ధరను లెక్కించడానికి సేవ
కొన్ని నెలల క్రితం, వస్తువుల తుది ధరను లెక్కించడానికి చాలా అభ్యర్థనలు కొత్త సేవకు వెళ్లాయి, ఇది సూత్రప్రాయంగా, డేటాబేస్ లేకుండా పనిచేస్తుంది, అయితే కొంతకాలం క్రితం హుడ్ కింద టరాన్టూల్‌తో కూడిన సేవ ద్వారా ప్రతిదీ 100% ప్రాసెస్ చేయబడింది.
సర్వీస్ డేటాబేస్ 4 మాస్టర్‌లను కలిగి ఉంటుంది, వీటిలో సింక్రోనైజర్ డేటాను సేకరిస్తుంది మరియు ఈ రెప్లికేషన్ మాస్టర్‌లలో ప్రతి ఒక్కటి రీడ్‌ఓన్లీ రెప్లికాస్‌కు డేటాను పంపిణీ చేస్తుంది. ప్రతి మాస్టర్ దాదాపు 15 అటువంటి ప్రతిరూపాలను కలిగి ఉంటారు.
మొదటి స్కీమ్‌లో లేదా రెండవ స్కీమ్‌లో, ఒక DC అందుబాటులో లేకుంటే, అప్లికేషన్ రెండవ దానిలో డేటాను స్వీకరించగలదు.
టరాన్టూల్‌లో ప్రతిరూపణ చాలా సరళమైనది మరియు రన్‌టైమ్‌లో కాన్ఫిగర్ చేయబడుతుందని గమనించాలి. ఇతర వ్యవస్థలలో, ఇబ్బందులు తలెత్తాయి. ఉదాహరణకు, PostgreSQLలో max_wal_senders మరియు max_replication_slots పారామితులను మార్చడానికి విజార్డ్ పునఃప్రారంభించవలసి ఉంటుంది, ఇది కొన్ని సందర్భాల్లో అప్లికేషన్ మరియు DBMS మధ్య కనెక్షన్‌లను విడదీయడానికి దారితీయవచ్చు.
వెతకండి మరియు మీరు కనుగొంటారు!
ఎందుకు మేము "సాధారణ వ్యక్తుల వలె" చేయలేదు, కానీ ఒక విలక్షణమైన మార్గాన్ని ఎంచుకున్నాము? ఇది సాధారణమైనదిగా పరిగణించబడే దానిపై ఆధారపడి ఉంటుంది. చాలా మంది వ్యక్తులు సాధారణంగా మొంగో నుండి ఒక క్లస్టర్‌ను తయారు చేస్తారు మరియు దానిని మూడు జియో-డిస్ట్రిబ్యూటెడ్ DCలలో విస్తరించారు.
ఆ సమయంలో, మాకు ఇప్పటికే రెండు రెడిస్ ప్రాజెక్ట్‌లు ఉన్నాయి. మొదటిది కాష్, మరియు రెండవది చాలా క్లిష్టమైన డేటా కోసం నిరంతర నిల్వ. ఇది అతనితో చాలా కష్టం, కొంతవరకు మా తప్పు. కొన్నిసార్లు చాలా పెద్ద వాల్యూమ్‌లు కీలో ఉన్నాయి మరియు ఎప్పటికప్పుడు సైట్ అనారోగ్యానికి గురవుతుంది. మేము ఈ సిస్టమ్ను మాస్టర్-స్లేవ్ వెర్షన్‌లో ఉపయోగించాము. మరియు మాస్టర్‌కు ఏదో జరిగినప్పుడు మరియు ప్రతిరూపం విరిగిపోయిన సందర్భాలు చాలా ఉన్నాయి.
అంటే, రెడిస్ స్టేట్‌లెస్ పనులకు మంచిది, రాష్ట్రానికి సంబంధించిన వాటికి కాదు. సూత్రప్రాయంగా, ఇది చాలా సమస్యలను పరిష్కరించడానికి అనుమతించింది, కానీ అవి ఒక జత సూచికలతో కీలక-విలువ పరిష్కారాలు అయితే మాత్రమే. కానీ ఆ సమయంలో రెడిస్ పట్టుదల మరియు ప్రతిరూపణతో చాలా విచారంగా ఉన్నాడు. అదనంగా, పనితీరుపై ఫిర్యాదులు ఉన్నాయి.
మేము MySQL మరియు PostgreSQL గురించి ఆలోచించాము. కానీ మొదటిది ఏదో ఒకవిధంగా మాతో పట్టుకోలేదు మరియు రెండవది దానికదే అధునాతనమైన ఉత్పత్తి, మరియు దానిపై సాధారణ సేవలను నిర్మించడం సరికాదు.
మేము RIAK, Cassandra, గ్రాఫ్ డేటాబేస్‌ని కూడా ప్రయత్నించాము. సేవలను రూపొందించడానికి సాధారణ సార్వత్రిక సాధనం పాత్రకు సరిపోని అన్ని సముచిత పరిష్కారాలు.
చివరికి మేము టరాన్టూల్‌లో స్థిరపడ్డాము.
ఇది వెర్షన్ 1.6లో ఉన్నప్పుడు మేము దానిని ఆశ్రయించాము. కీ-విలువ యొక్క సహజీవనం మరియు రిలేషనల్ డేటాబేస్ యొక్క కార్యాచరణ ద్వారా మేము దానిపై ఆసక్తిని కలిగి ఉన్నాము. ద్వితీయ సూచికలు, లావాదేవీలు మరియు ఖాళీలు ఉన్నాయి, ఇవి పట్టికల వలె ఉంటాయి, కానీ సాధారణమైనవి కావు, మీరు వాటిలో వేర్వేరు సంఖ్యలో నిలువు వరుసలను నిల్వ చేయవచ్చు. కానీ టరాన్టూల్ యొక్క కిల్లర్ లక్షణం కీ-విలువ మరియు లావాదేవీలతో కలిపి ద్వితీయ సూచికలు.
చాట్‌లో సహాయం చేయడానికి సిద్ధంగా ఉన్న ప్రతిస్పందించే రష్యన్ మాట్లాడే సంఘం కూడా పాత్ర పోషించింది. మేము దీన్ని చురుకుగా ఉపయోగించాము మరియు నేరుగా చాట్‌లో నివసిస్తున్నాము. మరియు స్పష్టమైన తప్పులు మరియు తప్పులు లేకుండా మంచి పట్టుదల గురించి మర్చిపోవద్దు. మీరు టరాన్టూల్‌తో మా చరిత్రను పరిశీలిస్తే, ప్రతిరూపణతో మాకు చాలా నొప్పి మరియు వైఫల్యాలు ఉన్నాయి, కానీ దాని లోపం కారణంగా మేము డేటాను కోల్పోలేదు!
అమలు ఒక కఠినమైన ప్రారంభానికి వచ్చింది
ఆ సమయంలో, మా ప్రధాన అభివృద్ధి స్టాక్ .NET, దీనికి టరాన్టూల్‌కు కనెక్టర్ లేదు. మేము వెంటనే గోలో ఏదో చేయడం ప్రారంభించాము. ఇది లువాతో కూడా బాగా పనిచేసింది. ఆ సమయంలో ప్రధాన సమస్య డీబగ్గింగ్‌తో ఉంది: .NETలో దీనితో ప్రతిదీ చాలా బాగుంది, కానీ ఆ తర్వాత మీకు లాగ్‌లు తప్ప డీబగ్గింగ్ లేనప్పుడు ఎంబెడెడ్ లువా ప్రపంచంలోకి ప్రవేశించడం కష్టం. అదనంగా, కొన్ని కారణాల వల్ల ప్రతిరూపణ క్రమానుగతంగా విడిపోతుంది, కాబట్టి నేను టరాన్టూల్ ఇంజిన్ యొక్క నిర్మాణాన్ని లోతుగా పరిశోధించవలసి వచ్చింది. చాట్ దీనికి సహాయపడింది మరియు కొంత మేరకు డాక్యుమెంటేషన్; కొన్నిసార్లు మేము కోడ్‌ని చూసాము. ఆ సమయంలో, డాక్యుమెంటేషన్ అలా ఉంది.
కాబట్టి, చాలా నెలల వ్యవధిలో, నేను టరాన్టూల్‌తో కలిసి పని చేయడం ద్వారా నా తల చుట్టూ తిరుగుతూ మంచి ఫలితాలను పొందగలిగాను. మేము కొత్త మైక్రోసర్వీస్‌ల ఏర్పాటుకు సహాయపడే రిఫరెన్స్ డెవలప్‌మెంట్‌లను gitలో సంకలనం చేసాము. ఉదాహరణకు, ఒక పని తలెత్తినప్పుడు: మరొక మైక్రోసర్వీస్‌ని సృష్టించడానికి, డెవలపర్ రిపోజిటరీలోని రిఫరెన్స్ సొల్యూషన్ యొక్క సోర్స్ కోడ్‌ను చూశారు మరియు కొత్తదాన్ని సృష్టించడానికి ఒక వారం కంటే ఎక్కువ సమయం పట్టదు.
ఇవి ప్రత్యేక సమయాలు. సాంప్రదాయకంగా, మీరు తదుపరి టేబుల్‌లోని నిర్వాహకుని వద్దకు వెళ్లి ఇలా అడగవచ్చు: "నాకు వర్చువల్ మెషీన్ ఇవ్వండి." దాదాపు ముప్పై నిమిషాల తర్వాత కారు మీ వద్ద ఉంది. మీరు మీరే కనెక్ట్ అయ్యారు, ప్రతిదీ ఇన్‌స్టాల్ చేసారు మరియు మీకు ట్రాఫిక్ పంపబడింది.
ఈ రోజు ఇది పని చేయదు: మీరు సేవకు పర్యవేక్షణ మరియు లాగింగ్‌ను జోడించాలి, పరీక్షలతో కార్యాచరణను కవర్ చేయాలి, వర్చువల్ మెషీన్‌ను ఆర్డర్ చేయాలి లేదా కుబేర్‌కు డెలివరీ చేయాలి మొదలైనవి. సాధారణంగా, ఈ విధంగా మెరుగ్గా ఉంటుంది, అయితే ఇది ఎక్కువ సమయం పడుతుంది మరియు మరింత సమస్యాత్మకంగా ఉంటుంది.
విభజించి పాలించు. లువాతో ఒప్పందం ఏమిటి?
తీవ్రమైన సందిగ్ధత ఏర్పడింది: కొన్ని బృందాలు లువాలో చాలా లాజిక్‌లు ఉన్న సేవకు విశ్వసనీయంగా మార్పులను అందించలేకపోయాయి. ఇది తరచుగా సేవ పనిచేయకపోవటంతో పాటుగా ఉంటుంది.
అంటే, డెవలపర్లు ఒక రకమైన మార్పును సిద్ధం చేస్తున్నారు. టరాన్టూల్ మైగ్రేషన్ చేయడం ప్రారంభిస్తుంది, కానీ ప్రతిరూపం ఇప్పటికీ పాత కోడ్‌తో ఉంటుంది; కొన్ని DDL లేదా మరేదైనా ప్రతిరూపణ ద్వారా అక్కడికి చేరుకుంటుంది మరియు అది పరిగణనలోకి తీసుకోనందున కోడ్ విడిపోతుంది. ఫలితంగా, నిర్వాహకుల కోసం నవీకరణ విధానం A4 షీట్‌లో రూపొందించబడింది: ప్రతిరూపణను ఆపండి, దీన్ని నవీకరించండి, ప్రతిరూపణను ఆన్ చేయండి, ఇక్కడ ఆఫ్ చేయండి, అక్కడ అప్‌డేట్ చేయండి. పీడకల!
ఫలితంగా, ఇప్పుడు మేము చాలా తరచుగా లువాలో ఏమీ చేయడానికి ప్రయత్నిస్తాము. iproto (సర్వర్‌తో పరస్పర చర్య చేయడానికి బైనరీ ప్రోటోకాల్) ఉపయోగించండి మరియు అంతే. బహుశా ఇది డెవలపర్లలో జ్ఞానం లేకపోవడం, కానీ ఈ దృక్కోణం నుండి సిస్టమ్ సంక్లిష్టంగా ఉంటుంది.
మేము ఎల్లప్పుడూ ఈ స్క్రిప్ట్‌ను గుడ్డిగా అనుసరించము. ఈ రోజు మనకు నలుపు మరియు తెలుపు రంగులు లేవు: ప్రతిదీ లువాలో ఉంది లేదా ప్రతిదీ గోలో ఉంది. మేము వాటిని ఎలా కలపవచ్చో మేము ఇప్పటికే అర్థం చేసుకున్నాము, తద్వారా మేము తరువాత వలస సమస్యలతో ముగుస్తుంది.
ఇప్పుడు టరాన్టూల్ ఎక్కడ ఉంది?
"ప్రమోటర్" అని కూడా పిలువబడే డిస్కౌంట్ కూపన్‌లను పరిగణనలోకి తీసుకొని వస్తువుల తుది ధరను లెక్కించడానికి టరాన్టూల్ సేవలో ఉపయోగించబడుతుంది. నేను ముందే చెప్పినట్లుగా, అతను ఇప్పుడు పదవీ విరమణ చేస్తున్నాడు: అతను ముందుగా లెక్కించిన ధరలతో కొత్త కేటలాగ్ సేవ ద్వారా భర్తీ చేయబడతాడు, అయితే ఆరు నెలల క్రితం అన్ని లెక్కలు ప్రమోటైజర్‌లో చేయబడ్డాయి. ఇంతకుముందు, దాని తర్కంలో సగం లువాలో వ్రాయబడింది. రెండు సంవత్సరాల క్రితం, సేవను నిల్వ సౌకర్యంగా మార్చారు మరియు తర్కం గోలో తిరిగి వ్రాయబడింది, ఎందుకంటే డిస్కౌంట్ల మెకానిక్‌లు కొద్దిగా మారాయి మరియు సేవ పనితీరు లోపించింది.
అత్యంత క్లిష్టమైన సేవల్లో ఒకటి వినియోగదారు ప్రొఫైల్. అంటే, Wildberries వినియోగదారులందరూ Tarantoolలో నిల్వ చేయబడతారు మరియు వారిలో దాదాపు 50 మిలియన్లు ఉన్నారు. గో సేవలకు కనెక్ట్ చేయబడిన అనేక DCలలో పంపిణీ చేయబడిన వినియోగదారు ID ద్వారా విభజించబడిన సిస్టమ్.
RPS ప్రకారం, ప్రమోటర్ ఒకప్పుడు నాయకుడు, 6 వేల అభ్యర్థనలను చేరుకుంది. ఒకానొక సమయంలో మా దగ్గర 50-60 కాపీలు ఉన్నాయి. ఇప్పుడు RPSలో అగ్రగామి వినియోగదారు ప్రొఫైల్‌లు, దాదాపు 12 వేలు. ఈ సేవ వినియోగదారు IDల పరిధుల ద్వారా విభజించబడిన కస్టమ్ షార్డింగ్‌ని ఉపయోగిస్తుంది. సేవ 20 కంటే ఎక్కువ యంత్రాలకు సేవలు అందిస్తుంది, కానీ ఇది చాలా ఎక్కువ; మేము కేటాయించిన వనరులను తగ్గించాలని ప్లాన్ చేస్తున్నాము, ఎందుకంటే 4-5 యంత్రాల సామర్థ్యం దీనికి సరిపోతుంది.
సెషన్ సేవ vshard మరియు కార్ట్రిడ్జ్‌లో మా మొదటి సేవ. vshardని సెటప్ చేయడానికి మరియు కార్ట్రిడ్జ్‌ని అప్‌డేట్ చేయడానికి మా నుండి కొంత ప్రయత్నం అవసరం, కానీ చివరికి ప్రతిదీ పని చేసింది.
వెబ్‌సైట్‌లో మరియు మొబైల్ అప్లికేషన్‌లో విభిన్న బ్యానర్‌లను ప్రదర్శించే సేవ Tarantoolలో నేరుగా విడుదల చేయబడిన వాటిలో మొదటిది. ఈ సేవ 6-7 సంవత్సరాల వయస్సులో ఉంది, ఇది ఇప్పటికీ అమలులో ఉంది మరియు ఎప్పుడూ రీబూట్ చేయబడలేదు. మాస్టర్-మాస్టర్ రెప్లికేషన్ ఉపయోగించబడింది. ఏదీ విరిగిపోలేదు.
కొన్ని సందర్భాల్లో సమాచారాన్ని త్వరగా రెండుసార్లు తనిఖీ చేయడానికి గిడ్డంగి వ్యవస్థలో త్వరిత సూచన కార్యాచరణ కోసం టరాన్టూల్‌ను ఉపయోగించే ఉదాహరణ ఉంది. మేము దీని కోసం Redisని ఉపయోగించడానికి ప్రయత్నించాము, కానీ మెమరీలోని డేటా Tarantool కంటే ఎక్కువ స్థలాన్ని ఆక్రమించింది.
వెయిటింగ్ లిస్ట్, క్లయింట్ సబ్‌స్క్రిప్షన్‌లు, ప్రస్తుతం ఫ్యాషనబుల్ కథనాలు మరియు వాయిదా వేసిన వస్తువులు కూడా Tarantoolతో పని చేస్తాయి. మెమరీలో చివరి సేవ సుమారు 120 GB పడుతుంది. ఇది పైన పేర్కొన్న వాటిలో అత్యంత సమగ్రమైన సేవ.
తీర్మానం
కీ-విలువ మరియు లావాదేవీలతో కూడిన ద్వితీయ సూచికలకు ధన్యవాదాలు, Tarantool మైక్రోసర్వీస్-ఆధారిత నిర్మాణాలకు బాగా సరిపోతుంది. అయినప్పటికీ, లువాలో చాలా లాజిక్‌లతో సేవలకు మార్పులను రోల్ చేస్తున్నప్పుడు మేము ఇబ్బందులను ఎదుర్కొన్నాము - సేవలు తరచుగా పనిచేయడం మానేస్తాయి. మేము దీనిని అధిగమించలేకపోయాము మరియు కాలక్రమేణా మేము లువా మరియు గో యొక్క విభిన్న కలయికలకు వచ్చాము: ఒక భాషను ఎక్కడ ఉపయోగించాలో మరియు మరొక భాషను ఎక్కడ ఉపయోగించాలో మాకు తెలుసు.
అంశంపై ఇంకా ఏమి చదవాలి
- Tarantool ఉపయోగించి మొదటి నుండి అధిక-లోడ్ అప్లికేషన్‌ను సృష్టిస్తోంది
- Tarantool కార్ట్రిడ్జ్‌లో విశ్వసనీయ నాయకుని ఎంపిక
- ఉత్పత్తి గురించిన వార్తలతో టెలిగ్రామ్ ఛానెల్ టరాన్టూల్
- కమ్యూనిటీ చాట్‌లో టరాన్టూల్ గురించి చర్చించండి
మూలం: www.habr.com