פארשטאנד פון אָנזאָג בראָקערס. לערנען די מאַקאַניקס פון מעסידזשינג מיט ActiveMQ און Kafka. קאַפּיטל 3. קאַפקאַ

פארזעצונג פון דער איבערזעצונג פון א קליין בוך:
פארשטאנד מעסעדזש בראָקערס
מחבר: Jakub Korab, אַרויסגעבער: O'Reilly Media, ינק., ויסגאַבע טאָג: יוני 2017, ISBN: 9781492049296.

פֿריִער איבערגעזעצטע טייל: פארשטאנד פון אָנזאָג בראָקערס. לערנען די מאַקאַניקס פון מעסידזשינג מיט ActiveMQ און Kafka. קאַפּיטל 1 הקדמה

קאפיטל 3

קאַפקאַ

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

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

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

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

יונאַפייד דעסטיניישאַן מאָדעל

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

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

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

די טערמינען "לאָג" און "טייַטל" טאָן ניט דערשייַנען אין קאַפקאַ דאַקיומענטיישאַן. די באקאנטע ווערטער ווערן דא גענוצט צו העלפן פארשטאנד.

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

פיגורע 3-1. קאַפקאַ פּאַרטישאַנז

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

לייענען אַרטיקלען

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

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

די פּראָבלעם פון לייענען קענען זיין רעפּריזענטיד ווי גייט:

• דער טעמע האט עטלעכע פּאַרטישאַנז
• קייפל גרופּעס פון קאָנסומערס קענען נוצן אַ טעמע אין דער זעלביקער צייט
• א גרופּע פון ​​קאָנסומערס קענען האָבן קייפל באַזונדער ינסטאַנסיז

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

קאָנסומערס און קאַנסומער גרופּעס

לאָמיר נעמען ווי אַ סטאַרטינג פונט אַ טעמע מיט איין צעטיילונג (פיגורע קסנומקס-קסנומקס).

פיגורע 3-2. קאָנסומער לייענט פון צעטיילונג

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

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

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

קאָנסומערס אין אַ קאָנסומער גרופּע

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

פיגורע 3-4. צוויי קאָנסומערס אין דער זעלביקער קאַנסומער גרופּע לייענען פון דער זעלביקער צעטיילונג

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

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

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

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

די קאַנאָניקאַל וועג צו סאָלווע דעם פּראָבלעם אין Kafka איז צו נוצן bОמער פּאַרטישאַנז.

צעטיילונג

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

פיגורע 3-5. איין קאָנסומער לייענט פון קייפל פּאַרטישאַנז

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

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

פיגורע 3-6. צוויי קאָנסומערס אין דער זעלביקער קאַנסומער גרופּע לייענען פון פאַרשידענע פּאַרטישאַנז

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

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

כל דער קאַפקאַ מעקלער האט צו טאָן איז צו פאָרן אַרטיקלען סאַקווענטשאַלי צו די קאַנסומער ווען דער יענער ריקוועס זיי.

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

שיקט אַרטיקלען

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

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

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

1. דער באַניצער חשבון איז קאַנפיגיערד.
2. געלט איז קרעדאַטאַד צו די חשבון.
3. א געוועט איז געמאכט וואָס וויטדרז געלט פון די חשבון.

אויב יעדער געשעעניש איז אַ אָנזאָג פּאָסטעד צו אַ טעמע, דער נאַטירלעך שליסל איז די חשבון שייַן.
ווען אַ אָנזאָג איז געשיקט מיט די Kafka Producer API, עס איז דורכגעגאנגען צו אַ צעטיילונג פונקציע וואָס, געגעבן די אָנזאָג און די קראַנט שטאַט פון די Kafka קנויל, קערט די ID פון די צעטיילונג צו וואָס די אָנזאָג זאָל זיין געשיקט. דעם שטריך איז ימפּלאַמענאַד אין Java דורך די Partitioner צובינד.

דער צובינד קוקט ווי דאָס:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

שרייבן דיין אייגענע פּאַרטישאַנינג סטראַטעגיע

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

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

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

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

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

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

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

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

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

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

