ווען איר קומען צו אַ פּראָדוקט וואָס איז דעוועלאָפּעד פֿאַר מער ווי אַ יאָרצענדלינג, עס איז נישט חידוש צו געפֿינען אַוטדייטיד טעקנאַלאַדזשיז אין עס. אבער וואָס אויב אין זעקס חדשים איר האָבן צו האַלטן די מאַסע 10 מאל העכער, און די פּרייַז פון פאלס וועט פאַרגרעסערן הונדערטער פון מאל? אין דעם פאַל, איר דאַרפֿן אַ קיל היגהלאָאַד ינזשעניר. אָבער אין דער אַוועק פון אַ דינסט, זיי ענטראַסטיד מיר צו לייזן דעם פּראָבלעם. אין דער ערשטער טייל פון דעם אַרטיקל איך וועט זאָגן איר ווי מיר אריבערגעפארן פון Redis צו Redis-cluster, און אין די צווייטע טייל איך וועל געבן עצה ווי צו אָנהייבן ניצן דעם קנויל און וואָס צו באַצאָלן ופמערקזאַמקייט צו ווען איר נוצן עס.

סעלעקציע פון ​​טעכנאָלאָגיע

איז עס אַזוי שלעכט? באַזונדער Redis (standalone redis) в конфигурации 1 мастер и N слейвов? Почему я называю его устаревшей технологией?

Нет, Redis не так плох… Однако, есть некоторые недочеты которые нельзя игнорировать.

• ערשטער, Redis שטיצט נישט ומגליק אָפּזוך מעקאַניזאַמז נאָך אַ בעל דורכפאַל. צו סאָלווע דעם פּראָבלעם, מיר געוויינט אַ קאַנפיגיעריישאַן מיט אָטאַמאַטיק אַריבערפירן פון וויפּס צו אַ נייַ בעל, טשאַנגינג די ראָלע פון ​​איינער פון די סלאַוועס און באַשטימען די מנוחה. דעם מעקאַניזאַם געארבעט, אָבער עס קען נישט זיין גערופֿן אַ פאַרלאָזלעך לייזונג. ערשטער, פאַלש אַלאַרמס פארגעקומען, און צווייטנס, עס איז געווען דיספּאָוזאַבאַל, און נאָך אָפּעראַציע מאַנואַל אַקשאַנז זענען פארלאנגט צו באַשולדיקן די פרילינג.

• צווייטנס, ווייל בלויז איין בעל געפירט צו די פּראָבלעם פון שאַרדינג. מיר האָבן צו שאַפֿן עטלעכע פרייַ קלאַסטערז "1 בעל און ען סלאַוועס," און מאַניואַלי פאַרשפּרייטן די דאַטאַבייסיז צווישן די מאשינען און האָפֿן אַז מאָרגן איינער פון די דאַטאַבייסיז וועט נישט טייַער אַזוי פיל אַז עס וואָלט זיין אריבערגעפארן צו אַ באַזונדער בייַשפּיל.

וואָס זענען די אָפּציעס?

• Самое дорогое и богатое решение — Redis-Enterprise. Это коробочное решение с полной технической поддержкой. Несмотря на то, что оно выглядит идеальным с технической точки зрения, нам не подошло по идеологическим соображениям.
• Redis-cluster. Из коробки есть поддержка аварийного переключения мастера и шардирования. Интерфейс почти не отличается от обычной версии. Выглядит многообещающе, про подводные камни поговорим далее.
• Tarantool, Memcache, Aerospike און אנדערע. אַלע די מכשירים טאָן כּמעט די זעלבע זאַך. אבער יעדער האט זייַן אייגענע חסרונות. מיר באַשלאָסן נישט צו שטעלן אַלע אונדזער עגגס אין איין קאָרב. מיר נוצן Memcache און Tarantool פֿאַר אנדערע טאַסקס, און, קוק פאָרויס, איך וועל זאָגן אַז אין אונדזער פיר עס זענען געווען מער פּראָבלעמס מיט זיי.

ספּעסיפיקס פון נוצן

Давайте взглянем, какие задачи мы исторически решали Redis’ом и какую функциональность использовали:

