ब्याच क्वेरी प्रशोधनका समस्याहरू र तिनका समाधानहरू (भाग १)

लगभग सबै आधुनिक सफ्टवेयर उत्पादनहरूमा धेरै सेवाहरू हुन्छन्। अक्सर, इन्टरसर्भिस च्यानलहरूको लामो प्रतिक्रिया समय प्रदर्शन समस्याहरूको स्रोत बन्छ। यस प्रकारको समस्याको मानक समाधान भनेको धेरै अन्तरसेवा अनुरोधहरूलाई एउटा प्याकेजमा प्याक गर्नु हो, जसलाई ब्याचिङ भनिन्छ।

यदि तपाइँ ब्याच प्रशोधन प्रयोग गर्नुहुन्छ भने, तपाइँ प्रदर्शन वा कोड स्पष्टताको सर्तमा नतिजाहरूसँग खुसी नहुन सक्नुहुन्छ। यो विधि कलरमा तपाईले सोचे जस्तो सजिलो छैन। विभिन्न उद्देश्यका लागि र विभिन्न परिस्थितिहरूमा, समाधानहरू धेरै भिन्न हुन सक्छन्। विशिष्ट उदाहरणहरू प्रयोग गरेर, म धेरै दृष्टिकोणहरूको फाइदा र विपक्ष देखाउनेछु।

प्रदर्शन परियोजना

स्पष्टताको लागि, म हाल काम गरिरहेको अनुप्रयोगमा सेवाहरू मध्ये एउटाको उदाहरण हेरौं।

उदाहरणका लागि प्लेटफर्म चयनको व्याख्याखराब प्रदर्शनको समस्या एकदम सामान्य छ र कुनै विशेष भाषा वा प्लेटफर्महरूलाई असर गर्दैन। यस लेखले समस्या र समाधानहरू प्रदर्शन गर्न वसन्त + कोटलिन कोड उदाहरणहरू प्रयोग गर्नेछ। Kotlin जाभा र C# विकासकर्ताहरूको लागि समान रूपमा बुझ्न योग्य (वा बुझ्न नसकिने) छ, थप रूपमा, कोड जाभा भन्दा बढी कम्प्याक्ट र बुझ्न योग्य छ। शुद्ध जाभा विकासकर्ताहरूका लागि बुझ्न सजिलो बनाउनको लागि, म कोटलिनको कालो जादूलाई बेवास्ता गर्नेछु र केवल सेतो जादू (लोम्बोकको भावनामा) प्रयोग गर्नेछु। त्यहाँ केहि विस्तार विधिहरू हुनेछन्, तर तिनीहरू वास्तवमा सबै जाभा प्रोग्रामरहरूलाई स्थिर विधिहरूको रूपमा परिचित छन्, त्यसैले यो सानो चिनी हुनेछ जसले डिशको स्वाद बिगार्दैन।
त्यहाँ कागजात अनुमोदन सेवा छ। कसैले कागजात सिर्जना गर्छ र यसलाई छलफलको लागि पेश गर्दछ, जसमा सम्पादनहरू गरिन्छन्, र अन्ततः कागजातमा सहमति हुन्छ। स्वीकृति सेवा आफैंले कागजातहरूको बारेमा केहि थाहा छैन: यो केवल साना अतिरिक्त प्रकार्यहरूको साथ अनुमोदनकर्ताहरूको च्याट हो जुन हामी यहाँ विचार गर्दैनौं।

त्यसोभए, त्यहाँ प्रत्येकमा सहभागीहरूको पूर्वनिर्धारित सेटको साथ च्याट कोठाहरू (कागजातहरूसँग सम्बन्धित) छन्। नियमित च्याटहरूमा जस्तै, सन्देशहरूमा पाठ र फाइलहरू छन् र जवाफ वा फर्वार्ड गर्न सकिन्छ:

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 ms हो, त्यसैले हामी भविष्यमा यी नम्बरहरू प्रयोग गर्नेछौं।

हामीले सबै आवश्यक जानकारीको साथ अन्तिम N सन्देशहरू प्राप्त गर्न एक साधारण REST नियन्त्रक बनाउन आवश्यक छ। त्यो हो, हामी विश्वास गर्छौं कि फ्रन्टएन्डमा सन्देश मोडेल लगभग समान छ र सबै डेटा पठाउन आवश्यक छ। फ्रन्ट-एन्ड मोडेल बीचको भिन्नता भनेको फाइल र प्रयोगकर्तालाई लिङ्कहरू बनाउनको लागि थोरै डिक्रिप्टेड फारममा प्रस्तुत गर्न आवश्यक छ:

/** В таком виде отдаются ссылки на сущности для фронта */
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>
}

UI पोस्टफिक्स भनेको फ्रन्टएन्डका लागि DTO मोडेलहरू हो, त्यो हो, हामीले REST मार्फत के सेवा गर्नुपर्छ।