פּראָדוצירער אַגרימאַנץ

פּאַרטיטיאָן איז נישט די בלויז זאַך צו באַטראַכטן ווען שיקט אַרטיקלען. לאָמיר נעמען אַ קוק אין די שיקן () מעטהאָדס פון די פּראָדוצירער קלאַס אין די Java API:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

מער וועגן לייענען אַרטיקלען

לייענען אַרטיקלען האט נאָך קאַמפּלעקסיטיז וואָס דאַרפֿן צו זיין ספּעקיאַלייטיד וועגן. ניט ענלעך די JMS API, וואָס קענען לויפן אַ אָנזאָג ליסנער אין ענטפער צו אַ אָנזאָג, די קאָנסומער קאַפקאַ בלויז פּאָללס. זאל ס נעמען אַ נעענטער קוק אין דעם אופֿן אַנקעטע ()געניצט פֿאַר דעם צוועק:

ConsumerRecords < K, V > poll(long timeout);

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

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

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

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

1. באַקומען אַ אָנזאָג פֿאַר לייענען.
2. פּראָצעס דעם אָנזאָג.
3. באַשטעטיקן אָנזאָג.

די קאַפקאַ קאַנסומער קומט מיט אַ קאַנפיגיעריישאַן אָפּציע enable.auto.commit. דאָס איז אַ אָפט געניצט פעליקייַט באַשטעטיקן, ווי געוויינטלעך מיט סעטטינגס מיט די וואָרט "אַוטאָ".

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

אין Kafka 0.10, דער קליענט קאָד איז טשיינדזשד אַזוי אַז די קאַמיט איז טריגערד פּיריאַדיקלי דורך די קליענט ביבליאָטעק, ווי קאַנפיגיערד auto.commit.interval.ms. דער אָפּפירונג איז ערגעץ צווישן די JMS AUTO_ACKNOWLEDGE און DUPS_OK_ACKNOWLEDGE מאָדעס. ווען ניצן אַוטאָקאָמיט, אַרטיקלען קען זיין באגאנגען ראַגאַרדלאַס פון צי זיי זענען פאקטיש פּראַסעסט - דאָס קען פּאַסירן אין דעם פאַל פון אַ פּאַמעלעך קאַנסומער. אויב אַ קאַנסומער אַבאָרטיד, אַרטיקלען וואָלט זיין געבראכט דורך דער ווייַטער קאַנסומער, סטאַרטינג אין די באגאנגען שטעלע, וואָס קען רעזולטאַט אין אַ מיסט אָנזאָג. אין דעם פאַל, קאַפקאַ האט נישט פאַרלירן די אַרטיקלען, די לייענען קאָד האט זיי נאָר נישט פּראַסעסט.

דער מאָדע האט די זעלבע צוזאָג ווי אין ווערסיע 0.9: אַרטיקלען קענען זיין פּראַסעסט, אָבער אויב עס פיילז, די פאָטאָ קען נישט זיין באגאנגען, וואָס קען זיין דאַבאַלד עקספּרעס. די מער אַרטיקלען איר באַקומען ווען עקסאַקיוטינג אַנקעטע (), די מער דעם פּראָבלעם.

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

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

איר קענען קאָנטראָלירן די מאַנואַל אָפסעט יבערגעבן פּראָצעס אין די Kafka קאַנסומער אַפּי דורך באַשטעטיקן דעם פּאַראַמעטער enable.auto.commit צו פאַלש און בפירוש רופן איינער פון די פאלגענדע מעטהאָדס:

void commitSync();
void commitAsync();

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

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

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

אויב מיר קענען נישט פאַרלאָזנ אויף טראַנזאַקשאַנז, ווי קענען מיר צושטעלן סעמאַנטיקס נעענטער צו די צוגעשטעלט דורך טראדיציאנעלן מעסידזשינג סיסטעמען?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

אופֿן זוכן () קענען זיין געוויינט מיט דער אופֿן
offsetsForTimes(מאַפּע TimestampsToSearch) צו ריוויינד צו אַ שטאַט אין עטלעכע ספּעציפיש פונט אין דער פאַרגאַנגענהייט.

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

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

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