• Кеш перед запросами к удаленным сервисам вроде 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• קאַש איידער MYSQL | פפּ
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Основное хранилище для сервиса работы с сессиями и координатами водителей | Golang
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Как видите, никакой высшей математики. В чём же тогда сложность? Давайте разберем отдельно по каждому методу.

אופֿן
באַשרייַבונג
פֿעיִקייטן פון Redis-קנויל
באַשייד

באַקומען שטעלן
שרייב / לייענען שליסל

MGET MSET
שרייב / לייענען קייפל שליסלען
Ключи будут лежать на разных нодах. Готовые библиотеки умеют делать Multi-операции только в рамках одной ноды
Заменить MGET на pipeline из N GET операций

אויסקלייַבן דב
Выбрать базу, с которой будем работать
שטיצט נישט קייפל דאַטאַבייסיז
Складывать всё в одну базу. Добавить к ключам префиксы

יבערקוקן
גיין דורך אַלע די שליסלען אין די דאַטאַבייס
Поскольку у нас одна база, проходить по всем ключам в кластере слишком затратно
Поддерживать инвариант внутри одного ключа и делать HSCAN по этому ключу. Или отказаться совсем

געאָ
אַפּעריישאַנז מיט אַ געאָקיי
Геоключ не шардируется

שליסל דורך מוסטער
זוכן פֿאַר אַ שליסל דורך מוסטער
Поскольку у нас одна база, будем искать по всем ключам в кластере. Слишком затратно
Отказаться или поддерживать инвариант, как и в случае со SCAN-ом

Redis ווס Redis-cluster

Что мы теряем и что получаем при переходе на кластер?

• Недостатки: теряем функциональность нескольких баз.
  • Если мы хотим хранить в одном кластере логически не связанные данные, придется делать костыли в виде префиксов.
  • Теряем все операции «по базе», такие как SCAN, DBSIZE, CLEAR DB и т.п.
  • Multi-операции стали значительно сложнее в реализации, потому что может требоваться обращение к нескольким нодам.
• Pluses:
  • Отказоустойчивость в виде аварийного переключения мастера.
  • שאַרדינג אויף די רעדיס זייַט.
  • Перенос данных между нодами атомарно и без простоев.
  • Добавление и перераспределение мощностей и нагрузок без простоев.

איך וואָלט פאַרענדיקן אַז אויב איר טאָן ניט דאַרפֿן צו צושטעלן אַ הויך מדרגה פון שולד טאָלעראַנץ, מאַך צו אַ קנויל איז נישט ווערט עס, ווייַל עס קען זיין אַ ניט-ניט-ניטוויאַל אַרבעט. אבער אויב איר טכילעס קלייַבן צווישן אַ באַזונדער ווערסיע און אַ קנויל ווערסיע, איר זאָל קלייַבן אַ קנויל, ווייַל עס איז נישט ערגער און, אין דערצו, איר וועט באַפרייַען עטלעכע כעדייקס.

פּריפּערינג צו רירן

Начнем с требований к переезду:

• Он должен быть бесшовным. Полная остановка сервиса на 5 минут нас не устраивает.
• Он должен быть максимально безопасным и постепенным. Хочется иметь какой-то контроль над ситуацией. Бухнуть сразу всё и молиться над кнопкой отката мы не желаем.
• Минимальные потери данных при переезде. Мы понимаем, что переехать атомарно будет очень сложно, поэтому допускаем некоторую рассинхронизацию между данными в обычном и кластерном Redis.

קנויל וישאַלט

Перед самым переездом следует задуматься о том, а можем ли мы поддерживать кластер:

