בעיות של עיבוד שאילתות אצווה והפתרונות שלהן (חלק 1)

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

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

פרויקט הדגמה

למען הבהירות, בואו נסתכל על דוגמה של אחד מהשירותים באפליקציה שעליה אני עובד כעת.

הסבר על בחירת פלטפורמה לדוגמאותהבעיה של ביצועים גרועים היא די כללית ואינה נוגעת לשום שפות או פלטפורמות ספציפיות. מאמר זה ישתמש בדוגמאות קוד של Spring + Kotlin כדי להדגים בעיות ופתרונות. קוטלין מובן (או לא מובן) באותה מידה למפתחי Java ו-C#; בנוסף, הקוד קומפקטי ומובן יותר מאשר ב-Java. כדי להקל על ההבנה עבור מפתחי ג'אווה טהורים, אמנע מהקסם השחור של קוטלין ואשתמש רק בקסם הלבן (ברוח לומבוק). יהיו כמה שיטות הרחבה, אבל הן למעשה מוכרות לכל מתכנתי ג'אווה כשיטות סטטיות, כך שזה יהיה סוכר קטן שלא יהרוס את הטעם של המנה.
יש שירות אישור מסמכים. מישהו יוצר מסמך ומגיש אותו לדיון, במהלכו מתבצעות עריכות, ובסופו של דבר המסמך מוסכם. שירות האישורים עצמו לא יודע דבר על מסמכים: זה רק צ'אט של מאשרים עם פונקציות קטנות נוספות שלא נשקול כאן.

לכן, ישנם חדרי צ'אט (המתאימים למסמכים) עם קבוצה מוגדרת מראש של משתתפים בכל אחד מהם. כמו בצ'אטים רגילים, הודעות מכילות טקסט וקבצים ויכולות להיות תשובות או העברות:

data class ChatMessage(
  // nullable так как появляется только после persist
  val id: Long? = null,
  /** Ссылка на автора */
  val author: UserReference,
  /** Сообщение */
  val message: String,
  /** Ссылки на аттачи */
  // из-за особенностей связки JPA+СУБД проще поддерживать и null, и пустые списки
  val files: List<FileReference>? = null,
  /** Если является ответом, то здесь будет оригинал */
  val replyTo: ChatMessage? = null,
  /** Если является пересылкой, то здесь будет оригинал */
  val forwardFrom: ChatMessage? = null
)

קישורי קבצים ומשתמשים הם קישורים לדומיינים אחרים. כאן אנחנו חיים ככה:

typealias FileReference = Long
typealias UserReference = Long

נתוני המשתמש מאוחסנים ב-Keycloak ומתקבלים באמצעות REST. כך גם לגבי קבצים: קבצים ומטא-אינפורמציה עליהם נמצאים בשירות אחסון קבצים נפרד.

כל השיחות לשירותים אלו הם בקשות כבדות. המשמעות היא שהתקורה של העברת בקשות אלו גדולה בהרבה מהזמן שלוקח לעיבודן על ידי שירות צד שלישי. על ספסלי הבדיקה שלנו, זמן ההתקשרות האופייני לשירותים כאלה הוא 100 אלפיות השנייה, אז נשתמש במספרים אלה בהמשך.

אנחנו צריכים ליצור בקר REST פשוט כדי לקבל את N ההודעות האחרונות עם כל המידע הדרוש. כלומר, אנו מאמינים שב-frontend מודל ההודעות כמעט זהה ויש לשלוח את כל הנתונים. ההבדל בין המודל החזיתי הוא שצריך להציג את הקובץ והמשתמש בצורה מעט מפוענחת על מנת להפוך אותם לקישורים:

/** В таком виде отдаются ссылки на сущности для фронта */
data class ReferenceUI(
  /** Идентификатор для url */
  val ref: String,
  /** Видимое пользователю название ссылки */
  val name: String
)
data class ChatMessageUI(
  val id: Long,
  /** Ссылка на автора */
  val author: ReferenceUI,
  /** Сообщение */
  val message: String,
  /** Ссылки на аттачи */
  val files: List<ReferenceUI>,
  /** Если являтся ответом, то здесь будет оригинал */
  val replyTo: ChatMessageUI? = null,
  /** Если являтся пересылкой, то здесь будет оригинал */
  val forwardFrom: ChatMessageUI? = null
)

אנחנו צריכים ליישם את הדברים הבאים:

interface ChatRestApi {
  fun getLast(n: Int): List<ChatMessageUI>
}

ממשק המשתמש של Postfix פירושו דגמי DTO עבור ה-frontend, כלומר, מה שעלינו לשרת באמצעות REST.