यहाँ अचम्मको कुरा के हुन सक्छ कि हामीले कुनै च्याट ID पास गरिरहेका छैनौं र ChatMessage/ChatMessageUI मोडेलमा पनि छैन। मैले यो जानाजानी गरें ताकि उदाहरणहरूको कोड अव्यवस्थित नहोस् (च्याटहरू अलग छन्, त्यसैले हामी मान्न सक्छौं कि हामीसँग एउटा मात्र छ)।

दार्शनिक विषयवस्तुदुबै ChatMessageUI कक्षा र ChatRestApi.getLast विधिले सूची डेटा प्रकार प्रयोग गर्दछ जब वास्तवमा यो अर्डर गरिएको सेट हो। यो JDK मा खराब छ, त्यसैले इन्टरफेस स्तरमा तत्वहरूको क्रम घोषणा गर्न (थप्दा र हटाउने क्रममा अर्डर सुरक्षित गर्ने) काम गर्दैन। त्यसकारण अर्डर गरिएको सेट आवश्यक भएको अवस्थामा सूची प्रयोग गर्ने सामान्य अभ्यास भएको छ (त्यहाँ लिङ्कडह्याससेट पनि छ, तर यो इन्टरफेस होइन)।
महत्त्वपूर्ण सीमा: जवाफ वा स्थानान्तरणको कुनै लामो चेनहरू छैनन् भनी हामी मान्नेछौं। त्यो हो, तिनीहरू अवस्थित छन्, तर तिनीहरूको लम्बाइ तीन सन्देशहरू भन्दा बढी छैन। सन्देशहरूको सम्पूर्ण श्रृंखला फ्रन्टएन्डमा पठाइनु पर्छ।

बाह्य सेवाहरूबाट डाटा प्राप्त गर्न निम्न 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>
}

यो देख्न सकिन्छ कि बाह्य सेवाहरूले सुरुमा ब्याच प्रशोधनका लागि प्रदान गर्दछ, र दुवै संस्करणहरूमा: सेट मार्फत (तत्वहरूको क्रम सुरक्षित नगरी, अद्वितीय कुञ्जीहरूसँग) र सूची मार्फत (त्यहाँ डुप्लिकेट हुन सक्छ - अर्डर सुरक्षित छ)।

सरल कार्यान्वयन

निष्कपट कार्यान्वयन

हाम्रो 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 मा एक कल गरिनेछ। त्यो हो जस्तो लाग्छ। मानौं कि ChatMessage को लागि ForwardFrom र replyTo फिल्डहरू यसरी प्राप्त गरिन्छ कि यसका लागि अनावश्यक कलहरू आवश्यक पर्दैन। तर तिनीहरूलाई ChatMessageUI मा परिणत गर्नाले पुनरावृत्ति हुनेछ, अर्थात्, कल काउन्टरहरू उल्लेखनीय रूपमा बढ्न सक्छ। हामीले पहिले उल्लेख गरेझैं, मानौं कि हामीसँग धेरै नेस्टिङ छैन र चेन तीन सन्देशहरूमा सीमित छ।

फलस्वरूप, हामीले प्रति सन्देश बाह्य सेवाहरूमा दुई देखि छ कलहरू र सन्देशहरूको सम्पूर्ण प्याकेजको लागि एक JPA कल प्राप्त गर्नेछौं। कलहरूको कुल संख्या 2*N+1 देखि 6*N+1 सम्म फरक हुनेछ। वास्तविक एकाइहरूमा यो कति छ? मानौं कि यो पृष्ठ रेन्डर गर्न 20 सन्देशहरू लिन्छ। तिनीहरूलाई प्राप्त गर्न, यसले 4 s देखि 10 सेकेन्ड सम्म लिनेछ। भयानक! म यसलाई 500 ms भित्र राख्न चाहन्छु। र तिनीहरूले फ्रन्टएन्डमा सिमलेस स्क्रोलिङ बनाउने सपना देखेकाले, यस अन्त्यबिन्दुको लागि प्रदर्शन आवश्यकताहरू दोब्बर गर्न सकिन्छ।

प्रो:

1. कोड संक्षिप्त र स्व-डकुमेन्टिङ (एक समर्थन टोलीको सपना) हो।
2. कोड सरल छ, त्यसैले खुट्टामा आफैलाई गोली मार्ने लगभग कुनै अवसरहरू छैनन्।
3. ब्याच प्रशोधन कुनै विदेशी जस्तो देखिदैन र तर्कमा संगठित रूपमा एकीकृत हुन्छ।
4. तर्क परिवर्तनहरू सजिलै बनाइनेछ र स्थानीय हुनेछ।

माइनस:

धेरै सानो प्याकेटको कारण भयानक प्रदर्शन।