• Графики. Мы используем Prometheus и Grafana для графиков загрузки процессоров, занятой памяти, количества клиентов, количества операций GET, SET, AUTH и т.п.
• עקספּערטיז. ימאַדזשאַן אַז מאָרגן איר וועט האָבן אַ ריזיק קנויל אונטער דיין פֿאַראַנטוואָרטלעכקייט. אויב עס ברייקס, קיין איינער אָבער איר קענען פאַרריכטן עס. אויב ער הייבט צו פּאַמעלעך אַראָפּ, אַלעמען וועט לויפן צו איר. אויב איר דאַרפֿן צו לייגן רעסורסן אָדער רידיסטריביוטינג די מאַסע, קום צוריק צו איר. אין סדר נישט צו ווערן גרוי ביי 25, עס איז קעדייַיק צו צושטעלן די קאַסעס און קאָנטראָלירן אין שטייַגן ווי די טעכנאָלאָגיע וועט זיין ביכייווד אונטער זיכער אַקשאַנז. לאָמיר רעדן וועגן דעם אין מער דעטאַל אין די אָפּטיילונג "עקספּערטיז".
• מאָניטאָרינג און אַלערץ. ווען אַ קנויל ברייקס אַראָפּ, איר ווילן צו זיין דער ערשטער צו וויסן וועגן אים. דאָ מיר לימיטעד זיך צו אַ אָנזאָג אַז אַלע נאָודז צוריקקומען די זעלבע אינפֿאָרמאַציע וועגן די שטאַט פון די קנויל (יאָ, עס כאַפּאַנז אַנדערש). און אנדערע פּראָבלעמס קענען זיין באמערקט מער געשווינד דורך אַלערץ פון Redis קליענט באַדינונגס.

רילאָוקיישאַן

ווי מיר וועלן מאַך:

• ערשטער פון אַלע, איר דאַרפֿן צו צוגרייטן אַ ביבליאָטעק צו אַרבעטן מיט דעם קנויל. מיר גענומען Go-Redis ווי די יקער פֿאַר די Go ווערסיע און טשיינדזשד עס אַ ביסל צו פּאַסן זיך. מיר ימפּלאַמענאַד מולטי-מעטאַדס דורך פּייפּליינז, און אויך אַ ביסל קערעקטאַד די כּללים פֿאַר ריפּיטינג ריקוועס. די PHP ווערסיע האט מער פּראָבלעמס, אָבער מיר יווענטשאַוואַלי געזעצט אויף php-redis. זיי לעצטנס באַקענענ קנויל שטיצן און עס קוקט גוט אין אונדזער מיינונג.
• Далее нужно развернуть сам кластер. Делается это буквально в две команды на основе конфигурационного файла. Подробнее настройку обсудим ниже.
• פֿאַר גראַדזשואַל מאָווינג מיר נוצן טרוקן מאָדע. זינט מיר האָבן צוויי ווערסיעס פון דער ביבליאָטעק מיט דער זעלביקער צובינד (איינער פֿאַר די רעגולער ווערסיע, די אנדערע פֿאַר די קנויל), עס קאָס גאָרנישט צו שאַפֿן אַ ראַפּער וואָס וועט אַרבעטן מיט אַ באַזונדער ווערסיע און אין פּאַראַלעל דופּליקאַט אַלע ריקוועס צו דעם קנויל, פאַרגלייַכן רעספּאָנסעס און שרייַבן דיסקרעפּאַנסיז אין די לאָגס (אין אונדזער פאַל אין NewRelic). אזוי, אפילו אויב די קנויל ווערסיע ברייקס בעשאַס ראָולאַוט, אונדזער פּראָדוקציע וועט נישט זיין אַפעקטאַד.
• נאָך ראָולד אויס דעם קנויל אין טרוקן מאָדע, מיר קענען רויק קוק אין די גראַפיק פון ענטפער דיסקרעפּאַנסיז. אויב דער טעות קורס סלאָולי אָבער שורלי באוועגט צו אַ קליין קעסיידערדיק, אַלץ איז גוט. פארוואס זענען נאָך דיפעראַנסיז? ווייַל רעקאָרדינג אין אַ באַזונדער ווערסיע אַקערז אַ ביסל פריער ווי אין די קנויל, און רעכט צו מיקראָלאַג, די דאַטן קען דייווערדזש. אַלע וואָס בלייבט איז צו קוקן אין די דיסקרעפּאַנסי לאָגס, און אויב זיי זענען אַלע דערקלערט דורך די ניט-אַטאָמיסיטי פון די רעקאָרד, מיר קענען מאַך אויף.
• איצט איר קענען באַשטימען טרוקן מאָדע אין די פאַרקערט ריכטונג. מיר וועלן שרייַבן און לייענען פון דעם קנויל, און דופּליקאַט עס אין אַ באַזונדער ווערסיע. צו וואס? אין דער ווייַטער וואָך איך וואָלט ווי צו אָבסערווירן די אַרבעט פון דעם קנויל. אויב עס פּלוצלינג טורנס אויס אַז עס זענען פּראָבלעמס אין שפּיץ מאַסע, אָדער מיר האָבן נישט נעמען עפּעס אין חשבון, מיר שטענדיק האָבן אַ נויטפאַל ראָולבאַק צו די אַלט קאָד און קראַנט דאַטן דאַנק צו טרוקן מאָדע.
• Осталось отключить dry-mode и демонтировать отдельную версию.