מה שעשוי להפתיע כאן הוא שאנחנו לא מעבירים שום מזהה צ'אט ואפילו במודל ChatMessage/ChatMessageUI אין כזה. עשיתי זאת בכוונה כדי לא לבלבל את הקוד של הדוגמאות (הצ'אטים מבודדים, אז אפשר להניח שיש לנו רק אחד).

סטייה פילוסופיתגם המחלקה ChatMessageUI וגם השיטה ChatRestApi.getLast משתמשות בסוג הנתונים List, כאשר למעשה מדובר בסט מסודר. ב-JDK כל זה רע, כך שהכרזה על סדר האלמנטים ברמת הממשק (שימור הסדר בעת ההוספה והשליפה) לא תעבוד. אז זה הפך לנוהג נפוץ להשתמש ב- List במקרים שבהם יש צורך ב-Set מסודר (יש גם LinkedHashSet, אבל זה לא ממשק).
הגבלה חשובה: אנו נניח שאין שרשרות ארוכות של תשובות או העברות. כלומר, הם קיימים, אבל אורכם אינו עולה על שלוש הודעות. יש להעביר את כל שרשרת ההודעות ל-frontend.

כדי לקבל נתונים משירותים חיצוניים יש את ממשקי ה-API הבאים:

interface ChatMessageRepository {
  fun findLast(n: Int): List<ChatMessage>
}
data class FileHeadRemote(
  val id: FileReference,
  val name: String
)
interface FileRemoteApi {
  fun getHeadById(id: FileReference): FileHeadRemote
  fun getHeadsByIds(id: Set<FileReference>): Set<FileHeadRemote>
  fun getHeadsByIds(id: List<FileReference>): List<FileHeadRemote>
  fun getHeadsByChat(): List<FileHeadRemote>
}
data class UserRemote(
  val id: UserReference,
  val name: String
)
interface UserRemoteApi {
  fun getUserById(id: UserReference): UserRemote
  fun getUsersByIds(id: Set<UserReference>): Set<UserRemote>
  fun getUsersByIds(id: List<UserReference>): List<UserRemote>
}

ניתן לראות ששירותים חיצוניים מספקים בתחילה עיבוד אצווה, ובשתי הגרסאות: דרך Set (ללא שימור סדר האלמנטים, עם מפתחות ייחודיים) ודרך List (ייתכנו כפילויות - הסדר נשמר).

יישומים פשוטים

יישום נאיבי

היישום הנאיבי הראשון של בקר ה-REST שלנו ייראה בערך כך ברוב המקרים:

class ChatRestController(
  private val messageRepository: ChatMessageRepository,
  private val userRepository: UserRemoteApi,
  private val fileRepository: FileRemoteApi
) : ChatRestApi {
  override fun getLast(n: Int) =
    messageRepository.findLast(n)
      .map { it.toFrontModel() }
  
  private fun ChatMessage.toFrontModel(): ChatMessageUI =
    ChatMessageUI(
      id = id ?: throw IllegalStateException("$this must be persisted"),
      author = userRepository.getUserById(author).toFrontReference(),
      message = message,
      files = files?.let { files ->
        fileRepository.getHeadsByIds(files)
          .map { it.toFrontReference() }
      } ?: listOf(),
      forwardFrom = forwardFrom?.toFrontModel(),
      replyTo = replyTo?.toFrontModel()
    )
}

הכל מאוד ברור, וזה יתרון גדול.

אנו משתמשים בעיבוד אצווה ומקבלים נתונים משירות חיצוני באצוות. אבל מה קורה לפרודוקטיביות שלנו?

עבור כל הודעה, תתבצע קריאה אחת ל-UserRemoteApi כדי לקבל נתונים על שדה המחבר וקריאה אחת ל-FileRemoteApi כדי לקבל את כל הקבצים המצורפים. נראה שזהו זה. נניח שהשדות forwardFrom ו- replyTo עבור ChatMessage מתקבלים בצורה כזו שזה לא מצריך שיחות מיותרות. אבל הפיכתם ל-ChatMessageUI תוביל לרקורסיה, כלומר, מוני השיחות יכולים להגדיל באופן משמעותי. כפי שציינו קודם לכן, נניח שאין לנו הרבה קינון והשרשרת מוגבלת לשלוש הודעות.

כתוצאה מכך נקבל בין שתיים לשש שיחות לשירותים חיצוניים לכל הודעה ושיחת JPA אחת לכל חבילת ההודעות. המספר הכולל של השיחות ישתנה בין 2*N+1 ל-6*N+1. כמה זה ביחידות אמיתיות? נניח שלוקח 20 הודעות לעיבוד דף. כדי להשיג אותם, תצטרך מ 4 שניות עד 10 שניות. נורא! אני רוצה לשמור אותו בטווח של 500 אלפיות השנייה. ומכיוון שהם חלמו לעשות גלילה חלקה בחזית, ניתן להכפיל את דרישות הביצועים עבור נקודת קצה זו.

