הטכניון - מכון טכנולוגי לישראל Technion - Israel Institute of Technology Технион - израильский технологический институт ألتخنيون - معهد تكنولوجي لإسرائيل

02360351 - Distributed Systems 02360351 - Distributed Systems 02360351 - Distributed Systems 02360351 - Distributed Systems

חורף 2021-2022Winter 2021-2022Зима 2021-2022شتاء 2021-2022

שאלות ותשובות Frequently Asked Questions Вопросы и Ответы أسئلة وأجوبة

Why should I study this course?

Because this is the golden age for distributed systems.
Almost everything we do involves distributed systems (everything that is Internet based, e.g., Google, e-mail, WhatsApp, TikTok, Telegram, Instagram, Facebook, Dropbox, Amazon, Twitter, Netflix, your bank, cryptocurrencies and blockchains, etc.).
In this course, we will study the mechanisms behind the scenes of these systems, and you will learn how to design such systems yourself.

project

What IDE is recommended?

The template has been tested on IntelliJ IDEA.

האם מצב בו כל השרתים שומרים את כל העסקאות שהתבצעו עד כה כולל כאלה שלא על השארד שלהם, הוא מצב קביל?

שימו לב שאסור לשמור את כל העסקאות בכל הshards. זה בדיוק כל הרעיון, כל שארד אחראי על כל ההכנסות של החשבונות שבאחריותו. שהארדים צריכים לעבוד בצורה בלתי תלויה בשארדים האחרים, למעט המקרים בהם מתקבלת פקודה שמצריכה סנכרון ביניהם. למשל בatomic transaction list או כשיש להעביר את ההיסטוריה הגלובלית של כל המערכת.
מכיוון שהעברת ההיסטוריה היא פעולה כבדה ולא מהותית, שנועדה לצורך בדיקת המערכת מבחינתנו כצופים חיצוניים ולא עבור לקוחות, אפשר לעשות אותה בצורה מאוד לא יעילה. לדוגמה תוכלו לעצור את פעולת המערכת הכללית (double barrier) לחכות שכל השארדים יסיימו להעביר את כל המידע שיש להם, ואז להחזיר את המערכת לפעולתה הסטנדרטית. בסוף לפני המעבר ללקוח אפשר לסדר את הטרנזקציות לפי סדר כרונולוגי דטרמיניסטי.
זה כמובן מאוד לא יעיל, אך זו אינה פעולה שמיועדת ללקוחות באופן כללי, אלא רק עבורנו כצופים חיצוניים. הייתי ממליץ להשתמש בzookeeper כשאפשר. אל תנסו לממש קונצנזוס בעצמכם, למעט המקרה בו אתם צריכים לממש atomic broadcast (ואז תשתמשו בקוד שסיפקנו לכם).

במה שונה atomic transaction listמ-transaction בודד אשר מכיל את כל הinput והoutput המשולב מכל הטרנזקציות. (כלומר טרנזקציה שמאחדת את כל הטרנזקציות ברשימה)

שימו לב שטרנזקציה רגילה חייבת לקבל inputs משולח יחיד, כלומר לא ניתן לבצע את האיחוד שאתה מציע לפי הסמנטיקה של טרנזקציות שהוגדרה בתרגיל. שימו לב שמכיוון שלטרנזקציה שולח יחיד, אפשר לנהל את הטרנזקציה באופן בלעדי בshard של השולח. מצד שני בatomic transaction list יכולים להיות מספר שולחים, גם מshards שונים, ולכן יש צורך במנגנון סנכרון כלשהו בין הshards הרלוונטיים. זה כמובן לא נדרש בטרנזקציה סטנדרטית.

ניסינו להריץ את שרת הREST ונתקלנו בשגיאה בסגנון הבא:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/user/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-log4j12/1.7.30/c21f55139d8141d2231214fb1feaf50a1edca95e/slf4j-log4j12-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/user/.gradle/caches/modules-2/files-2.1/ch.qos.logback/logback-classic/1.2.3/7c4f3c474fb2c041d8028740440937705ebb473a/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
מה עושים?

הוסיפו לסוף הקובץ server\build.gradle.kt את ההוראות הבאות:

configurations.all {
exclude("org.slf4j","slf4j-log4j12")
}
זה אמור לפתור את הקונפליקט שהוא מתלונן עליו.