עקספּערטיז

ערשטער, בעקיצער וועגן דעם קנויל פּלאַן.

ערשטער פון אַלע, Redis איז אַ שליסל-ווערט קראָם. אַרביטראַריש סטרינגס זענען געניצט ווי שליסלען. נומערן, סטרינגס און גאַנץ סטראַקטשערז קענען זיין געוויינט ווי וואַלועס. עס זענען דא אסאך פון די לעצטע, אבער צו פארשטיין די אלגעמיינע סטרוקטור איז דאס נישט וויכטיג פאר אונז.
דער ווייַטער מדרגה פון אַבסטראַקציע נאָך שליסלען איז סלאָץ (SLOTS). יעדער שליסל געהערט צו איינער פון 16 סלאָץ. עס קענען זיין קיין נומער פון שליסלען אין יעדער שפּעלטל. אזוי, אַלע שליסלען זענען צעטיילט אין 383 דיסדזשוינט שטעלט.

ווייַטער, עס מוזן זיין N בעל נאָודז אין דעם קנויל. יעדער נאָדע קענען זיין קאַנסידערד ווי אַ באַזונדער רעדיס בייַשפּיל וואָס ווייסט אַלץ וועגן אנדערע נאָודז אין דעם קנויל. יעדער בעל נאָדע כּולל אַ נומער פון סלאָץ. יעדער שפּעלטל געהערט צו בלויז איין בעל נאָדע. אַלע סלאָץ דאַרפֿן צו זיין פונאנדערגעטיילט צווישן נאָודז. אויב עטלעכע סלאָץ זענען נישט אַלאַקייטיד, די שליסלען סטאָרד אין זיי וועט זיין ינאַקסעסאַבאַל. עס מאכט זינען צו לויפן יעדער בעל נאָדע אויף אַ באַזונדער לאַדזשיקאַל אָדער גשמיות מאַשין. עס איז אויך כדאי צו געדענקען אַז יעדער נאָדע לויפט בלויז אויף איין האַרץ, און אויב איר ווילן צו לויפן קייפל Redis ינסטאַנסיז אויף דער זעלביקער לאַדזשיקאַל מאַשין, מאַכן זיכער אַז זיי לויפן אויף פאַרשידענע קאָרעס (מיר האָבן נישט געפרוווט דאָס, אָבער אין טעאָריע עס זאָל אַרבעטן) . יסענשאַלי, בעל נאָודז צושטעלן רעגולער שאַרדינג, און מער בעל נאָודז לאָזן שרייַבן און לייענען ריקוועס צו וואָג.

נאָך אַלע די שליסלען זענען פונאנדערגעטיילט צווישן די סלאָץ, און די סלאָץ זענען צעוואָרפן צווישן די בעל נאָודז, אַ אַרביטראַריש נומער פון שקלאַף נאָודז קענען זיין מוסיף צו יעדער בעל נאָדע. אין יעדער אַזאַ בעל-שקלאַף לינק, נאָרמאַל רעפּלאַקיישאַן וועט אַרבעטן. סלאַוועס זענען דארף צו וואָג לייענען ריקוועס און פֿאַר פאַילאָווער אין פאַל פון בעל דורכפאַל.

Теперь поговорим об операциях, которые лучше бы уметь делать.