यो दृष्टिकोण साधारण सेवाहरूमा वा प्रोटोटाइपहरूमा प्रायः देख्न सकिन्छ। यदि परिवर्तन गर्ने गति महत्त्वपूर्ण छ भने, यो प्रणालीलाई जटिल बनाउन सायद लायक छैन। एकै समयमा, हाम्रो धेरै सरल सेवाको लागि प्रदर्शन भयानक छ, त्यसैले यो दृष्टिकोणको लागू हुने दायरा धेरै साँघुरो छ।

भोली समानांतर प्रशोधन

तपाईं समानान्तरमा सबै सन्देशहरू प्रशोधन सुरु गर्न सक्नुहुन्छ - यसले तपाईंलाई सन्देशहरूको संख्याको आधारमा समयको रैखिक वृद्धिबाट छुटकारा पाउन अनुमति दिनेछ। यो विशेष रूपमा राम्रो मार्ग होइन किनभने यसले बाह्य सेवामा ठूलो शिखर भारको परिणाम दिन्छ।

समानान्तर प्रशोधन कार्यान्वयन धेरै सरल छ:

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

समानान्तर सन्देश प्रशोधन प्रयोग गरेर, हामीले आदर्श रूपमा 300-700 ms पाउँछौं, जुन सरल कार्यान्वयनको तुलनामा धेरै राम्रो छ, तर अझै पनि पर्याप्त छिटो छैन।

यस दृष्टिकोणको साथ, प्रयोगकर्ता रिपोजिटरी र फाइल रिपोजिटरीमा अनुरोधहरू सिंक्रोनस रूपमा कार्यान्वयन गरिनेछ, जुन धेरै प्रभावकारी छैन। यसलाई ठीक गर्न, तपाईंले कल तर्क धेरै धेरै परिवर्तन गर्नुपर्नेछ। उदाहरण को लागी, CompletionStage मार्फत (उर्फ Completable Future):

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()!!

यो देख्न सकिन्छ कि प्रारम्भिक सरल म्यापिङ कोड कम बुझ्न योग्य भएको छ। यो किनभने हामीले बाहिरी सेवाहरूमा कलहरू अलग गर्नुपर्‍यो जहाँ परिणामहरू प्रयोग गरिन्छ। यो आफैमा नराम्रो होइन। तर कलहरू संयोजन गर्दा धेरै सुरुचिपूर्ण देखिँदैन र एक सामान्य प्रतिक्रियाशील "नूडल" जस्तो देखिन्छ।

यदि तपाइँ coroutines प्रयोग गर्नुहुन्छ भने, सबै कुरा अधिक सभ्य देखिनेछ:

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 ms प्राप्त गर्नेछौं, जुन पहिले नै हाम्रो अपेक्षाको नजिक छ।

दुर्भाग्यवश, यस्तो राम्रो समानान्तर अवस्थित छैन, र तिर्न को लागी मूल्य एकदम क्रूर छ: एकै समयमा काम गर्ने केहि प्रयोगकर्ताहरु संग, अनुरोध को एक ब्यारेज सेवाहरु मा पर्नेछ, जसरी पनि समानान्तर मा प्रशोधन गरिने छैन, त्यसैले हामी हाम्रो दुखी 4 s मा फर्किनेछ।

यस्तो सेवा प्रयोग गर्दा मेरो परिणाम 1300 सन्देशहरू प्रशोधन गर्न 1700-20 ms हो। यो पहिलो कार्यान्वयन भन्दा छिटो छ, तर अझै पनि समस्या समाधान गर्दैन।

समानान्तर प्रश्नहरूको वैकल्पिक प्रयोगहरूतेस्रो-पक्ष सेवाहरूले ब्याच प्रशोधन प्रदान गर्दैन भने के हुन्छ? उदाहरणका लागि, तपाइँ इन्टरफेस विधिहरू भित्र ब्याच प्रशोधन कार्यान्वयनको अभाव लुकाउन सक्नुहुन्छ:

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. राम्रो स्केलेबिलिटी।

Cons:

1. समानान्तर रूपमा विभिन्न सेवाहरूमा अनुरोधहरू प्रशोधन गर्दा यसको प्रशोधनबाट डाटा अधिग्रहण अलग गर्न आवश्यक छ।
2. तेस्रो-पक्ष सेवाहरूमा लोड बढ्यो।

यो देख्न सकिन्छ कि व्यावहारिकता को दायरा लगभग भोली दृष्टिकोण को जस्तै छ। यदि तपाइँ अरूको निर्दयी शोषणको कारणले तपाइँको सेवाको कार्यसम्पादन धेरै पटक बढाउन चाहनुहुन्छ भने समानान्तर अनुरोध विधि प्रयोग गर्न यो अर्थपूर्ण छ। हाम्रो उदाहरणमा, प्रदर्शन 2,5 गुणा बढ्यो, तर यो स्पष्ट रूपमा पर्याप्त छैन।