יתרונות:

1. הקוד מתומצת ומתעד בעצמו (חלום של צוות תמיכה).
2. הקוד פשוט, כך שאין כמעט הזדמנויות לירות לעצמך ברגל.
3. עיבוד אצווה לא נראה כמו משהו זר והוא משולב באופן אורגני בלוגיקה.
4. שינויים לוגיים יהיו קלים לביצוע ויהיו מקומיים.

מינוס:

ביצועים איומים בגלל חבילות קטנות מאוד.

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

עיבוד מקביל נאיבי

אתה יכול להתחיל לעבד את כל ההודעות במקביל - זה יאפשר לך להיפטר מהעלייה הליניארית בזמן בהתאם למספר ההודעות. זה לא נתיב טוב במיוחד כי זה יגרום לעומס שיא גדול על השירות החיצוני.

יישום עיבוד מקביל הוא פשוט מאוד:

override fun getLast(n: Int) =
  messageRepository.findLast(n).parallelStream()
    .map { it.toFrontModel() }
    .collect(toList())

באמצעות עיבוד הודעות מקביל, אנו מקבלים 300–700 אלפיות השנייה באופן אידיאלי, וזה הרבה יותר טוב מאשר ביישום נאיבי, אבל עדיין לא מספיק מהיר.

עם גישה זו, בקשות ל-userRepository ול-fileRepository יבוצעו באופן סינכרוני, וזה לא מאוד יעיל. כדי לתקן זאת, תצטרך לשנות את היגיון השיחה די הרבה. לדוגמה, דרך CompletionStage (המכונה CompletableFuture):

private fun ChatMessage.toFrontModel(): ChatMessageUI =
  CompletableFuture.supplyAsync {
    userRepository.getUserById(author).toFrontReference()
  }.thenCombine(
    files?.let {
      CompletableFuture.supplyAsync {
        fileRepository.getHeadsByIds(files).map { it.toFrontReference() }
      }
    } ?: CompletableFuture.completedFuture(listOf())
  ) { author, files ->
    ChatMessageUI(
      id = id ?: throw IllegalStateException("$this must be persisted"),
      author = author,
      message = message,
      files = files,
      forwardFrom = forwardFrom?.toFrontModel(),
      replyTo = replyTo?.toFrontModel()
    )
  }.get()!!

ניתן לראות שקוד המיפוי הפשוט בהתחלה הפך פחות מובן. הסיבה לכך היא שהיינו צריכים להפריד בין שיחות לשירותים חיצוניים מהמקום שבו נעשה שימוש בתוצאות. זה כשלעצמו לא רע. אבל שילוב שיחות לא נראה אלגנטי במיוחד ודומה ל"אטריות" תגובתי טיפוסי.

אם אתה משתמש בקורוטינות, הכל ייראה הגון יותר:

private fun ChatMessage.toFrontModel(): ChatMessageUI =
  join(
    { userRepository.getUserById(author).toFrontReference() },
    { files?.let { fileRepository.getHeadsByIds(files)
      .map { it.toFrontReference() } } ?: listOf() }
  ).let { (author, files) ->
    ChatMessageUI(
      id = id ?: throw IllegalStateException("$this must be persisted"),
      author = author,
      message = message,
      files = files,
      forwardFrom = forwardFrom?.toFrontModel(),
      replyTo = replyTo?.toFrontModel()
    )
  }

איפה:

fun <A, B> join(a: () -> A, b: () -> B) =
  runBlocking(IO) {
    awaitAll(async { a() }, async { b() })
  }.let {
    it[0] as A to it[1] as B
  }

תיאורטית, באמצעות עיבוד מקביל כזה, נקבל 200–400 אלפיות השנייה, שזה כבר קרוב לציפיות שלנו.

למרבה הצער, הקבלה כה טובה לא מתרחשת, והמחיר לתשלום הוא די אכזרי: כשרק משתמשים בודדים יעבדו בו זמנית, השירותים ייפגעו בשטף של בקשות שלא יטופלו במקביל, כך שאנו יחזור ל-4 העצובים שלנו.

התוצאה שלי בשימוש בשירות כזה היא 1300–1700 אלפיות השנייה לעיבוד 20 הודעות. זה מהיר יותר מאשר ביישום הראשון, אבל עדיין לא פותר את הבעיה.