מיר וועלן אַקסעס די סיסטעם דורך Redis-CLI. זינט Redis האט נישט אַ איין פּאָזיציע פונט, איר קענען דורכפירן די פאלגענדע אַפּעריישאַנז אויף קיין פון די נאָודז. אין יעדער פונט איך באַזונדער ופמערקזאַמקייט צו די מעגלעכקייט פון פּערפאָרמינג די אָפּעראַציע אונטער מאַסע.

• דער ערשטער און מערסט וויכטיק זאַך וואָס מיר דאַרפֿן איז די קנויל נאָודז אָפּעראַציע. עס קערט די שטאַט פון די קנויל, ווייַזן אַ רשימה פון נאָודז, זייער ראָלעס, שפּעלטל פאַרשפּרייטונג, עטק. מער אינפֿאָרמאַציע קענען זיין באקומען מיט קנויל אינפֿאָרמאַציע און קנויל סלאָץ.
• עס וואָלט זיין פייַן צו קענען צו לייגן און אַראָפּנעמען נאָודז. פֿאַר דעם צוועק עס זענען קנויל טרעפן און קנויל פאַרגעסן אַפּעריישאַנז. ביטע טאָן אַז קנויל פאַרגעסן מוזן זיין געווענדט צו יעדער נאָדע, ביידע הארן און רעפּלאַקאַז. און קנויל טרעפן נאָר דאַרף צו זיין גערופן אויף איין נאָדע. דער חילוק קען זיין דיסקאַווערד, אַזוי עס איז בעסטער צו לערנען וועגן אים איידער איר לעבן מיט דיין קנויל. אַדינג אַ נאָדע איז בעשאָלעם דורכגעקאָכט אין שלאַכט און טוט נישט ווירקן די אָפּעראַציע פון ​​די קנויל אין קיין וועג (וואָס איז לאַדזשיקאַל). אויב איר זענען געגאנגען צו באַזייַטיקן אַ נאָדע פון ​​דעם קנויל, איר זאָל מאַכן זיכער אַז עס זענען קיין סלאָץ לינקס אויף עס (אַנדערש איר ריזיקירן צו פאַרלירן אַקסעס צו אַלע די שליסלען אויף דעם נאָדע). אויך נישט אויסמעקן א בעל וואס האט עבדים, אנדערש וועט מען מאכן אן אומנייטיק שטימע פאר א נייעם בעל. אויב די נאָודז האָבן ניט מער סלאָץ, דאָס איז אַ קליין פּראָבלעם, אָבער וואָס טאָן מיר דאַרפֿן עקסטרע ברירות אויב מיר קענען ויסמעקן די סלאַוועס ערשטער.
• אויב איר דאַרפֿן צו פאָרספאַלי ויסבייַטן די בעל און שקלאַף שטעלעס, דער קנויל פיילאָווער באַפֿעל וועט זיין געטאן. ווען איר רופן עס אין שלאַכט, איר דאַרפֿן צו פֿאַרשטיין אַז דער בעל וועט נישט זיין בארעכטיגט בעשאַס די אָפּעראַציע. טיפּיקאַללי די באַשטימען אַקערז אין ווייניקער ווי אַ רגע, אָבער איז נישט אַטאָמישע. איר קענען דערוואַרטן אַז עטלעכע ריקוועס צו די בעל וועט פאַרלאָזן בעשאַס דעם צייט.
• איידער רימוווינג אַ נאָדע פון ​​דעם קנויל, עס זאָל זיין קיין סלאָץ לינקס אויף עס. עס איז בעסער צו רידיסטריביוט זיי מיט די קנויל רעשאַרד באַפֿעל. סלאָץ וועט זיין טראַנספערד פון איין בעל צו אנדערן. די גאנצע אָפּעראַציע קען נעמען עטלעכע מינוט, עס דעפּענדס אויף די באַנד פון דאַטן טראַנספערד, אָבער די אַריבערפירן פּראָצעס איז זיכער און טוט נישט ווירקן די אָפּעראַציע פון ​​די קנויל אין קיין וועג. אזוי, אַלע דאַטן קענען זיין טראַנספערד פון איין נאָדע צו אנדערן גלייַך אונטער מאַסע, און אָן זאָרג וועגן זייַן אַוויילאַבילאַטי. אָבער, עס זענען אויך סאַטאַלטיז. פירסטלי, דאַטן אַריבערפירן איז פארבונדן מיט אַ זיכער מאַסע אויף די באַקומער און סענדער נאָודז. אויב דער באַקומער נאָדע איז שוין שווער לאָודיד אויף די פּראַסעסער, איר זאָל נישט לאָדן עס מיט ריסיווינג נייַ דאַטן. צווייטנס, ווי באַלד ווי עס איז נישט אַ איין שפּעלטל אויף די שיקט בעל, אַלע פון ​​​​זייַן סלאַוועס וועט מיד גיין צו די בעל צו וואָס די סלאַץ זענען טראַנספערד. און די פּראָבלעם איז אַז אַלע די סלאַוועס וועלן וועלן צו סינגקראַנייז דאַטן אין אַמאָל. און איר וועט זיין מאַזלדיק אויב עס איז פּאַרטיייש אלא ווי גאַנץ סינגקראַנאַזיישאַן. נעמען דעם אין חשבון און פאַרבינדן די אַפּעריישאַנז פון טראַנספערינג סלאָץ און דיסייבאַל / טראַנספערינג סלאַוועס. אָדער האָפֿן אַז איר האָבן אַ גענוג גרענעץ פון זיכערקייַט.
• וואָס זאָל איר טאָן אויב, בעשאַס די אַריבערפירן, איר געפֿינען אַז איר האָט פאַרפאַלן דיין סלאָץ ערגעץ? איך האָפֿן אַז דאָס פּראָבלעם קען נישט ווירקן איר, אָבער אויב דאָס איז, עס איז אַ קנויל פאַרריכטן אָפּעראַציע. אין מינדסטער, זי וועט צעוואָרפן די סלאָץ אַריבער די נאָודז אין אַ טראַפ - סדר. איך רעקאָמענדירן צו קאָנטראָלירן זייַן אָפּעראַציע דורך ערשטער רימוווינג די נאָדע מיט פונאנדערגעטיילט סלאָץ פון דעם קנויל. זינט דאַטן אין אַנאַלאַקייטיד סלאָץ זענען שוין אַנאַוויילאַבאַל, עס איז צו שפּעט צו זאָרג וועגן פּראָבלעמס מיט די אַוויילאַבילאַטי פון די סלאָץ. אין קער, די אָפּעראַציע וועט נישט ווירקן פונאנדערגעטיילט סלאָץ.
• Еще одна полезная операция — monitor. Она позволяет в реальном времени видеть весь список запросов, идущих на ноду. Более того, по ней можно сделать grep и узнать, есть ли нужный трафик.