הויך אַוויילאַביליטי

Kafka ס צוגאַנג צו הויך אַוויילאַבילאַטי איז זייער אַנדערש פון ActiveMQ ס צוגאַנג. Kafka איז דיזיינד אַרום וואָג-אויס קלאַסטערז ווו אַלע מעקלער ינסטאַנסיז באַקומען און פאַרשפּרייטן אַרטיקלען אין דער זעלביקער צייט.

א קאַפקאַ קנויל באשטייט פון קייפל מעקלער ינסטאַנסיז פליסנדיק אויף פאַרשידענע סערווערס. Kafka איז דיזיינד צו לויפן אויף פּראָסט סטאַנדאַלאָנע ייַזנוואַרג, ווו יעדער נאָדע האט זיין אייגענע דעדאַקייטאַד סטאָרידזש. די נוצן פון נעץ אַטאַטשט סטאָרידזש (SAN) איז נישט רעקאַמענדיד ווייַל קייפל קאַמפּיוט נאָודז קענען קאָנקורירן פֿאַר צייט.ЫE סטאָרידזש ינטערוואַלז און שאַפֿן קאָנפליקט.

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

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

אין די באַזע פאַל, אַ טעמע איז באשאפן אין אַ קאַפקאַ קנויל מיט די פאלגענדע פּראָפּערטיעס:

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

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

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

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

טייל פון די פּראָדוצירער קאַנפיגיעריישאַן איז דער פּאַראַמעטער אַקס, וואָס באַשטימט ווי פילע רעפּלאַקאַז מוזן באַשטעטיקן (באַשטעטיקן) קאַבאָלע פון ​​אַ אָנזאָג איידער די אַפּלאַקיישאַן פאָדעם האלט צו שיקן: 0, 1 אָדער אַלע. אויב שטעלן צו אַלע, און ווען אַ אָנזאָג איז באקומען, דער פירער וועט שיקן אַ באַשטעטיקונג צוריק צו דער פּראָדוצירער ווי באַלד ווי ער באקומט באַשטעטיקונג (דערקענטענישן) פון די רעקאָרד פון עטלעכע קיוז (אַרייַנגערעכנט זיך) דיפיינד דורך די טעמע באַשטעטיקן min.insync.replicas (פעליקייַט 1). אויב דער אָנזאָג קענען ניט זיין הצלחה רעפּליקייטיד, דער פּראָדוצירער וועט וואַרפן אַ אַפּלאַקיישאַן ויסנעם (ניט גענוג רעפּלאַקאַז אָדער ניט גענוג רעפּלאַקאַז נאָך אַפּענד).

א טיפּיש קאַנפיגיעריישאַן קריייץ אַ טעמע מיט אַ רעפּלאַקיישאַן פאַקטאָר פון 3 (1 פירער, 2 אנהענגערס פּער צעטיילונג) און די פּאַראַמעטער min.insync.replicas איז באַשטימט צו 2. אין דעם פאַל, דער קנויל וועט לאָזן איינער פון די בראָקערס אָנפירונג די טעמע צעטיילונג צו גיין אַראָפּ אָן אַפעקטינג קליענט אַפּלאַקיישאַנז.

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

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

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

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

רעזולטאַטן פון

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

פֿריִער איבערגעזעצטע טייל: פארשטאנד פון אָנזאָג בראָקערס. לערנען די מאַקאַניקס פון מעסידזשינג מיט ActiveMQ און Kafka. קאַפּיטל 1

איבערזעצונג געטאן: tele.gg/middle_java

צו פאָרזעצן ...

בלויז רעגיסטרירט ניצערס קענען אָנטייל נעמען אין די יבערבליק. סיין ארייןביטע.

איז קאַפקאַ געניצט אין דיין אָרגאַניזאַציע?

• יאָ

• קיין

• פריער געוויינט, איצט נישט

• מיר פּלאַן צו נוצן

38 באנוצער האבן געשטימט. 8 באנוצער האבן זיך אפגעהאלטן.

מקור: www.habr.com