क्यासिङ

तपाईले बाह्य सेवाहरूको लागि JPA को भावनामा क्यासिङ गर्न सक्नुहुन्छ, त्यो हो, प्राप्त वस्तुहरूलाई सत्र भित्र भण्डार गर्नुहोस् ताकि तिनीहरूलाई फेरि प्राप्त नहोस् (ब्याच प्रशोधनका क्रममा सहित)। तपाईंले त्यस्ता क्यासहरू आफैं बनाउन सक्नुहुन्छ, तपाईं यसको @Cacheable सँग Spring प्रयोग गर्न सक्नुहुन्छ, साथै तपाईं सधैं EhCache जस्तै म्यानुअल रूपमा तयार क्यास प्रयोग गर्न सक्नुहुन्छ।

एक सामान्य समस्या यो हुनेछ कि क्यासहरू मात्र उपयोगी छन् यदि तिनीहरूसँग हिट छ। हाम्रो अवस्थामा, लेखक फिल्डमा हिटहरू धेरै सम्भावित छन् (मानौं, 50%), तर त्यहाँ फाइलहरूमा कुनै पनि हिट हुनेछैन। यस दृष्टिकोणले केही सुधारहरू प्रदान गर्नेछ, तर यसले मौलिक रूपमा प्रदर्शन परिवर्तन गर्दैन (र हामीलाई सफलता चाहिन्छ)।

इन्टरसेसन (लामो) क्यासहरूलाई जटिल अमान्यता तर्क चाहिन्छ। सामान्यतया, पछि तपाईं इन्टरसेसन क्यासहरू प्रयोग गरेर प्रदर्शन समस्याहरू समाधान गर्न तल जानुहुन्छ, राम्रो।

प्रो:

1. कोड परिवर्तन नगरी क्यासिङ लागू गर्नुहोस्।
2. उत्पादकता धेरै पटक बढ्यो (केहि अवस्थामा)।

Cons:

1. यदि गलत रूपमा प्रयोग गरियो भने कम प्रदर्शनको सम्भावना।
2. ठूलो मेमोरी ओभरहेड, विशेष गरी लामो क्यास संग।
3. जटिल अमान्यता, त्रुटिहरू जसमा रनटाइममा पुन: उत्पादन गर्न गाह्रो हुने समस्याहरू हुन्छन्।

धेरै पटक, क्यासहरू मात्र डिजाइन समस्याहरू छिटो प्याच गर्न प्रयोग गरिन्छ। यसको मतलब यो होइन कि तिनीहरू प्रयोग गर्नु हुँदैन। जे होस्, तपाईंले तिनीहरूलाई सधैं सावधानीपूर्वक व्यवहार गर्नुपर्छ र पहिले नतिजा प्रदर्शन लाभको मूल्याङ्कन गर्नुहोस्, र त्यसपछि मात्र निर्णय गर्नुहोस्।

हाम्रो उदाहरणमा, क्यासहरूले लगभग 25% को प्रदर्शन वृद्धि प्रदान गर्नेछ। एकै समयमा, क्यासहरूमा धेरै बेफाइदाहरू छन्, त्यसैले म तिनीहरूलाई यहाँ प्रयोग गर्दिन।

परिणामहरू

त्यसोभए, हामीले ब्याच प्रशोधन प्रयोग गर्ने सेवाको निष्कपट कार्यान्वयन, र यसलाई गति बढाउन केही सरल तरिकाहरू हेर्यौं।

यी सबै विधिहरूको मुख्य फाइदा सादगी हो, जसबाट त्यहाँ धेरै सुखद परिणामहरू छन्।

यी विधिहरूसँग एक सामान्य समस्या खराब प्रदर्शन हो, मुख्य रूपमा प्याकेटहरूको आकारको कारणले। त्यसकारण, यदि यी समाधानहरूले तपाईंलाई उपयुक्त गर्दैनन् भने, यो थप कट्टरपन्थी विधिहरू विचार गर्न लायक छ।

त्यहाँ दुई मुख्य दिशाहरू छन् जसमा तपाइँ समाधानहरू खोज्न सक्नुहुन्छ:

• डेटाको साथ एसिन्क्रोनस कार्य (एक प्रतिमान परिवर्तन आवश्यक छ, त्यसैले यस लेखमा छलफल गरिएको छैन);
• सिंक्रोनस प्रशोधन कायम गर्दा ब्याचहरूको विस्तार।

ब्याचहरूको विस्तारले बाह्य कलहरूको संख्यालाई धेरै कम गर्नेछ र एकै समयमा कोडलाई सिंक्रोनस राख्छ। लेखको अर्को भाग यस विषयमा समर्पित हुनेछ।

स्रोत: www.habr.com