עס איז אויך ווערט דערמאָנען די מאַסטער פיילאָווער פּראָצעדור. אין קורץ, עס יגזיסץ, און, אין מיין מיינונג, עס אַרבעט גרויס. אָבער, טאָן ניט טראַכטן אַז אויב איר אָפּשטעקן די מאַכט שנור אויף אַ מאַשין מיט אַ בעל נאָדע, Redis וועט מיד באַשטימען און קלייאַנץ וועלן נישט באַמערקן די אָנווער. אין מיין פיר, די סוויטשינג אַקערז אין אַ ביסל סעקונדעס. אין דעם צייט, עטלעכע פון ​​​​די דאַטן וועט זיין אַנאַוויילאַבאַל: די אַנאַוויילאַביליטי פון די בעל איז דיטעקטאַד, נאָודז שטימען פֿאַר אַ נייַע, סלאַוועס זענען סוויטשט, דאַטן סינגקראַנייזד. דער בעסטער וועג צו מאַכן זיכער אַז די סכעמע אַרבעט איז צו אָנפירן היגע עקסערסייזיז. כאַפּן דעם קנויל אויף דיין לאַפּטאַפּ, געבן עס אַ מינימום מאַסע, סימולירן אַ קראַך (פֿאַר בייַשפּיל, דורך בלאַקינג די פּאָרץ), און אָפּשאַצן די סוויטשינג גיכקייַט. אין מיין מיינונג, נאָר נאָך פּלייינג אין דעם וועג פֿאַר אַ טאָג אָדער צוויי, איר קענען זיין זיכער אין די אָפּעראַציע פון ​​די טעכנאָלאָגיע. נו, אָדער האָפֿן אַז די ווייכווארג וואָס העלפט פון די אינטערנעט ניצט מיסטאָמע אַרבעט.

