Що сталося

Приклад, з якого він стартує, побутовий. Треба опитати п’ять серверів. Послідовна програма чекає відповідь першого, потім другого, потім третього. Поки одна адреса мовчить, решта простоює. Горутина дозволяє відправити перевірку і зайнятися наступною, не чекаючи завершення попередньої. Для мережі, файлів, фонових завдань і черг викликів це природний режим: більшу частину часу програма все одно чекає чужу відповідь, а не рахує.

Канал у цьому розборі — не прикраса, а спосіб забрати результат, не лізучи в чужу пам’ять руками. Буфер змінює ритм. Канал make(chan int, 10) тримає десять значень, і відправник блокується лише коли буфер повний. Це якраз випадок, коли виробник і споживач не збігаються за швидкістю: коротка пауза на прийомі не зупиняє всю віддачу. Оператор select чекає кілька операцій одразу — наприклад, результат або сигнал таймауту, — і програма може відповісти відмовою, а не висіти на одному каналі.

Пул працівників обмежує, скільки задач іде одночасно. Без такої межі легко запустити горутину на кожен вхідний запит і впертися в пам’ять, файли і з’єднання, хоча кожна окрема горутина і здається дешевою. Автор ставить пул поруч із синхронізацією як практичний прийом, а не як необов’язкове ускладнення: паралельність тут про контроль ресурсів, а не про максимальне число одночасно живих задач.

Окремий шматок — скасування. Запит по HTTP стартував похід у базу, користувач закрив з’єднання. Без явного скасування серверна робота триває вхолосту. Пакет context якраз передає строк і сигнал зупинки вниз по викликах, щоб база та інші очікування завершилися разом із запитом, а не жили своїм життям після відходу клієнта.

Чому це важливо

Перший день з Go створює ілюзію, що паралельність — це префікс перед викликом функції. На навантаженні з багатьох очікувань мережі ця ілюзія дорого коштує: або програма як і раніше працює по черзі і простоює, або горутин стає стільки, скільки запитів, і вузьким місцем стають з’єднання, а не мова. Канал, буфер, вибір за кількома каналами і обмежений пул — це і є мінімальний набір, без якого ключове слово go лише розмножує очікування.

Скасування важливе з тієї ж причини, що і пул. Незавершена робота після обриву клієнта з’їдає ті самі з’єднання і тих самих працівників, які потрібні живим запитам. Для API, опитувань і фонових завдань це ближче до стійкості сервісу, ніж до «просунутого» розділу підручника.

На практиці

Розбір навчальний: у ньому немає заміру на вашому профілі навантаження і немає готового каркаса сервісу. Його варто використовувати як перевірку, що в коді є всі чотири частини, а не лише запуск горутини. П’ять серверів у прикладі легко замінити на пачку вихідних викликів у своєму обробнику і побачити, чи чекаєте ви їх по черзі.

Буфер на десять значень — ілюстрація, не рекомендований розмір черги. Розмір буфера і число працівників обирають за тим, скільки одночасних з’єднань ви реально можете тримати.

1. Розділіть роботу, яка здебільшого чекає мережу або диск, і не ганяйте її строго по черзі, якщо відповіді одна від одної не залежать.
2. Забирайте результати каналом, а не спільною змінною без узгодження.
3. Обмежте число одночасних задач пулом, якщо вхідний потік може бути більшим, ніж вихідні з’єднання.
4. На кілька наслідків — відповідь, таймаут, скасування — використовуйте select, а не одне вічне читання з каналу.
5. Прокидайте context із вхідного запиту в базу і в зовнішні виклики, щоб обрив клієнта зупиняв роботу.

Підсумок

Текст нагадує просту розвилку: Go робить запуск паралельної роботи дешевим, але не робить її безпечною сам по собі. Канали передають дані, буфер і select керують очікуванням, пул тримає стелю, context гасить зайве. Для сервісу на вхідних запитах цього досить, щоб перестати плутати одне ключове слово з готовністю до навантаження.