שימושים חלופיים בשאילתות מקבילותמה אם שירותי צד שלישי אינם מספקים עיבוד אצווה? לדוגמה, אתה יכול להסתיר את היעדר הטמעת עיבוד אצווה בתוך שיטות ממשק:

interface UserRemoteApi {
  fun getUserById(id: UserReference): UserRemote
  fun getUsersByIds(id: Set<UserReference>): Set<UserRemote> =
    id.parallelStream()
      .map { getUserById(it) }.collect(toSet())
  fun getUsersByIds(id: List<UserReference>): List<UserRemote> =
    id.parallelStream()
      .map { getUserById(it) }.collect(toList())
}

זה הגיוני אם אתה מקווה לראות עיבוד אצווה בגרסאות עתידיות.
יתרונות:

1. הטמע בקלות עיבוד מקביל מבוסס הודעות.
2. מדרגיות טובה.

חסרונות:

1. הצורך להפריד בין רכישת הנתונים לעיבודם בעת עיבוד בקשות לשירותים שונים במקביל.
2. עומס מוגבר על שירותי צד שלישי.

ניתן לראות כי היקף התחולה זהה בקירוב לזה של הגישה הנאיבית. הגיוני להשתמש בשיטת הבקשה המקבילה אם אתה רוצה להגביר את ביצועי השירות שלך מספר פעמים בגלל ניצול חסר רחמים של אחרים. בדוגמה שלנו, הפרודוקטיביות גדלה פי 2,5, אך ברור שזה לא מספיק.

שמירה במטמון

אתה יכול לעשות מטמון ברוח JPA עבור שירותים חיצוניים, כלומר לאחסן אובייקטים שהתקבלו בתוך הפעלה כדי לא לקבל אותם שוב (כולל במהלך עיבוד אצווה). אתה יכול ליצור מטמונים כאלה בעצמך, אתה יכול להשתמש ב-Spring עם @Cacheable שלו, בנוסף אתה תמיד יכול להשתמש במטמון מוכן כמו EhCache באופן ידני.

בעיה נפוצה תהיה שמטמונים שימושיים רק אם יש להם היטים. במקרה שלנו, סבירות גבוהה להיטים בשדה המחבר (נניח, 50%), אבל לא יהיו כניסות לקבצים בכלל. גישה זו תספק כמה שיפורים, אבל היא לא תשנה באופן קיצוני את הפרודוקטיביות (ואנחנו צריכים פריצת דרך).

מטמונים של intersession (ארוכים) דורשים לוגיקה מורכבת של אי תוקף. באופן כללי, ככל שתגיע מאוחר יותר לפתרון בעיות ביצועים באמצעות מטמונים של intersession, כך ייטב.

יתרונות:

1. יישם מטמון ללא שינוי קוד.
2. פרודוקטיביות מוגברת מספר פעמים (במקרים מסוימים).

חסרונות:

1. אפשרות לביצועים מופחתים בשימוש לא נכון.
2. זיכרון גדול מעל הראש, במיוחד עם מטמונים ארוכים.
3. אי תוקף מורכב, שגיאות בהן יובילו לבעיות שקשה לשחזר בזמן ריצה.

לעתים קרובות מאוד, מטמונים משמשים רק כדי לתקן במהירות בעיות עיצוב. זה לא אומר שאסור להשתמש בהם. עם זאת, תמיד כדאי להתייחס אליהם בזהירות ולהעריך תחילה את רווח הביצועים שנוצר, ורק לאחר מכן לקבל החלטה.

בדוגמה שלנו, מטמונים יספקו עליית ביצועים של כ-25%. יחד עם זאת, למטמונים יש די הרבה חסרונות, אז לא הייתי משתמש בהם כאן.

תוצאות של

אז, בדקנו יישום נאיבי של שירות המשתמש בעיבוד אצווה, וכמה דרכים פשוטות להאיץ אותו.

היתרון העיקרי של כל השיטות הללו הוא הפשטות, שממנה יש השלכות נעימות רבות.

בעיה נפוצה בשיטות אלו היא ביצועים גרועים, הקשורים בעיקר לגודל החבילות. לכן, אם הפתרונות האלה לא מתאימים לך, אז כדאי לשקול שיטות רדיקליות יותר.

ישנם שני כיוונים עיקריים שבהם ניתן לחפש פתרונות:

• עבודה אסינכרונית עם נתונים (דורשת שינוי פרדיגמה, ולכן לא נדון במאמר זה);
• הגדלה של אצוות תוך שמירה על עיבוד סינכרוני.

הגדלה של אצוות תפחית מאוד את מספר השיחות החיצוניות ובמקביל תשאיר את הקוד סינכרוני. החלק הבא של המאמר יוקדש לנושא זה.

מקור: www.habr.com