קאָנפיגוראַטיאָן

אָפט, די קאַנפיגיעריישאַן איז דער ערשטער זאַך איר דאַרפֿן צו אָנהייבן ארבעטן מיט די געצייַג. און ווען אַלץ אַרבעט, איר טאָן ניט אפילו ווילן צו פאַרבינדן די קאַנפיגיעריישאַן. עס נעמט עטלעכע מי צו צווינגען זיך צו גיין צוריק צו די סעטטינגס און דורכגיין זיי קערפאַלי. אין מיין זכּרון, מיר האָבן בייַ מינדסטער צוויי ערנסט פייליערז רעכט צו ינטענטיד צו די קאַנפיגיעריישאַן. באַצאָלן ספּעציעל אכטונג צו די פאלגענדע פונקטן:

• טיימינג קסנומקס
  Время, через которое закрываются неактивные соединения (в секундах). 0 — не закрываются
  ניש ט יעדע ר ביבליאטע ק אי ן אונזע ר הא ט געקענ ט פארמאכ ן פארבינדונגען . דורך דיסייבאַל דעם באַשטעטיקן, מיר ריזיקירן צו שלאָגן די שיעור פון די נומער פון קלייאַנץ. אויף די אנדערע האַנט, אויב עס איז אַזאַ אַ פּראָבלעם, אָטאַמאַטיק טערמאַניישאַן פון פאַרפאַלן קאַנעקשאַנז וועט מאַסקע עס, און מיר קען נישט באַמערקן. אין אַדישאַן, איר זאָל נישט געבן דעם באַשטעטיקן ווען איר נוצן אָנהאַלטן קאַנעקשאַנז.
• היט xy & אַפּפּענדאָנלי יאָ
  שפּאָרן אַ RDB מאָמענטבילד.
  Проблемы RDB/AOF мы подробно обсудим ниже.
• stop-writes-on-bgsave-error no & slave-serve-stale-data yes
  אויב ענייבאַלד, אויב די RDB מאָמענטבילד ברייקס, דער בעל וועט האַלטן אַקסעפּטינג ענדערונגען ריקוועס. אויב די קשר צו די בעל איז פאַרפאַלן, דער שקלאַף קענען פאָרזעצן צו ריספּאַנד צו ריקוועס (יאָ). אָדער וועט האַלטן ריספּאַנדינג (ניין)
  Нас не устраивает ситуация, при которой Redis превращается в тыкву.
• repl-ping-slave-period 5
  Через этот промежуток времени мы начнем беспокоиться о том, что мастер сломался и пора бы провести процедуру failover’a.
  Придется вручную находить баланс между ложными срабатываниями и запуском failover’а. На нашей практике это 5 секунд.
• repl-backlog-גרייס 1024מב & epl-backlog-ttl 0
  Ровно столько данных мы можем хранить в буфере для отвалившейся реплики. Если буфер кончится, то придется полностью синхронизироваться.
  פּראַקטיסיז סאַגדזשעסץ אַז עס איז בעסער צו שטעלן אַ העכער ווערט. עס זענען פילע סיבות וואָס אַ רעפּליקע קען אָנהייבן צו אָפּשטיי. אויב עס לאַגז, רובֿ מסתּמא דיין בעל איז שוין סטראַגאַלינג צו קאָפּע, און פול סינגקראַנאַזיישאַן וועט זיין די לעצטע שטרוי.
• maxclients 10000
  מאַקסימום נומער פון איין-צייַט קלייאַנץ.
  По нашему опыту, лучше поставить значение побольше. Redis прекрасно справляется с 10 тыс. соединений. Только убедитесь, что в системе достаточно сокетов.
• maxmemory-policy volatile-ttl
  Правило, по которому удаляются ключи при достижения лимита доступной памяти.
  Тут важно не само правило, а понимание, как это будет происходить. Redis можно похвалить за умение штатно работать при достижении лимита памяти.

RDB און AOF פּראָבלעמס

Хотя сам Redis хранит всю информацию в оперативной памяти, также есть механизм сохранения данных на диск. А точнее, три механизма:

• RDB-snapshot — полный слепок всех данных. Устанавливается с помощью конфигурации SAVE X Y и читается как «Сохранять полный снепшот всех данных каждые X секунд, если изменилось хотя бы Y ключей».
• Append-only file — список операций в порядке их выполнения. Добавляет новые пришедшие операции в файл каждые Х секунд или каждые Y операций.
• RDB and AOF — комбинация двух предыдущих.

У всех методов есть свои достоинства и недостатки, я не буду перечислять их все, лишь обращу внимания на не очевидные, на мой взгляд, моменты.

ערשטער, שפּאָרן אַ RDB מאָמענטבילד ריקווייערז פאַך FORK. אויב עס איז אַ פּלאַץ פון דאַטן, דאָס קען הענגען אַלע Redis פֿאַר אַ צייט פון עטלעכע מיליסעקאַנדז צו אַ רגע. אין אַדישאַן, די סיסטעם דאַרף אַלאַקייט זיקאָרן פֿאַר אַזאַ אַ מאָמענטבילד, וואָס פירט צו די נויטיק צו האַלטן אַ טאָפּל צושטעלן פון באַראַן אויף די לאַדזשיקאַל מאַשין: אויב 8 גיגאבייט זענען אַלאַקייטיד פֿאַר Redis, 16 גיגאבייט זאָל זיין בארעכטיגט אויף די ווירטואַל מאַשין מיט. עס.

צווייטנס, עס זענען פּראָבלעמס מיט פּאַרטיייש סינגקראַנאַזיישאַן. אין AOF מאָדע, ווען די שקלאַף איז ריקאַנעקטיד, אַנשטאָט פון פּאַרטיייש סינגקראַנאַזיישאַן, פול סינגקראַנאַזיישאַן קענען זיין דורכגעקאָכט. פארוואס דאָס כאַפּאַנז, איך קען נישט פֿאַרשטיין. אבער עס איז ווערט צו געדענקען דעם.

די צוויי ווייזט שוין מאַכן אונדז טראַכטן צי מיר טאַקע דאַרפֿן די דאַטן אויף די דיסק אויב אַלץ איז שוין דופּליקייטיד דורך סלאַוועס. דאַטן קענען זיין פאַרפאַלן בלויז אויב אַלע סלאַוועס דורכפאַל, און דאָס איז אַ "פייַער אין די דק" מדרגה פּראָבלעם. ווי אַ קאָמפּראָמיס, איר קענען פאָרשלאָגן צו ראַטעווען דאַטן בלויז אויף סלאַוועס, אָבער אין דעם פאַל איר דאַרפֿן צו מאַכן זיכער אַז די סלאַוועס וועט קיינמאָל ווערן אַ בעל בעשאַס ומגליק אָפּזוך (פֿאַר דעם עס איז אַ שקלאַף בילכערקייַט באַשטעטיקן אין זייער קאַנפיגיעריישאַן). פֿאַר זיך, אין יעדער ספּעציפיש פאַל, מיר טראַכטן צי עס איז נייטיק צו ראַטעווען דאַטן אויף די דיסק, און רובֿ אָפט די ענטפער איז "ניין".

סאָף

אין מסקנא, איך האָפֿן אַז איך איז געווען ביכולת צו געבן אַ גענעראַל געדאַנק פון ווי רעדיס-קנויל אַרבעט פֿאַר די וואס האָבן נישט געהערט פון עס בייַ אַלע, און אויך געצויגן ופמערקזאַמקייט צו עטלעכע ניט-קלאָרעוודיק פונקטן פֿאַר די וואס האָבן שוין ניצן עס פֿאַר אַ לאַנג צייַט.
Спасибо за уделенное время и, как обычно, комментарии по теме приветствуются.

מקור: www.habr.com