Открытое тестовое интервью на Go разработчика | Эйч Навыки

23 января 2024 г. · 57 мин. чтения

Сегодня мы разберём реальное собеседование на позицию Go-разработчика, где кандидат проходит через серию технических вопросов и задач, начиная от основ языка и заканчивая архитектурными проблемами. Мы увидим, как интервьюер проверяет не только знание синтаксиса, но и глубокое понимание внутренней работы Go, а также способность кандидата решать задачи, связанные с параллелизмом и распределёнными системами.

Вопрос 1. Как в Go передаются аргументы в функции — по значению или по ссылке?

Таймкод: 00:10:23

Ответ собеседника: Правильный. В Go аргументы передаются либо по указателю, либо по копии; большие объекты рекомендуется передавать по указателю во избежание заполнения стека вызовов, который значительно более ограничен по сравнению с кучей.

Правильный ответ:

1. Базовое правило — всё передаётся по значению

В Go все аргументы функций передаются по значению (by value). Это означает, что при вызове функции создаётся копия передаваемого значения, и функция работает именно с этой копией. В отличие от C++ или Java, в Go нет встроенного механизма «передачи по ссылке» — вместо этого используются указатели.

func modify(x int) {
    x = 42 // меняем локальную копию
}

func main() {
    val := 10
    modify(val)
    fmt.Println(val) // 10 — оригинал не изменился
}

2. Указатели как способ передачи по ссылке

Чтобы функция могла модифицировать оригинальную переменную, в Go принято передавать указатель на неё. При этом сам указатель тоже копируется (передаётся по значению), но он указывает на ту же область памяти, что и оригинал:

func modify(x *int) {
    *x = 42 // меняем значение по адресу
}

func main() {
    val := 10
    modify(&val)
    fmt.Println(val) // 42 — оригинал изменился
}

3. Поведение составных типов

Срез (slice), map, канал (chan), интерфейс и функция — это типы, которые внутри себя уже содержат указатель на данные. При передаче по значению копируется только «заголовок» структуры (указатель, длина, ёмкость), но не сами данные:

func appendElement(s []int) {
    s = append(s, 99) // может создать новый базовый массив
    s[0] = 100        // модифицирует общий базовый массив
}

func main() {
    slice := []int{1, 2, 3}
    appendElement(slice)
    fmt.Println(slice) // [100, 2, 3] — первый элемент изменился,
                       // но 99 не добавилось, т.к. append мог перевыделить память
}

Это важный нюанс: изменение элементов среза внутри функции видно снаружи, но изменение длины/ёмкости через append — нет, если только не вернуть новый срез или не передавать указатель на срез.

Map и chan ведут себя как ссылочные типы — при передаче по значению копируется только указатель на внутреннюю структуру, поэтому изменения содержимого map или отправка данных в chan внутри функции видны вызывающей стороне.

4. Структуры и производительность

Для структур передача по значению означает побайтовое копирование всех полей. Для небольших структур это эффективно (данные помещаются в регистры и стек). Для больших структур рекомендуется передавать по указателю:

type LargeStruct struct {
    data [1024 * 1024]byte
}

// Плохо — копирует 1 МБ при каждом вызове
func processByValue(s LargeStruct) {}

// Хорошо — копирует только 8 байт (указатель)
func processByPointer(s *LargeStruct) {}

5. Стек vs куча

Go использует escape analysis для определения, где размещать переменные — в стеке или куче. Если компилятор определяет, что переменная «убегает» из текущего контекста (например, возвращается указатель на локальную переменную), она размещается в куче. Передача больших объектов по значению действительно может привести к значительным затратам на копирование, особенно если стек ограничен (по умолчанию горутина начинает с 2 КБ стека в современных версиях Go, стек растёт динамически).

6. Итого

В Go всё передаётся по значению — это фундаментальное правило языка.
Для модификации оригинала используются указатели.
Срезы, map, chan — ссылочные типы, их «заголовки» копируются, но данные — нет.
Для больших структур предпочтительна передача по указателю ради производительности.
Компилятор сам решает, размещать данные в стеке или куче, на основе escape analysis.

Вопрос 2. Что такое срез (slice) в Go, как он устроен и как передаётся в функцию?

Таймкод: 00:11:54

Ответ собеседника: Правильный. Слайс — это структура с тремя полями (указатель на массив, длина, ёмкость), данные хранятся в динамической памяти на куче; при передаче в функцию копируется только структура слайса, но указатель внутри остаётся тем же, поэтому можно менять содержимое исходного слайса из функции без передачи по указателю.

Правильный ответ:

1. Внутреннее устройство среза

Срез (slice) в Go — это лёгкая структура-обёртка над массивом, определённая в runtime как:

// runtime/slice.go
type slice struct {
    array unsafe.Pointer // указатель на первый элемент базового массива
    len   int            // текущая длина среза
    cap   int            // ёмкость (capacity) — максимальная длина без перевыделения
}

Поле array указывает на непрерывный блок памяти в куче (или стеке, если компилятор может доказать, что массив не «убегает»). Поля len и cap — целые числа, определяющие, сколько элементов доступно и сколько место зарезервировано.

2. Создание среза

// Литерал — компилятор выделяет массив и создаёт срез
s := []int{1, 2, 3} // len=3, cap=3

// make — явное указание длины и ёмкости
s := make([]int, 3, 10) // len=3, cap=10

// На основе массива
arr := [5]int{1, 2, 3, 4, 5}
s := arr[1:4] // len=3, cap=4 (от индекса 1 до конца массива)

3. Передача среза в функцию

При передаче среза в функцию копируется структура из трёх полей (24 байта на 64-битной системе). Указатель array копируется по значению, но он по-прежнему указывает на тот же базовый массив в памяти:

func modifyElements(s []int) {
    for i := range s {
        s[i] *= 2 // модифицирует оригинальный базовый массив
    }
}

func main() {
    s := []int{1, 2, 3}
    modifyElements(s)
    fmt.Println(s) // [2, 4, 6] — элементы изменились
}

4. Важный нюанс — append и перевыделение памяти

Если внутри функции вызывается append и ёмкости среза не хватает, создаётся новый базовый массив с увеличенной ёмкостью. Локальная копия структуры среза начинает указывать на новый массив, а оригинальный срез вызывающей стороны — нет:

func tryAppend(s []int) {
    s = append(s, 99)       // может создать новый массив
    s[0] = 100              // если был новый массив — меняем его, а не оригинал
    fmt.Println("inside:", s) // [100, 2, 3, 99]
}

func main() {
    s := make([]int, 3, 3) // len=3, cap=3 — ёмкость точно исчерпается
    s[0], s[1], s[2] = 1, 2, 3
    tryAppend(s)
    fmt.Println("outside:", s) // [1, 2, 3] — оригинал не изменился
}

Чтобы изменения через append были видны снаружи, нужно либо вернуть новый срез, либо передавать указатель на срез:

// Вариант 1 — возврат нового среза
func appendAndReturn(s []int) []int {
    return append(s, 99)
}

// Вариант 2 — указатель на срез
func appendViaPointer(s *[]int) {
    *s = append(*s, 99)
}

5. Практические рекомендации

Для чтения и модификации существующих элементов — передавайте срез по значению, это безопасно и эффективно.
Для добавления элементов с возможным перевыделением — возвращайте новый срез или используйте указатель на срез.
Не забывайте, что срез может разделять базовый массив с другими срезами — это источник трудноотлавливаемых багов при параллельном доступе.
При необходимости полной независимой копии используйте copy:

original := []int{1, 2, 3}
independent := make([]int, len(original))
copy(independent, original)

6. Итого

Срез — это структура из трёх полей (указатель, длина, ёмкость), обёртывающая непрерывный блок памяти. При передаче в функцию копируется только эта структура (24 байта), а не данные. Это делает срезы эффективными для передачи, но требует внимательности при использовании append, который может создать новый базовый массив и разорвать связь с оригиналом.

Вопрос 3. Что выведет код со срезами, демонстрирующий работу append, capacity и разделяемой памяти?

Таймкод: 00:14:52

Ответ собеседника: Правильный. После присваивания S2 = S1 оба среза указывают на одну область памяти; при добавлении элемента в S2 происходит переполнение capacity, создаётся новый массив, и S1 с S2 начинают работать с разными областями памяти. Вывод принтов определён верно.

Правильный ответ:

1. Типичный пример задачи

Рассмотрим классический пример, который часто встречается на собеседованиях:

func main() {
    s1 := make([]int, 3, 5) // len=3, cap=5
    s1[0], s1[1], s1[2] = 1, 2, 3

    s2 := s1                  // s2 указывает на тот же базовый массив
    s2 = append(s2, 4)        // cap не превышен, новый массив НЕ создаётся

    fmt.Println(s1)           // [1 2 3]
    fmt.Println(s2)           // [1 2 3 4]

    s2[0] = 100               // модификация общего базового массива

    fmt.Println(s1)           // [100 2 3]
    fmt.Println(s2)           // [100 2 3 4]

    s2 = append(s2, 5)        // cap исчерпан (len=5, cap=5), создаётся НОВЫЙ массив
    s2 = append(s2, 6)        // добавляем ещё один элемент в новый массив

    s2[0] = 999               // модификация НОВОГО массива

    fmt.Println(s1)           // [100 2 3] — не изменился
    fmt.Println(s2)           // [999 2 3 4 5 6]
}

2. Пошаговый разбор

Шаг 1 — создание s1:

s1: {array→[_, _, _, _, _], len=3, cap=5}
          [1,  2,  3,  _,  _]

Шаг 2 — присваивание s2 = s1:

s1: {array→[1, 2, 3, _, _], len=3, cap=5}
s2: {array→[1, 2, 3, _, _], len=3, cap=5}  // тот же указатель

Шаг 3 — append(s2, 4): Ёмкости хватает (len станет 4, cap=5), новый массив не создаётся:

s1: {array→[1, 2, 3, 4, _], len=3, cap=5}  // s1[3] записан, но s1.len=3
s2: {array→[1, 2, 3, 4, _], len=4, cap=5}

s1 при печати покажет только 3 элемента, но в базовом массиве по индексу 3 уже лежит 4.

Шаг 4 — s2[0] = 100: Оба среза делят базовый массив, поэтому изменение видно через s1:

s1: [100, 2, 3]
s2: [100, 2, 3, 4]

Шаг 5 — append(s2, 5): Теперь len=5, cap=5 — ёмкость исчерпана. Runtime создаёт новый массив (обычно с удвоенной ёмкостью), копирует данные:

s1: {array→[100, 2, 3, 4, 5], len=3, cap=5}  // старый массив
s2: {array→[100, 2, 3, 4, 5, ...], len=5, cap=10}  // НОВЫЙ массив

Шаг 6 — s2[0] = 999: s2 теперь указывает на новый массив, s1 — на старый:

s1: [100, 2, 3]
s2: [999, 2, 3, 4, 5, 6]

3. Ключевые принципы

Присваивание среза копирует структуру (указатель, len, cap), но не данные. Оба среза делят базовый массив.
append без перевыделения модифицирует общий массив — изменения видны всем срезам, ссылающимся на него.
append с перевыделением (при нехватке cap) создаёт новый массив — срезы расходятся и становятся независимыми.
len среза определяет, сколько элементов видно при печати и итерации, даже если в базовом массиве есть данные дальше.

4. Практический совет

Если нужна гарантированно независимая копия среза, используйте copy:

s1 := []int{1, 2, 3}
s2 := make([]int, len(s1))
copy(s2, s1) // s2 имеет свой базовый массив

Или идиоматический способ отсечения, предотвращающий утечку памяти от большого базового массива:

// Берём только первые 3 элемента, отсекая «хвост»
s2 := append([]int(nil), s1[:3]...)

Вопрос 4. Что такое map в Go, как работает эвакуация данных, как map передаётся в функцию, потокобезопасна ли она и гарантируется ли порядок итерации?

Таймкод: 00:20:36

Ответ собеседника: Неполный. Мапа — это хеш-таблица для хранения пар ключ-значение; при заполненности бакета свыше ~6.5 элементов происходит эвакуация; мапа передаётся аналогично срезу — копируется структура с указателем; обычная мапа не потокобезопасна; порядок итерации не гарантируется. Не упомянуты детали устройства бакетов, хеш-функции и типы эвакуации.

Правильный ответ:

1. Внутреннее устройство map

Map в Go — это хеш-таблица, реализованная в runtime как структура hmap:

// runtime/map.go (упрощённо)
type hmap struct {
    count     int            // текущее количество элементов
    flags     uint8
    B         uint8          // логарим количества бакетов (2^B бакетов)
    noverflow uint16         // количество переполненных бакетов
    hash0     uint32         // seed для хеш-функции (рандомизируется при создании)
    buckets    unsafe.Pointer // указатель на массив бакетов
    oldbuckets unsafe.Pointer // указатель на старый массив бакетов (при эвакуации)
    nevacuate  uintptr       // прогресс эвакуации
    // ...
}

Каждый бакет (bmap) — это структура, хранящая до 8 пар ключ-значение. Внутри бакета ключи и значения хранятся отдельно (не как пары key-value подряд), что улучшает кэш-локальность при итерации только по ключам или только по значениям.

2. Механизм хеширования и поиска

При обращении к мапе m[key]:

Вычисляется hash = hashFunction(key, hmap.hash0) — хеш-функция зависит от типа ключа и рандомизированного seed.
Младшие B бит хеша определяют номер бакета: bucketIndex = hash & (2^B - 1).
Старшие 8 бит (topHash = hash >> 56) используются для быстрого сравнения внутри бакета — сначала сравниваются topHash, и только при совпадении — сами ключи.
Если бакет переполнен, проверяются цепочки переполненных бакетов (overflow buckets).

3. Эвакуация данных (evacuation)

Go использует два типа роста мапы:

А. Постепенное увеличение (incremental growth) — когда loadFactor > 6.5

Load factor рассчитывается как count / (2^B), где 2^B — количество бакетов. Среднее количество элементов на бакет не должно превышать ~6.5. При превышении:

Количество бакетов удваивается (B += 1).
Создаётся новый массив бакетов, старый сохраняется в oldbuckets.
Эвакуация происходит постепенно — при каждой последующей записи или удалении эвакуируются 2 бакета из старого массива. Это распределяет стоимость перемещения по времени и предотвращает длительные паузы.

Б. Равномерное перераспределение (same-size growth) — при большом количестве overflow-бакетов

Если мапа содержит слишком много переполненных бакетов (более 2^15), но load factor ещё в норме, Go выполняет реорганизацию без увеличения их количества — просто перемещает данные, устраняя цепочки overflow.

Процесс эвакуации бакета:

// Упрощённая логика эвакуации
func evacuate(t *maptype, h *hmap, oldbucket uintptr) {
    b := (*bmap)(add(h.oldbuckets, oldbucket*uintptr(t.bucketsize)))
    newbit := h.noldbuckets() // новая ёмкость в бакетах

    for ; b != nil; b = b.overflow(t) {
        for i := uintptr(0); i < bucketCnt; i++ {
            top := b.tophash[i]
            if top == emptyRest || top == emptyOne {
                continue
            }
            k := add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize))
            v := add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.valuesize))

            // Определяем, в какой из двух новых бакетов попадёт элемент
            var xb uintptr // бакет в первой половине
            var yb uintptr // бакет во второй половине
            // ... хеш-функция определяет, куда переместить
        }
    }
}

4. Передача map в функцию

Map — это ссылочный тип. Переменная m типа map[K]V внутри содержит указатель на структуру hmap. При передаче в функцию копируется только этот указатель (8 байт), а не вся хеш-таблица:

func addEntry(m map[string]int) {
    m["new"] = 42 // видно в вызывающем коде
}

func main() {
    m := map[string]int{"a": 1}
    addEntry(m)
    fmt.Println(m) // map[a:1 new:42]
}

5. Потокобезопасность

Стандартная map не является потокобезопасной. Параллельная запись, или одновременная запись и чтение, вызывает панику:

// Это приведёт к панике: concurrent map writes
func main() {
    m := make(map[int]int)
    go func() { for i := 0; i < 1000; i++ { m[i] = i } }()
    go func() { for i := 0; i < 1000; i++ { m[i] = i } }()
    time.Sleep(time.Second)
}

Для безопасной конкурентной работы есть три подхода:

А. sync.Mutex / sync.RWMutex:

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}

func (s *SafeMap) Get(key string) (int, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    val, ok := s.m[key]
    return val, ok
}

func (s *SafeMap) Set(key string, val int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.m[key] = val
}

Б. sync.Map — специализированная конкурентная мапа из стандартной библиотеки, оптимизированная для сценариев с редкой записью и частым чтением:

var m sync.Map
m.Store("key", 42)
val, ok := m.Load("key")

В. Шардирование — разделение на несколько мьютексов по хешу ключа для уменьшения конкуренции.

6. Порядок итерации

Порядок итерации по map не гарантируется и намеренно рандомизируется. Начиная с Go 1.0, при каждой итерации выбирается случайный начальный бакет. Начиная с Go 1.12, порядок также зависит от размера мапы и истории её модификаций.

m := map[string]int{"a": 1, "b": 2, "c": 3}
for k, v := range m {
    fmt.Println(k, v) // порядок каждый раз разный
}

Если нужен детерминированный порядок — нужно отсортировать ключи:

keys := make([]string, 0, len(m))
for k := range m {
    keys = append(keys, k)
}
sort.Strings(keys)
for _, k := range keys {
    fmt.Println(k, m[k])
}

7. Итого

Map — хеш-таблица с бакетами по 8 элементов, использующая хеш-функцию с рандомизированным seed.
При load factor > 6.5 происходит постепенная эвакуация — удвоение числа бакетов с инкрементальным перемещением данных.
Map передаётся в функцию как указатель — изменения видны вызывающей стороне.
Стандартная map не потокобезопасна — для конкурентного доступа используются sync.Mutex, sync.Map или шардирование.
Порядок итерации рандомизирован и не гарантируется.

Вопрос 5. Что такое интерфейс в Go, для чего он используется и как он устроен внутри?

Таймкод: 00:30:45

Ответ собеседника: Неполный. Интерфейс — это контракт, который структура может выполнять (duck typing); используется для полиморфизма, абстрагирования и тестирования (моки). Не раскрыты внутреннее устройство — таблица методов (itable), проверка удовлетворения интерфейсу, разница между eface и iface.

Правильный ответ:

1. Определение и назначение

Интерфейс в Go — это набор сигнатур методов (контракт). Любой тип, реализующий все методы интерфейса, автоматически удовлетворяет ему — это структурная типизация (structural typing), часто называемая «утиной типизацией» (duck typing):

type Writer interface {
    Write(p []byte) (n int, err error)
}

// File удовлетворяет Writer, потому что имеет метод Write
// Явное указание «реализует» не требуется

Интерфейсы используются для:

Полиморфизма — работа с разными типами через единый контракт.
Абстрагирования — разделение зависимостей в коде (Dependency Inversion).
Тестирования — подмена реальных зависимостей моками.
Расширяемости — добавление новой функциональности без изменения существующего кода.

2. Внутреннее устройство — два вида интерфейсов

В runtime Go использует две структуры для представления интерфейсов:

А. eface — пустой интерфейс (interface{} или any)

// runtime/runtime2.go
type eface struct {
    _type *_type // указатель на информацию о типе
    data  unsafe.Pointer // указатель на данные
}

Используется, когда интерфейс не содержит методов (или в обобщённом виде). Содержит только указатель на тип и указатель на значение.

Б. iface — непустой интерфейс (с методами)

type iface struct {
    tab  *itab // указатель на таблицу интерфейса
    data unsafe.Pointer // указатель на данные
}

Содержит указатель на itab (interface table) и указатель на данные.

3. Таблица методов — itab

type itab struct {
    inter *interfacetype // метаданные интерфейса
    _type *_type         // метаданные конкретного типа
    hash  uint32         // хеш типа (для быстрого сравнения)
    _     [4]byte        // padding
    fun   [1]uintptr     // массив указателей на методы (размер определяется при создании)
}

Поле fun — это виртуальная таблица методов (vtable). Каждый элемент — указатель на конкретную реализацию метода для данного типа. Размер массива равен количеству методов в интерфейсе.

4. Механизм проверки и вызова

Присваивание переменной интерфейса:

var w Writer = os.Stdout

Компилятор генерирует вызов runtime.getitab() (или runtime.convI2I), который:

Проверяет, реализует ли *os.File интерфейс Writer.
Если да — создаёт (или находит в кэше) itab с указателями на методы.
Если нет — паника при приседи или ошибка компиляции (для статических типов).

Вызов метода через интерфейс:

w.Write([]byte("hello"))

Компилятор генерирует:

Загрузка itab из интерфейса.
Загрузка указателя на функцию из itab.fun[0] (для Write).
Вызов функции с передачей data как первого аргумента (receiver).

Это косвенный вызов (indirect call), что дороже прямого вызова, но дешевле динамической диспетчеризации в языках с наследованием.

5. Кэширование itab

Go кэширует созданные itab в хеш-таблице runtime.itabTable. При повторном присваивании того же типа к тому же интерфейсу используется кэш, что избегает повторного создания таблицы.

6. Пустой интерфейс interface{} / any

Пустой интерфейс не требует itab, потому что нет методов для диспетчеризации. Используется eface, который легче (нет таблицы методов):

func printAny(v interface{}) {
    // Type assertion для извлечения конкретного типа
    if s, ok := v.(string); ok {
        fmt.Println("string:", s)
    }
}

7. Type assertion и type switch

// Type assertion
if f, ok := w.(*os.File); ok {
    f.Stat()
}

// Type switch
switch v := w.(type) {
case *os.File:
    fmt.Println("file:", v.Name())
case *bytes.Buffer:
    fmt.Println("buffer:", v.String())
default:
    fmt.Println("unknown")
}

8. Встраивание интерфейсов

Интерфейсы можно комбинировать:

type ReadWriter interface {
    Reader // встраивание
    Writer
}

При этом методы обоих интерфейсов объединяются в один interfacetype.

9. Нулевой интерфейс

Нулевое значение интерфейса — nil и для tab, и для data. Важный нюанс:

var p *os.File = nil
var w Writer = p // w не nil! tab != nil, data == nil

if w == nil { // false!
    fmt.Println("nil")
}

Это частая ошибка — интерфейс, содержащий нулевой указатель на конкретный тип, не равен nil. Для безопасной проверки используйте reflect.ValueOf(w).IsNil() или явную проверку типа.

10. Итого

Интерфейс — контракт из методов; любой тип, реализующий эти методы, автоматически удовлетворяет интерфейсу.
Внутри: iface (для непустых интерфейсов) и eface (для interface{}).
itab — таблица с указателями на методы (vtable), создаётся и кэшируется при первом присваивании.
Вызов метода через интерфейс — косвенный вызов через itab.fun.
Нулевой интерфейс с ненулевым типом, но нулевыми данными — не nil, что источник багов.

Вопрос 6. Что выведет код с интерфейсом, где метод возвращает nil-указатель на структуру, и при каких условиях возникнет nil pointer dereference?

Таймкод: 00:36:49

Ответ собеседника: Правильный. При возврате из метода указателя (*T) интерфейс не будет равен nil, поскольку интерфейс содержит тип + значение, и тип не nil. Код вызовет метод без паники, если внутри метода не обращаются к полям ресивера.

Правильный ответ:

1. Классический пример проблемы

type MyInterface interface {
    DoSomething()
}

type MyStruct struct {
    value int
}

func (m *MyStruct) DoSomething() {
    fmt.Println("Doing something with value:", m.value) // обращение к полю
}

func getInterface() MyInterface {
    var m *MyStruct = nil // нулевой указатель
    return m              // возвращаем как интерфейс
}

func main() {
    iface := getInterface()
    fmt.Println("iface == nil:", iface == nil) // false!
    iface.DoSomething()                         // panic: nil pointer dereference
}

2. Почему iface == nil возвращает false

Интерфейс в Go — это пара (тип, значение). Нулевой интерфейс — это (nil, nil). Но когда мы возвращаем nil указатель *MyStruct, интерфейс становится:

iface{tab: *itab{inter: MyInterface, _type: *MyStruct}, data: nil}

То есть tab не nil (тип известен), а data — nil. Интерфейс в целом не равен nil, потому что одна из двух компонент ненулевая.

3. Когда возникает паника

Паника nil pointer dereference возникает при обращении к полям или методам через нулевой указатель:

func (m *MyStruct) SafeMethod() {
    fmt.Println("I'm safe") // нет обращения к m — паники нет
}

func (m *MyStruct) UnsafeMethod() {
    fmt.Println(m.value) // обращение к полю — panic!
}

Если метод не обращается к полям receiver'а, вызов не вызовет панику, даже если receiver — nil.

4. Практический пример — ошибка в возврате из функции

Частая ошибка — возврат ошибки как интерфейса:

type MyError struct {
    msg string
}

func (e *MyError) Error() string {
    return e.msg
}

func doWork() error {
    var err *MyError = nil
    // ... логика, где err остаётся nil ...
    return err // возвращаем nil *MyError как error
}

func main() {
    err := doWork()
    if err != nil { // true! err не nil
        fmt.Println("Error:", err)
    } else {
        fmt.Println("No error")
    }
}

Вывод: Error: — хотя мы вернули «nil», интерфейс error не равен nil.

5. Как избежать проблемы

А. Явный возврат nil как интерфейса:

func doWork() error {
    // ...
    if somethingWrong {
        return &MyError{msg: "oops"}
    }
    return nil // возвращаем именно nil, а не *MyError(nil)
}

Б. Использование переменной типа error:

func doWork() error {
    var err error = nil // тип — error, не *MyError
    // ...
    return err // это настоящий nil интерфейса
}

В. Проверка через reflect (для отладки):

import "reflect"

func isNilInterface(i interface{}) bool {
    if i == nil {
        return true
    }
    v := reflect.ValueOf(i)
    switch v.Kind() {
    case reflect.Ptr, reflect.Interface, reflect.Func, reflect.Map, reflect.Slice:
        return v.IsNil()
    }
    return false
}

6. Итого

Интерфейс — пара (тип, значение). Нулевой интерфейс — (nil, nil).
Возврат nil указателя на конкретный тип как интерфейс создаёт ненулевой интерфейс с нулевыми данными.
Паника возникает при обращении к полям/методам через нулевой receiver.
Для избежания: возвращайте nil явно, не приводя к конкретному типу, или используйте переменную типа интерфейса.

Вопрос 7. Что такое каналы в Go, какие бывают типы каналов и что роизойдёт при чтении/записи в неинициализированный (nil) канал?

Таймкод: 00:40:00

Ответ собеседника: Неполный. Каналы — структура для коммуникации между горутинами; бывают буферизованные и небуферизованные; при чтении/записи в nil-канал происходит блокировка навсегда. Не раскрыты внутреннее устройство каналов, направленность, поведение закрытого канала и детали про select с nil-каналами.

Правильный ответ:

1. Определение и назначение

Канал (channel) — это типизированный канал связи между горутинами, реализующий принцип CSP (Communicating Sequential Processes). Каналы обеспечивают безопасную передачу данных без явных блокировок и разделяемой памяти:

ch := make(chan int) // создание канала
ch <- 42             // отправка
val := <-ch          // получение

2. Типы каналов

А. По направлению:

ch := make(chan int)    // двунаправленный (send + receive)
var send chan<- int = ch // только отправка
var recv <-chan int = ch // только получение

Направленные каналы используются для ограничения доступа в функциях:

func producer(ch chan<- int) {
    ch <- 42
    // val := <-ch // ошибка компиляции: нельзя читать из send-only канала
}

func consumer(ch <-chan int) {
    val := <-ch
    // ch <- 10 // ошибка компиляции: нельзя писать в receive-only канал
}

Б. По наличию буфера:

ch1 := make(chan int)      // небуферизованный (буфер = 0)
ch2 := make(chan int, 10)  // буферизованный (буфер = 10)

Небуферизованный канал — синхронная передача. Отправитель блокируется, пока получатель не прочитает значение, и наоборот. Это гарантия синхронизации:

ch := make(chan int)
go func() {
    ch <- 42 // заблокируется, пока main не прочитает
}()
val := <-ch // разблокирует горутину

Буферизованный канал — асинхронная передача до заполнения буфера. Отправитель блокируется только когда буфер полон:

ch := make(chan int, 2)
ch <- 1 // не блокируется
ch <- 2 // не блокируется
ch <- 3 // заблокируется — буфер полон

3. Внутреннее устройство канала

В runtime канал представлен структурой hchan:

// runtime/chan.go (упрощённо)
type hchan struct {
    qcount   uint           // текущее количество элементов в буфере
    dataqsiz uint           // размер буфера
    buf      unsafe.Pointer // кольцевой буфер (для буферизованных)
    sendx    uint           // индекс для следующей отправки
    recvx    uint           // индекс для следующего получения
    recvq    waitq          // очередь ожидающих получателей (sudog)
    sendq    waitq          // очередь ожидающих отправителей (sudog)
    lock     mutex          // мьютекс для защиты структуры
}

Каждая операция отправки/получения защищена мьютексом. При блокировки горутина помещается в очередь (sudog) и переводится в состояние Gwaiting.

4. Поведение nil-канала

Nil-канал — это канал, которому не было присвоено значение (var ch chan int). Его поведение специфично:

var ch chan int // nil канал

ch <- 42       // блокировка навсегда (горутина засыпает и никогда не проснётся)
val := <-ch    // блокировка навсегда
close(ch)      // panic: close of nil channel

Важное исключение — select:

var ch chan int
select {
case ch <- 42:    // этот case никогда не выполнится
    fmt.Println("sent")
case val := <-ch: // этот case никогда не выполнится
    fmt.Println("received")
default:
    fmt.Println("default") // выполнится это
}

В select nil-канал игнорируется — case с ним не рассматривается. Это используется для динамического отключения case'ов:

func merge(ch1, ch2 <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for {
            select {
            case v, ok := <-ch1:
                if !ok {
                    ch1 = nil // отключаем этот case
                    continue
                }
                out <- v
            case v, ok := <-ch2:
                if !ok {
                    ch2 = nil // отключаем этот case
                    continue
                }
                out <- v
            }
            if ch1 == nil && ch2 == nil {
                break
            }
        }
        close(out)
    }()
    return out
}

5. Поведение закрытого канала

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch)

val := <-ch // 1 — можно прочитать оставшиеся значения
val = <-ch  // 2
val = <-ch  // 0 (zero value) — буфер пуст, канал закрыт

// Проверка закрытия
val, ok := <-ch // val=0, ok=false

close(ch) // panic: close of already closed channel

Для небуферизованного канала:

ch := make(chan int)
close(ch)
val := <-ch // 0 — zero value немедленно

6. Идиоматические паттерны

А. Сигнал завершения (done channel):

func worker(done chan struct{}) {
    for {
        select {
        case <-done:
            return // получили сигнал завершения
        default:
            // работа
        }
    }
}

Б. Ограничение конкуренции (semaphore):

sem := make(chan struct{}, 10) // максимум 10 параллельных горутин
for _, task := range tasks {
    sem <- struct{}{} // ждём слот
    go func(t Task) {
        defer func() { <-sem }() // освобождаем слот
        process(t)
    }(task)
}

7. Итого

Каналы — типизированные очереди для безопасной коммуникации между горутинами.
Небуферизованные — синхронные (блокировка до парной операции), буферизованные — асинхронные до заполнения буфера.
Nil-канал: запись/чтение блокирует навсегда, close вызывает панику. В select nil-case игнорируется.
Закрытый канал: можно читать оставшиеся значения, затем получается zero value. Повторный close — паника.
Внутри канал — hchan с мьютексом, кольцевым буфером и очередями ожидающих горутин.

Вопрос 8. Что выведет код с горутинами, захватывающими переменную цикла, и какие проблемы есть в коде с мапой, каналом и группой горутин?

Таймкод: 00:42:10

Ответ собеседника: Правильный. Код с горутинами и переменной цикла выведет непредсказуемый результат из-за отсутствия синхронизации; канал не инициализирован (nil), мапа не потокобезопасна, переменная цикла захватывается некорректно.

Правильный ответ:

1. Классическая проблема захвата переменной цикла

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println(i) // замыкание захватывает переменную i по ссылке
        }()
    }
    wg.Wait()
}

Проблема: Все горутины захватывают одну и ту же переменную i по ссылке. К моменту выполнения горутины цикл уже завершился, и i равно 5. Вывод — пять пятёрок (или другой непредсказуемый результат, если некоторые горутины успеют выполниться до завершения цикла).

Исправление — передача параметра:

for i := 0; i < 5; i++ {
    wg.Add(1)
    go func(val int) {
        defer wg.Done()
        fmt.Println(val) // каждый вызов получает свою копию
    }(i) // передаём текущее значение
}

Или создание локальной переменной внутри цикла (до Go 1.22):

for i := 0; i < 5; i++ {
    i := i // теневая переменная
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println(i) // захватываем локальную копию
    }()
}

Начиная с Go 1.22 эта проблема устранена на уровне языка — каждая итерация цикла for создаёт новую переменную, поэтому замыкания захватывают разные значения.

2. Типичные проблемы с мапой, каналом и группой горутин

func process(items []int) map[int]int {
    results := make(map[int]int)
    var wg sync.WaitGroup
    ch := make(chan int)

    for _, item := range items {
        wg.Add(1)
        go func() {
            defer wg.Done()
            result := item * 2 // проблема 1: захват переменной цикла
            results[result]++  // проблема 2: concurrent map write
            ch <- result       // проблема 3: блокировка, если никто не читает
        }()
    }

    wg.Wait()
    close(ch) // проблема 4: горутины уже заблокированы на ch <- result
    return results
}

Проблема 1 — захват переменной цикла: item захватывается по ссылке, все горутины видят последнее значение.

Исправление:

go func(item int) {
    // ...
}(item)

Проблема 2 — concurrent map write: Мапа в Go не потокобезопасна. Параллельная запись вызывает панику.

Исправление:

var mu sync.Mutex
// внутри горутины:
mu.Lock()
results[result]++
mu.Unlock()

Или использование sync.Map.

Проблема 3 и 4 — дедлок с каналом: Небуферизованный канал ch блокирует отправителя до появления получателя. Но wg.Wait() вызывается до чтения из канала — дедлок:

горутины ждут: ch <- result (никто не читает)
main ждёт: wg.Wait() (горутины не завершатся)

Исправление — отдельная горутина для закрытия канала:

go func() {
    wg.Wait()
    close(ch)
}()

// чтение из канала в main-горутине
for result := range ch {
    fmt.Println(result)
}

3. Полностью исправленный код

func process(items []int) map[int]int {
    results := make(map[int]int)
    var mu sync.Mutex
    var wg sync.WaitGroup
    ch := make(chan int)

    for _, item := range items {
        wg.Add(1)
        go func(item int) {
            defer wg.Done()
            result := item * 2

            mu.Lock()
            results[result]++
            mu.Unlock()

            ch <- result
        }(item)
    }

    // Закрываем канал после завершения всех горутин
    go func() {
        wg.Wait()
        close(ch)
    }()

    // Читаем из канала (опционально)
    for range ch {
    }

    return results
}

4. Итого

Захват переменной цикла замыканием — одна из самых частых ошибок в Go (исправлена в Go 1.22).
Мапа не потокобезопасна — нужна синхронизация при конкурентной записи.
Небуферизованный канал без получателя приводит к дедлоку.
Паттерн «горутина-закрывалка» (go func() { wg.Wait(); close(ch) }()) — стандартный способ безопасного закрытия канала после завершения воркеров.

Вопрос 9. Что такое context в Go, для чего он используется и что в него рекомендуется класть?

Таймкод: 00:52:34

Ответ собеседника: Правильный. Контекст — механизм для передачи данных, связанных с выполнением запроса, через дерево вызовов; используется для тайм-аутов, отмены операций, передачи системной информации; рекомендуется класть инфраструктурную/системную информацию, а не бизнес-логику.

Правильный ответ:

1. Определение и назначение

context.Context — это интерфейс из стандартной библиотеки, предназначенный для передачи сигналов отмены, тайм-аутов и данных, специфичных для запроса, через границы API и между горутинами:

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key any) any
}

Основные сценарии использования:

Отмена операций — распространение сигнала отмены по дереву вызовов.
Тайм-ауты и дедлайны — ограничение времени выполнения операции.
Передача данных запроса — значения, специфичные для конкретного запроса (trace ID, user ID и т.д.).

2. Типы контекстов

А. context.Background() — корневой контекст, никогда не отменяется, без тайм-аута. Используется в main, обработчиках запросов, тестах:

ctx := context.Background()

Б. context.TODO() — заглушка, когда неясно, какой контекст использовать, или функция ещё не поддерживает контекст:

ctx := context.TODO()

В. context.WithCancel(parent) — создаёт контекст с возможностью ручной отмены:

ctx, cancel := context.WithCancel(context.Background())
defer cancel() // важно всегда вызывать, чтобы освободить ресурсы

go func() {
    time.Sleep(time.Second)
    cancel() // отмена всех дочерних контекстов
}()

select {
case <-ctx.Done():
    fmt.Println("cancelled:", ctx.Err()) // context canceled
}

Г. context.WithTimeout(parent, duration) — автоматическая отмена по тайм-ауту:

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// Если операция не завершится за 5 секунд — ctx.Done() закроется

Д. context.WithDeadline(parent, time) — автоматическая отмена в указанное время:

ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(5*time.Second))
defer cancel()

Е. context.WithValue(parent, key, value) — привязка данных к контексту:

type contextKey string // собственный тип для ключей — обязательно

const userIDKey contextKey = "userID"

ctx := context.WithValue(context.Background(), userIDKey, 12345)
userID := ctx.Value(userIDKey).(int)

3. Иерархия и распространение отмены

Контексты образуют дерево. Отмена родительского контекста автоматически отменяет все дочерние:

root, cancel := context.WithCancel(context.Background())

child1, _ := context.WithCancel(root)
child2, _ := context.WithCancel(root)

grandchild, _ := context.WithCancel(child1)

cancel() // отменяет root, child1, child2 и grandchild

Однако отмена дочернего контекста не отменяет родительский.

4. Что рекомендуется класть в контекст

А. Инфраструктурные/системные данные:

Trace ID / Span ID (для распределённой трассировки)
User ID / Session ID (для авторизации)
Request ID (для корреляции логов)
IP-адрес клиента
Информация о языке/локали

Б. Чего НЕ рекомендуется класть:

Параметры бизнес-логики (нарушает явность контракта функции)
Большие объекты (контекст передаётся по значению, данные копируются)
Опциональные параметры (злоупотребление приводит к «магическим» зависимостям)
Зависимости (базы данных, клиенты) — для этого лучше использовать структуры с зависимостями

5. Идиоматическое использование

Контекст всегда передаётся как первый параметр функции (соглашение Go):

func HandleRequest(ctx context.Context, req *Request) (*Response, error) {
    // Проверяем отмену перед длительными операциями
    if err := ctx.Err(); err != nil {
        return nil, err
    }

    // Передаём контекст вниз по стеку вызовов
    result, err := fetchData(ctx, req.ID)
    if err != nil {
        return nil, err
    }

    return processResult(result), nil
}

func fetchData(ctx context.Context, id int) (*Data, error) {
    // HTTP-запрос с контекстом
    req, _ := http.NewRequestWithContext(ctx, "GET", "/api/data/"+strconv.Itoa(id), nil)
    resp, err := http.DefaultClient.Do(req)
    // ...
}

6. Паттерн graceful shutdown

func main() {
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    srv := &http.Server{Addr: ":8080"}
    go func() {
        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()

    <-ctx.Done() // ждём сигнала ОС

    shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()

    if err := srv.Shutdown(shutdownCtx); err != nil {
        log.Fatal("forced shutdown:", err)
    }
}

7. Итого

context.Context — стандартный механизм для отмены, тайм-аутов и передачи данных запроса.
Контексты образуют дерево: отмена родителя отменяет всех детей.
Контекст всегда первый параметр функции.
В контекст кладут инфраструктурные данные (trace ID, user ID), а не параметры бизнес-логики.
Важно всегда вызывать cancel() для освобождения ресурсов (используйте defer).

Вопрос 10. Какие существуют способы синхронизации горутин в Go помимо каналов и зачем нужны мьютексы при наличии каналов?

Таймкод: 00:56:22

Ответ собеседника: Неполный. Названы sync.WaitGroup, sync.Mutex, sync.RWMutex, atomic, sync.Map, sync.Cond. Не раскрыто, зачем нужны мьютексы при наличии каналов, не упомянут принцип «Communicate by sharing memory, don't share memory by communicating».

Правильный ответ:

1. Философия Go: каналы vs мьютексы

Go придерживается принципа из официального блога:

> «Don't communicate by sharing memory; share memory by communicating.»

Это означает, что предпочтительный способ синхронизации — передача данных через каналы, а не защита разделяемой памяти мьютексами. Однако это не значит, что мьютексы не нужны — они необходимы в случаях, когда каналы избыточны или неэффективны.

2. Полный набор примитивов синхронизации

А. sync.Mutex — взаимоисключающая блокировка:

var mu sync.Mutex
var counter int

func increment() {
    mu.Lock()
    defer mu.Unlock()
    counter++
}

Б. sync.RWMutex — блокировка с разделением читателей и писателей:

var mu sync.RWMutex
var data map[string]int

func read(key string) int {
    mu.RLock()
    defer mu.RUnlock()
    return data[key]
}

func write(key string, val int) {
    mu.Lock()
    defer mu.Unlock()
    data[key] = val
}

Множество горутин могут одновременно читать, но запись — эксклюзивна.

В. sync.WaitGroup — ожидание завершения группы горутин:

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        // работа
    }()
}
wg.Wait() // ждём завершения всех

Г. sync.Once — гарантия однократного выполнения:

var once sync.Once
var instance *Singleton

func GetInstance() *Singleton {
    once.Do(func() {
        instance = &Singleton{}
    })
    return instance
}

Д. sync.Cond — переменная состояния для ожидания событий:

var mu sync.Mutex
cond := sync.NewCond(&mu)
ready := false

// Горутина-ожидатель
go func() {
    mu.Lock()
    for !ready {
        cond.Wait() // освобождает мьютекс и ждёт сигнала
    }
    fmt.Println("Ready!")
    mu.Unlock()
}()

// Горутина-сигнализатор
mu.Lock()
ready = true
cond.Signal() // или cond.Broadcast() для всех
mu.Unlock()

Е. sync.Map — потокобезопасная мапа (оптимизирована для частого чтения):

var m sync.Map
m.Store("key", 42)
val, ok := m.Load("key")

Ж. atomic — атомарные операции без блокировок:

var counter atomic.Int64
counter.Add(1)
val := counter.Load()

Поддерживает Add, Load, Store, Swap, CompareAndSwap для целых чисел и указателей.

3. Когда использовать каналы, а когда — мьютексы

Каналы предпочтительны, когда:

Нужна передача владения данными (ownership transfer)
Необходимо координировать работу нескольких горутин (fan-out, fan-in)
Требуется тайм-аут или отмена через select
Реализация паттернов worker pool, pipeline

// Fan-out: распределение работы между воркерами
func fanOut(input <-chan int, n int) []<-chan int {
    channels := make([]<-chan int, n)
    for i := 0; i < n; i++ {
        channels[i] = worker(input)
    }
    return channels
}

Мьютексы предпочтительны, когда:

Нужна простая защита разделяемого состояния (счётчик, кэш, конфигурация)
Критическая секция очень маленькая и частая (атомарные операции или мьютекс быстрее канала)
Данные не «перемещаются» между горутинами, а изменяются на месте

// Защита кэша — мьютекс уместнее канала
type Cache struct {
    mu    sync.RWMutex
    items map[string]*Item
}

func (c *Cache) Get(key string) (*Item, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    item, ok := c.items[key]
    return item, ok
}

4. Почему мьютексы нужны при наличии каналов

А. Производительность: Каналы в Go — тяжёлые структуры с мьютексом внутри (hchan). Использование канала для защиты простого счётчика — избыточное накладное расходование:

// Медленно: канал для инкремента счётчика
ch := make(chan func(), 1)
go func() {
    counter := 0
    for f := range ch {
        f()
        counter++
    }
}()
ch <- func() { /* работа */ }

// Быстро: мьютекс для инкремента
var mu sync.Mutex
var counter int
mu.Lock()
counter++
mu.Unlock()

// Ещё быстрее: atomic
var counter atomic.Int64
counter.Add(1)

Б. Семантическая ясность: Мьютекс чётко выражает намерение «защитить доступ к данным». Канал выражает «передать данные или сигнал». Использование канала для защиты данных ухудшает читаемость.

В. Гранулярность блокировки: RWMutex позволяет множественным читателям работать параллельно — это сложно и неэффективно реализовать через каналы.

Г. Сложные структуры данных: Защита сложной структуры (дерево, граф) через каналы потребовала бы выделения отдельной горутины-«владельца» и сериализации всех операций через сообщения — это усложняет код.

5. Комбинированный подход

На практике часто используется комбинация:

type Server struct {
    mu       sync.RWMutex
    handlers map[string]Handler

    // Канал для graceful shutdown
    shutdown chan struct{}
}

func (s *Server) Register(name string, h Handler) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.handlers[name] = h
}

func (s *Server) Shutdown() {
    close(s.shutdown) // сигнал через канал
}

6. Итого

Каналы — предпочтительный способ синхронизации в Go, но не единственный.
Мьютексы необходимы для защиты разделяемого состояния, когда каналы избыточны или неэффективны.
Выбор зависит от задачи: передача данных/сигналов — каналы, защита состояния — мьютексы/atomic.
atomic — самый быстрый вариант для простых операций с числами.
RWMutex — оптимален при частом чтении и редкой записи.

Вопрос 11. Чем горутины отличаются от потоков ОС, как устроен планировщик Go (GPM-модель) и что такое work stealing?

Таймкод: 01:01:36

Ответ собеседника: Неполный. Горутины управляются рантаймом Go, переключение контекста дешевле, чем у потоков ОС; упомянуты GPM-модель и очереди. Не раскрыты механизм work stealing, обработка блокирующих системных вызовов и детали работы планировщика.

Правильный ответ:

1. Горутины vs потоки ОС

Характеристика	Горутина	Поток ОС
Размер стека	2–8 КБ (растёт динамически)	1–8 МБ (фиксирован)
Переключение контекста	~100 нс (в user space)	~1–10 мкс (kernel space)
Создание	~200 нс	~10–100 мкс
Максимальное количество	Сотни тысяч — миллионы	Тысячи
Планировщик	Go runtime (M:N)	Ядро ОС (1:1)

Горутины — «зелёные потоки» (green threads), управляемые рантаймом Go, а не ядром ОС. Это позволяет создавать их дешево и переключать без перехода в kernel space.

2. GPM-модель

Планировщик Go использует три сущности:

G (Goroutine) — горутина, представленная структурой с указателем на стек, состоянием и контекстом:

type g struct {
    stack       stack   // текущий стек [lo, hi]
    stackguard0 uintptr // граница стека для проверки переполнения
    m           *m      // текущий M (machine), если выполняется
    sched       gobuf   // контекст планировщика (SP, PC, ...)
    status      uint32  // состояние: Grunning, Grunnable, Gwaiting, ...
}

P (Processor) — логический процессор, владеет локальной очередью горутин:

type p struct {
    id          int32
    status      uint32  // Pidle, Prunning, Psyscall, ...
    m           *m      // привязанный M
    runqhead    uint32  // голова локальной очереди
    runqtail    uint32  // хвост локальной очереди
    runq        [256]guintptr // кольцевая очередь (до 256 горутин)
    runnext     guintptr // следующая горутина для приоритетного выполнения
    // ...
}

Количество P определяется переменной GOMAXPROCS (по умолчанию — количество ядер CPU).

M (Machine) — поток ОС, выполняющий горутины:

type m struct {
    g0      *g    // специальная горутина для планировщика
    curg    *g    // текущая выполняемая горутина
    p       puintptr // привязанный P
    nextp   puintptr // P для следующей привязки
    // ...
}

3. Принцип работы

┌─────────────────────────────────────────────────┐
│                   Global Run Queue               │
│              (глобальная очередь G)              │
└──────────┬──────────┬──────────┬────────────────┘
           │          │          │
     ┌─────▼──┐ ┌─────▼──┐ ┌─────▼──┐
     │   P0   │ │   P1   │ │   P2   │  ...  (GOMAXPROCS штук)
     │ runq   │ │ runq   │ │ runq   │
     │ [G,G,G]│ │ [G,G]  │ │ [G,G,G]│
     └───┬────┘ └───┬────┘ └───┬────┘
         │          │          │
     ┌───▼──┐   ┌───▼──┐   ┌───▼──┐
     │  M0  │   │  M1  │   │  M2  │   ...  (потоки ОС)
     └──────┘   └──────┘   └──────┘

Каждый M привязан к одному P, который имеет локальную очередь горутин. M выполняет горутины из очереди своего P.

4. Work Stealing

Когда у P заканчиваются горутины в локальной очереди, он не простаивает, а «ворует» работу у других P:

// runtime/proc.go (упрощённо)
func findrunnable() (gp *g, inheritTime bool) {
    // 1. Проверяем локальную очередь
    if gp := runqget(_p_); gp != nil {
        return gp, false
    }

    // 2. Проверяем глобальную очередь
    if gp := globrunqget(_p_, 0); gp != nil {
        return gp, false
    }

    // 3. Work stealing: пытаемся украсть у других P
    for i := 0; i < 4; i++ { // количество попыток
        for enum := stealOrder.start(fastrand()); !enum.done(); enum.next() {
            if gp := runqsteal(_p_, allp[enum.position()], stealRunNextG); gp != nil {
                return gp, true
            }
        }
    }

    // 4. Если ничего не нашли — блокируемся
    // ...
}

Алгоритм work stealing:

P проверяет свою локальную очередь.
Если пуста — проверяет глобальную очередь.
Если и там пусто — случайным образом выбирает другой P и «ворует» половину его очереди (из хвоста, чтобы уменьшить contention).
Если ничего не найдено — M блокируется на событие (новая горутина, завершение системного вызова).

Это обеспечивает балансировку нагрузки без центрального координатора.

5. Обработка блокирующих операций

А. Блокирующие системные вызовы (file I/O, sleep):

Когда горутина выполняет блокирующий syscall, M блокируется в ядре. Чтобы не терять P, планировщик «отцепляет» P от M:

// Горутина вызывает блокирующий syscall
// 1. M переходит в состояние Psyscall
// 2. P привязывается к новому M (или создаётся новый M)
// 3. Когда syscall завершится — горутина вернётся в глобальную очередь

Б. Неблокирующие операции (network I/O):

Сетевые операции обрабатываются через netpoller (epoll/kqueue/IOCP). Горутина блокируется на сетевом вызове, но M не блокируется — горутина помещается в очередь netpoller'а, а M продолжает выполнять другие горутины. Когда данные готовы, горутина возвращается в очередь.

В. Каналы и мьютексы:

Блокировка на канале или мьютексе не блокирует M — горутина переходит в состояние Gwaiting, а M продолжает выполнять другие горутины из очереди P.

6. Системные вызовы и рост числа M

При блокирующих syscall'ах Go может создавать дополнительные потоки ОС. Ограничение — GOMAXPROCS для P, но M может быть больше (до 10000 по умолчанию, настраивается через runtime/debug.SetMaxThreads).

7. Итого

Горутины — легковесные потоки с динамическим стеком, управляемые рантаймом Go.
GPM-модель: G (горутины) выполняются на M (потоки ОС) через P (логические процессоры).
Work stealing — механизм балансировки: пустой P ворует горутины из очередей других P.
Блокирующие syscall'ы обрабатываются через отцепление P от M; сетевые — через netpoller.
Это позволяет Go эффективно использовать ресурсы CPU при большом количестве конкурентных задач.

Вопрос 12. Какие три кита мониторинга сервиса (метрики, логи, трассировка), какие инструменты используются и какие метрики стоит собирать?

Таймкод: 01:10:59

Ответ собеседника: Правильный. Названы метрики (RPS, процент ошибок), логи и трассировка как три кита мониторинга; упомянуты Prometheus и Grafana; отмечена важность системных метрик: память, горутины, файловые дескрипторы.

Правильный ответ:

1. Три кита наблюдаемости (Observability)

Наблюдаемость сервиса строится на трёх столпах, каждый из которых отвечает на свой вопрос:

А. Метрики (Metrics) — «Что происходит?»

Числовые показатели, агрегированные во времени. Позволяют отслеживать тренды, настраивать алерты, визуализировать состояние системы.

Б. Логи (Logs) — «Почему это произошло?»

Дискретные записи событий с контекстом. Используются для отладки конкретных инцидентов и расследования причин.

В. Трассировка (Traces) — «Где именно проблема?»

Отслеживание жизненного цикла запроса через все сервисы системы. Показывает путь запроса и время выполнения каждого этапа.

2. Инструменты

Метрики:

Prometheus — сбор, хранение и запрос метрик (pull-модель)
Grafana — визуализация и дашборды
VictoriaMetrics — альтернатива Prometheus с лучшей производительностью при больших объёмах
OpenTelemetry Collector — агрегация и экспорт метрик

Логи:

ELK Stack (Elasticsearch, Logstash, Kibana) — классический стек
Loki (Grafana Labs) — легковесная альтернатива, индексирует только лейблы
Fluentd / Fluent Bit — сбор и маршрутизация логов

Трассировка:

Jaeger — распределённая трассировка
Zipkin — аналог Jaeger
Tempo (Grafana Labs) — интеграция с Grafana
OpenTelemetry — стандарт инструментирования

3. Рекомендуемые метрики для Go-сервиса

А. RED-метрики (для сервисов, обрабатывающих запросы):

Метрика	Описание	Пример
Rate	Количество запросов в секунду	`http_requests_total`
Errors	Процент ошибок	`http_requests_total{status=~"5.."}`
Duration	Время обработки запроса	`http_request_duration_seconds`

Б. Метрики приложения в Go:

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promauto"
)

var (
    httpRequestsTotal = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "endpoint", "status"},
    )

    httpRequestDuration = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "HTTP request duration in seconds",
            Buckets: prometheus.DefBuckets,
        },
        []string{"method", "endpoint"},
    )

    dbQueryDuration = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "db_query_duration_seconds",
            Help:    "Database query duration",
            Buckets: []float64{.001, .005, .01, .05, .1, .5, 1, 5},
        },
        []string{"query_type"},
    )
)

В. Специфичные метрики Go (runtime):

import (
    "github.com/prometheus/client_golang/prometheus"
    "runtime"
)

func recordRuntimeMetrics() {
    go func() {
        for {
            // Количество горутин
            goroutines.Set(float64(runtime.NumGoroutine()))

            // Использование памяти
            var memStats runtime.MemStats
            runtime.ReadMemStats(&memStats)
            heapAlloc.Set(float64(memStats.HeapAlloc))
            heapInuse.Set(float64(memStats.HeapInuse))
            gcPauseNs.Set(float64(memStats.PauseNs[(memStats.NumGC+255)%256]))

            // Системная памятом
            sysMemory.Set(float64(memStats.Sys))

            time.Sleep(10 * time.Second)
        }
    }()
}

Г. USE-метрики (для ресурсов):

Ресурс	Utilization	Saturation	Errors
CPU	Процент использования	Длина очереди	—
Память	Процент использования	OOM events	OOM kills
Диск	Процент I/O	Длина очереди I/O	Ошибки чтения/записи
Сеть	Пропускная способность	Потеря пакетов	Ошибки соединений
Файловые дескрипторы	Процент использования	—	Too many open files

Д. Бизнес-метрики:

Зависят от домена, но примеры:

Количество заказов в минуту
Время обработки заказа
Конверсия воронки
Размер очереди задач

4. Структурированные логи

import "go.uber.org/zap"

logger, _ := zap.NewProduction()
defer logger.Sync()

logger.Info("request processed",
    zap.String("method", "GET"),
    zap.String("path", "/api/users"),
    zap.Int("status", 200),
    zap.Duration("duration", 150*time.Millisecond),
    zap.String("trace_id", traceID),
    zap.String("user_id", userID),
)

Ключевые принципы:

Структурированный формат (JSON)
Корреляция через trace_id
Уровни: DEBUG, INFO, WARN, ERROR, FATAL
Не логировать чувствительные данные

5. Распределённая трассировка

import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/trace"
)

func HandleRequest(ctx context.Context, req *Request) error {
    tracer := otel.Tracer("my-service")

    // Создаём span
    ctx, span := tracer.Start(ctx, "HandleRequest",
        trace.WithAttributes(attribute.String("user.id", req.UserID)),
    )
    defer span.End()

    // Дочерний span
    ctx, childSpan := tracer.Start(ctx, "FetchUserData")
    user, err := fetchUser(ctx, req.UserID)
    if err != nil {
        childSpan.RecordError(err)
        childSpan.SetStatus(codes.Error, "fetch failed")
    }
    childSpan.End()

    return nil
}

6. Итого

Три кита: метрики (что происходит), логи (почему), трассировка (где).
Инструменты: Prometheus + Grafana, ELK/Loki, Jaeger/Tempo.
Метрики: RED (Rate, Errors, Duration), USE (Utilization, Saturation, Errors), Go runtime (goroutines, heap, GC).
Логи: структурированные, с корреляцией через trace_id.
Трассировка: OpenTelemetry как стандарт инструментирования.

Вопрос 13. Что делать, если запросы к базе данных начали тормозить: какие инструменты диагностики использовать и какие причины могут быть?

Таймкод: 01:14:04

Ответ собеседника: Правильный. Использовать EXPLAIN ANALYZE для анализа плана запроса, проверить индексы (B-tree, hash, GIN, GiST), рассмотреть кэширование и шардирование.

Правильный ответ:

1. Системный подход к диагностике

При замедлении запросов к БД важно действовать методично: сначала собрать данные, затем анализировать, потом оптимизировать.

2. Инструменты диагностики

А. EXPLAIN / EXPLAIN ANALYZE (PostgreSQL):

-- План выполнения без реального запуска
EXPLAIN SELECT * FROM orders WHERE user_id = 12345;

-- План с реальным выполнением и статистикой
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 12345;

Ключевые показатели в выводе:

Seq Scan — полное сканирование таблицы (плохо для больших таблиц)
Index Scan / Index Only Scan — использование индекса (хорошо)
Nested Loop / Hash Join / Merge Join — тип соединения
actual time — реальное время выполнения
rows vs actual rows — оценка vs реальность (большое расхождение означает плохую статистику)

Б. pg_stat_statements — статистика по всем запросам:

-- Включение расширения
CREATE EXTENSION pg_stat_statements;

-- Самые медленные запросы по среднему времени
SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

-- Запросы с наибольшим суммарным временем
SELECT query, calls, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

В. Мониторинг блокировок:

-- Активные блокировки
SELECT blocked_locks.pid     AS blocked_pid,
       blocked_activity.query AS blocked_query,
       blocking_locks.pid     AS blocking_pid,
       blocking_activity.query AS blocking_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
    AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
    AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
    AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
    AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
    AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
    AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
    AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
    AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
    AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
    AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

Г. Slow query log:

-- postgresql.conf
log_min_duration_statement = 100  -- логировать запросы медленнее 100 мс

Д. pg_stat_user_tables — статистика по таблицам:

-- Таблицы с наибольшим количеством последовательных сканирований
SELECT schemaname, relname, seq_scan, seq_tup_read,
       idx_scan, idx_tup_fetch
FROM pg_stat_user_tables
ORDER BY seq_scan DESC;

-- Таблицы с «мёртвыми» кортежами (нужен VACUUM)
SELECT relname, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / nullif(n_live_tup, 0) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
WHERE n_dead_tup > 1000
ORDER BY n_dead_tup DESC;

3. Основные причины замедления

А. Отсутствие или неэффективность индексов:

-- Создание B-tree индекса (основной тип)
CREATE INDEX idx_orders_user_id ON orders(user_id);

-- Составной индекс
CREATE INDEX idx_orders_user_status ON orders(user_id, status);

-- Частичный индекс (для часто запрашиваемого подмножества)
CREATE INDEX idx_orders_active ON orders(created_at) WHERE status = 'active';

-- GIN индекс для полнотекстового поиска или JSONB
CREATE INDEX idx_products_metadata ON products USING gin(metadata);

-- GiST индекс для геоданных
CREATE INDEX idx_locations_coords ON locations USING gist(coordinates);

Б. Устаревшая статистика:

-- Обновление статистики
ANALYZE orders;

-- Или для конкретного столбца
ANALYZE orders(user_id, status);

В. Блокировки и конкуренция:

Долгие транзакции удерживают блокировки, блокируя другие запросы:

Искать долгие транзакции через pg_stat_activity
Убедиться, что транзакции коммитятся вовремя
Использовать соответствующий уровень изоляции

Г. «Bloated» таблицы и индексы:

Накопление «мёртвых» кортежей из-за отсутствия VACUUM:

VACUUM FULL orders; -- блокирует таблицу!
-- Или лучше для production:
REINDEX INDEX CONCURRENTLY idx_orders_user_id;

Д. N+1 проблема в приложении:

// Плохо: N+1 запросов
users := getUsers()
for _, user := range users {
    orders := getOrdersByUserID(user.ID) // отдельный запрос для каждого пользователя
}

// Хорошо: один запрос с JOIN
SELECT u.*, o.*
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2024-01-01';

Е. Неоптимальный план запроса:

Неправильный JOIN (Nested Loop вместо Hash Join для больших таблиц)
Отсутствие условия по индексированному столбцу
Использование функций на индексированных столбцах: WHERE lower(email) = 'test@example.com' не использует обычный индекс (нужен функциональный индекс)

Ж. Недостаток ресурсов:

Мало RAM — данные не помещаются в кэш (shared_buffers)
Медленные диски
Высокая нагрузка CPU

4. Стратегии оптимизации

А. Оптимизация запросов:

Переписать запрос, убрать подзапросы где возможно
Использовать EXISTS вместо IN для подзапросов
Добавить LIMIT где применимо
Использовать CTE (Common Table Expressions) для сложных запросов

Б. Кэширование:

Прикладное кэширование (Redis, Memcached)
Материализованные представления для тяжёлых агрегаций

CREATE MATERIALIZED VIEW daily_stats AS
SELECT date_trunc('day', created_at) AS day,
       count(*) AS order_count,
       sum(amount) AS total_amount
FROM orders
GROUP BY 1;

-- Обновление кэша
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats;

В. Партиционирование:

-- Партиционирование по дате
CREATE TABLE orders (
    id bigserial,
    user_id int,
    created_at timestamptz,
    amount decimal
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2024_q1 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-04-01');

Г. Шардирование — горизонтальное разделение данных между серверами (Citus, ручная реализация).

5. Итого

Диагностика: EXPLAIN ANALYZE, pg_stat_statensions, мониторинг блокировок, slow query log.
Причины: отсутствие индексов, устаревшая статистика, блокировки, N+1, bloated таблицы, нехватка ресурсов.
Решения: индексы, ANALYZE, оптимизация запросов, кэширование, партиционирование, шардирование.
Важно: всегда измерять до и после оптимизации, чтобы убедиться в эффекте.

Вопрос 14. Что такое репликация в базах данных, как она работает, что такое мастер-реплика и что происходит при падении мастера?

Таймкод: 01:20:53

Ответ собеседника: Неполный. Репликация — несколько инстансов БД с одинаковым состоянием; писать можно только в мастер; при падении мастера происходит leader election. Не раскрыты механизмы репликации (streaming, logical), лаг репликации, консенсус-протоколы.

Правильный ответ:

1. Определение и назначение

Репликация — механизм синхронизации данных между несколькими серверами БД. Основные цели:

Отказоустойчивость — при падении одного сервера другие продолжают работу.
Масштабирование чтения — распределение read-запросов между репликами.
Географическое распределение — размещение данных ближе к пользователям.
Резервное копирование — реплика как живая копия данных.

2. Архитектура Master-Replica (Primary-Replica)

        ┌──────────────┐
        │    Master    │
        │  (read/write)│
        └──────┬───────┘
               │ WAL / binlog
       ┌───────┼───────┐
       │       │       │
  ┌────▼──┐┌───▼───┐┌──▼────┐
  │Replica││Replica││Replica│
  │(read) ││(read) ││(read) │
  └───────┘└───────┘└───────┘

Master (Primary) — принимает операции записи (INSERT, UPDATE, DELETE) и чтение.
Replica (Standby) — принимает только операции чтения, получает изменения от мастера.

3. Механизмы репликации

А. Streaming Replication (физическая, PostgreSQL):

Мастер отправляет записи из WAL (Write-Ahead Log) реплике в реальном времени:

Master:  INSERT INTO users VALUES (1, 'Alice')
         → WAL record 0/1A000000
         → send to replica

Replica: receive WAL record 0/1A000000
         → replay: INSERT INTO users VALUES (1, 'Alice')

Настройка на мастере:

# postgresql.conf
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB

На реплике:

# recovery.conf или standby.signal
primary_conninfo = 'host=master port=5432 user=replicator password=secret'

Б. Logical Replication (логическая, PostgreSQL 10+):

Репликация на уровне логических изменений (строк), а не WAL-записей. Позволяет:

Реплицировать отдельные таблицы
Преобразовывать данные при репликации
Реплицировать между разными версиями PostgreSQL

-- На мастере: создание публикации
CREATE PUBLICATION my_pub FOR TABLE users, orders;

-- На реплике: создание подписки
CREATE SUBSCRIPTION my_sub
    CONNECTION 'host=master dbname=mydb user=replicator'
    PUBLICATION my_pub;

В. Бинарный лог репликации (MySQL):

Master:  Binary Log (binlog)
         ├── Position 100: INSERT INTO users ...
         ├── Position 200: UPDATE orders ...
         └── Position 300: DELETE FROM ...

Replica: I/O Thread → читает binlog → Relay Log
         SQL Thread → применяет изменения из Relay Log

4. Режимы синхронизации

А. Синхронная репликация:

Мастер ждёт подтверждения от реплики перед коммитом транзакции:

-- PostgreSQL
synchronous_standby_names = 'FIRST 1 (replica1, replica2)'

Плюсы: гарантия отсутствия потери данных. Минусы: увеличение латентности записи.

Б. Асинхронная репликация:

Мастер не ждёт подтверждения — коммит происходит сразу.

Плюсы: высокая производительность записи. Минусы: возможна потеря последних транзакций при падении мастера.

5. Лаг репликации (Replication Lag)

Время между применением изменения на мастере и на реплике:

-- PostgreSQL: проверка лага
SELECT pid, state, sent_lsn, write_lsn, flush_lsn, replay_lsn,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replication_lag
FROM pg_stat_replication;

Причины лага:

Высокая нагрузка на реплику
Медленные диски на реплике
Большие транзакции
Отсутствие индексов на реплике (для logical replication)
Сетевые проблемы

6. Что происходит при падении мастера

А. Failover (автоматический переход):

Процесс автоматического назначения новой мастера из реплик:

Master DOWN → обнаружение отказа → leader election → промоут реплики

Инструменты:

Patroni — автоматический failover для PostgreSQL
pg_auto_failover — автоматическое управление репликацией
Orchestrator — для MySQL

Б. Leader Election (выборы нового мастера):

Для выбора нового мастера используются консенсус-протоколы:

Raft (используется в Patroni с etcd/ZooKeeper):

Все узлы делятся на Leader, Follower, Candidate
Для принятия решения нужно большинство голосов (quorum)
Гарантирует, что в каждый момент времени только один лидер

Master DOWN
    ↓
Followers обнаруживают отсутствие heartbeat
    ↓
Один из Followers становится Candidate
    ↓
Candidate запрашивает голоса у других узлов
    ↓
Получает большинство голосов → становится новым Leader

В. Потеря данных при failover:

При асинхронной репликации возможна потеря последних транзакций:

Master: COMMIT T1 → отправил WAL → CRASH (WAL не дошёл до реплики)
Replica: не имеет T1 → становится новым мастером → T1 потеряна

Для минимизации рисков:

Использовать синхронную репликацию для критичных данных
Настроить wal_keep_size для хранения достаточного количества WAL
Использовать WAL archiving для восстановления

7. Multi-Master репликация

Некоторые системы поддерживают запись на несколько узлов:

PostgreSQL BDR (Bi-Directional Replication)
MySQL Group Replication
CockroachDB (встроенная репликация через Raft)

Проблемы multi-master:

Конфликты при одновременной записи в одну запись
Необходимость разрешения конфликтов
Более сложная настройка и администрирование

8. Итого

Репликация — синхронизация данных между серверами для отказоустойчивости и масштабирования.
Master-Replica: запись на мастер, чтение с реплик.
Механизмы: streaming (WAL), logical (логический), binlog (MySQL).
Синхронная vs асинхронная репликация — компромисс между консистентностью и производительностью.
При падении мастера — failover через leader election (Raft/Paxos).
Инструменты: Patroni, pg_auto_failover, Orchestrator.
Важно мониторить лаг репликации и тестировать failover.

Вопрос 15. Что такое шардирование, какие стратегии шардирования существуют и что такое консистентное хеширование?

Таймкод: 01:24:46

Ответ собеседника: Неполный. Шардирование — разбиение базы на части; упомянуты географическое шардирование и шардирование по ID; предложена хеш-функция. Не раскрыто консистентное хеширование и его преимущества.

Правильный ответ:

1. Определение и назначение

Шардирование (sharding) — горизонтальное разделение данных между несколькими серверами (шардами). Каждый шард содержит подмножество данных и работает независимо.

┌─────────────────────────────────────────┐
│           Без шардирования               │
│  ┌───────────────────────────────────┐  │
│  │        Один сервер БД             │  │
│  │  Все данные, все запросы          │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│           С шардированием                │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │ Shard 1 │ │ Shard 2 │ │ Shard 3 │   │
│  │ A-M     │ │ N-S     │ │ T-Z     │   │
│  └─────────┘ └─────────┘ └─────────┘   │
└─────────────────────────────────────────┘

Шардирование применяется, когда:

Один сервер не справляется с объёмом данных или нагрузкой
Требуется горизонтальное масштабирование
Необходимо географическое распределение данных

2. Стратегии шардирования

А. Хеш-шардирование (Hash-based):

Данные распределяются по шардам на основе хеша от ключа:

func getShardID(userID int, numShards int) int {
    return userID % numShards
}

// Или с хеш-функцией
func getShardIDHash(userID int, numShards int) int {
    h := fnv.New32a()
    h.Write([]byte(strconv.Itoa(userID)))
    return int(h.Sum32()) % numShards
}

Плюсы: равномерное распределение данных. Минусы: при изменении количества шардов нужно перемещать большую часть данных.

Б. Range-шардирование (по диапазонам):

Данные разделяются по диапазонам значений ключа:

Shard 1: user_id 1 - 1,000,000
Shard 2: user_id 1,000,001 - 2,000,000
Shard 3: user_id 2,000,001 - 3,000,000

Плюсы: простые range-запросы, предсказуемое распределение. Минусы: неравномерная нагрузка (hot spots), необходимость ребалансировки.

В. Географическое шардирование:

Данные распределяются по географическому признаку:

Shard EU: пользователи из Европы
Shard US: пользователи из Америки
Shard ASIA: пользователи из Азии

Плюсы: низкая латентность для пользователей, соответствие требованиям локализации данных (GDPR). Минусы: неравномерное распределение, сложность кросс-региональных запросов.

Г. Шардирование по типу данных (entity-based):

Разные типы данных хранятся на разных шардах:

Shard users: таблица users
Shard orders: таблица orders
Shard products: таблица products

Плюсы: изоляция нагрузки, независимое масштабирование. Минусы: сложность JOIN-запросов между шардами.

3. Консистентное хеширование (Consistent Hashing)

Простое хеш-шардирование (hash(key) % N) имеет фундаментальную проблему: при изменении количества шардов (добавлении или удалении) почти все ключи меняют свой шард, что требует массового перемещения данных.

Консистентное хеширование решает эту проблему: при изменении количества шардов перемещается только K/N ключей (где K — общее количество ключей, N — количество шардов).

Принцип работы:

Хеш-функция отображает и ключи, и шарды на кольцо (hash ring) — диапазон значений хеша (например, 0 до 2^32-1).
Каждый ключ назначается ближайшему шарду по часовой стрелке на кольце.
При добавлении шарда — перемещаются только ключи между новым шардом и его предшественником.
При удалении шарда — его ключи переходят к следующему шарду по кольцу.

         0 / 2^32
          │
    Shard C
          │
   ───────┼───────
   │      │      │
   │  Shard A    │
   │      │      │
   ───────┼───────
          │
    Shard B
          │
        2^32/2

Виртуальные узлы (vnodes):

Для равномерного распределения каждый физический шард представляется несколькими виртуальными узлами на кольце:

type ConsistentHash struct {
    ring       map[uint32]string // hash → node
    sortedKeys []uint32          // отсортированные хеши
    replicas   int               // количество vnode на узел
}

func New(replicas int) *ConsistentHash {
    return &ConsistentHash{
        ring:     make(map[uint32]string),
        replicas: replicas,
    }
}

func (ch *ConsistentHash) AddNode(node string) {
    for i := 0; i < ch.replicas; i++ {
        key := ch.hash(fmt.Sprintf("%s:%d", node, i))
        ch.ring[key] = node
        ch.sortedKeys = append(ch.sortedKeys, key)
    }
    sort.Slice(ch.sortedKeys, func(i, j int) bool {
        return ch.sortedKeys[i] < ch.sortedKeys[j]
    })
}

func (ch *ConsistentHash) GetNode(key string) string {
    if len(ch.ring) == 0 {
        return ""
    }
    hash := ch.hash(key)
    // Находим первый узел с хешем >= hash ключа
    idx := sort.Search(len(ch.sortedKeys), func(i int) bool {
        return ch.sortedKeys[i] >= hash
    })
    if idx == len(ch.sortedKeys) {
        idx = 0 // кольцо — заворачиваемся к началу
    }
    return ch.ring[ch.sortedKeys[idx]]
}

func (ch *ConsistentHash) hash(key string) uint32 {
    h := fnv.New32a()
    h.Write([]byte(key))
    return h.Sum32()
}

Пример использования:

ch := New(150) // 150 vnode на каждый физический шард
ch.AddNode("shard-1")
ch.AddNode("shard-2")
ch.AddNode("shard-3")

// Определяем шард для ключа
shard := ch.GetNode("user:12345") // "shard-2"

// Добавляем новый шард — перемещается только ~1/4 ключей
ch.AddNode("shard-4")

4. Сравнение стратегий

Стратегия	Равномерность	Масштабирование	Range-запросы	Сложность
Hash	Высокая	Плохое (без consistent hashing)	Нет	Низкая
Consistent Hash	Высокая	Хорошее	Нет	Средняя
Range	Низкая	Среднее	Да	Средняя
Geographic	Низкая	Среднее	Зависит	Высокая

5. Проблемы шардирования

Кросс-шардные запросы: JOIN и агрегация между шардами сложны и медленны.
Ребалансировка: Добавление/удаление шардов требует перемещения данных.
Транзакции: Распределённые транзакции сложны в реализации.
Выбор ключа шардирования: Неправильный выбор приводит к hot spots.

6. Итого

Шардирование — горизонтальное разделение данных между серверами.
Стратегии: hash, range, geographic, entity-based.
Консистентное хеширование минимизирует перемещение данных при изменении количества шардов.
Виртуальные узлы (vnodes) обеспечивают равномерное распределение.
Шардирование усложняет кросс-шардные запросы и транзакции — это архитектурное решение с серьёзными компромиссами.

Вопрос 16. Почему простое хеширование по модулю плохо работает при изменении количества шардов и что такое консистентное хеширование?

Таймкод: 01:44:19

Ответ собеседника: Правильный. При добавлении/удалении шарда простое хеширование по модулю приводит к инвалидации практически всех ключей — все данные нужно перераспределять заново. Консистентное хеширование — метод, при котором при изменении количества шардов перемещается только часть данных, а не все.

Правильный ответ:

1. Проблема простого хеширования по модулю

При использовании shardID = hash(key) % N каждый шард отвечает за диапазон значений остатка. При изменении N (добавлении или удалении шарда) практически все ключи получают новый шард:

// Пример: 3 шарда
key := "user:12345"
hash := 1234567890

shard3 := hash % 3 // = 0 → Shard 0

// Добавляем 4-й шард
shard4 := hash % 4 // = 2 → Shard 2 (!)

Математически, при изменении N на N±1, доля ключей, которые нужно переместить, составляет примерно 1/N. Для 100 шардов это ~1%, но при малом количестве шардов доля значительно больше.

2. Консистентное хеширование — решение

Консистентное хеширование решает эту проблему, используя кольцевую структуру:

А. Принцип:

Хеш-функция отображает и ключи, и шарды на кольцо (0 до 2^32-1).
Каждый ключ назначается ближайшему шарду по часовой стрелке.
При добавлении шарда — перемещаются только ключи между новым шардом и его предшественником.
При удалении шарда — его ключи переходят к следующему шарду.

Б. Реализация:

package consistenthash

import (
    "hash/fnv"
    "sort"
    "strconv"
)

type Hash func(data []byte) uint32

type ConsistentHash struct {
    hash     Hash
    ring     map[uint32]string
    keys     []uint32 // отсортированные хеши на кольце
    replicas int
}

func New(replicas int, fn Hash) *ConsistentHash {
    ch := &ConsistentHash{
        replicas: replicas,
        hash:     fn,
        ring:     make(map[uint32]string),
    }
    if ch.hash == nil {
        ch.hash = func(data []byte) uint32 {
            h := fnv.New32a()
            h.Write(data)
            return h.Sum32()
        }
    }
    return ch
}

func (ch *ConsistentHash) AddNode(node string) {
    for i := 0; i < ch.replicas; i++ {
        virtualKey := strconv.Itoa(i) + ":" + node
        hash := ch.hash([]byte(virtualKey))
        ch.ring[hash] = node
        ch.keys = append(ch.keys, hash)
    }
    sort.Slice(ch.keys, func(i, j int) bool {
        return ch.keys[i] < ch.keys[j]
    })
}

func (ch *ConsistentHash) RemoveNode(node string) {
    for i := 0; i < ch.replicas; i++ {
        virtualKey := strconv.Itoa(i) + ":" + node
        hash := ch.hash([]byte(virtualKey))
        delete(ch.ring, hash)
    }
    // Пересортировка
    ch.keys = nil
    for k := range ch.ring {
        ch.keys = append(ch.keys, k)
    }
    sort.Slice(ch.keys, func(i, j int) bool {
        return ch.keys[i] < ch.keys[j]
    })
}

func (ch *ConsistentHash) GetNode(key string) string {
    if len(ch.ring) == 0 {
        return ""
    }
    hash := ch.hash([]byte(key))
    // Бинарный поиск первого ключа >= hash
    idx := sort.Search(len(ch.keys), func(i int) bool {
        return ch.keys[i] >= hash
    })
    if idx == len(ch.keys) {
        idx = 0 // кольцо — заворачиваемся к началу
    }
    return ch.ring[ch.keys[idx]]
}

В. Пример использования:

func main() {
    ch := New(150, nil) // 150 vnode на узел
    
    ch.AddNode("shard-1:5432")
    ch.AddNode("shard-2:5432")
    ch.AddNode("shard-3:5432")
    
    keys := []string{"user:1", "user:2", "user:3", "user:4", "user:5"}
    
    fmt.Println("=== 3 шарда ===")
    for _, key := range keys {
        fmt.Printf("%s → %s\n", key, ch.GetNode(key))
    }
    
    // Добавляем 4-й шард
    ch.AddNode("shard-4:5432")
    
    fmt.Println("\n=== 4 шарда ===")
    moved := 0
    for _, key := range keys {
        fmt.Printf("%s → %s\n", key, ch.GetNode(key))
    }
    
    // Проверяем, сколько ключей переместилось
    ch3 := New(150, nil)
    ch3.AddNode("shard-1:5432")
    ch3.AddNode("shard-2:5432")
    ch3.AddNode("shard-3:5432")
    
    for _, key := range keys {
        if ch3.GetNode(key) != ch.GetNode(key) {
            moved++
        }
    }
    fmt.Printf("\nПеремещено ключей: %d из %d (%.0f%%)\n", 
        moved, len(keys), float64(moved)/float64(len(keys))*100)
}

3. Виртуальные узлы (vnodes)

Без vnodes распределение может быть неравномерным. Каждый физический узел представляется несколькими точками на кольце:

Без vnodes:         С vnodes (150 на узел):
                     
  Shard A              A1, A2, ..., A150
    ○                  ○ ○ ○ ○ ○ ○ ○ ○
   / \                ○ ○ ○ ○ ○ ○ ○ ○ ○
  ○   ○              ○ ○ ○ ○ ○ ○ ○ ○ ○
 Shard B Shard C     B1...B150  C1...C150

Это обеспечивает:

Более равномерное распределение нагрузки
Учёт разной мощности узлов (больше vnodes для мощных серверов)

4. Итого

Простое хеширование по модулю требует перемещения ~N/(N+1) данных при изменении количества шардов.
Консистентное хеширование перемещает только ~1/N данных.
Виртуальные узлы обеспечивают равномерное распределение.
Консистентное хеширование используется в DynamoDB, Cassandra, Discord, Akamai CDN и других системах.

Вопрос 17. Нужно ли разработчику знать паттерны проектирования микросервисов (transactional outbox, saga и т.д.)?

Таймкод: 01:55:22

Ответ собеседника: Правильный. Понять смысл паттернов — плюс; глубокое знание реализации (двухфазный коммит и т.д.) — тема более высокого уровня; рекомендованы видео с разбором этих паттернов.

Правильный ответ:

1. Уровни знания паттернов

Знание паттернов микросервисов полезно на любом уровне, но глубина понимания различается:

Junior:

Знать о существовании проблем (распределённые транзакции, eventual consistency)
Понимать, почему простой двухфазный коммит не всегда работает

Middle:

Знать основные паттерны и их назначение
Понимать trade-offs каждого паттерна
Уметь реализовать простые варианты

Senior:

Глубокое понимание реализации и ограничений
Способность выбрать правильный паттерн для конкретного случая
Понимание того, когда паттерн не нужен

2. Ключевые паттерны, которые стоит знать

А. Transactional Outbox:

Проблема: как атомарно обновить БД и опубликовать событие в брокер сообщений?

-- Вместо: UPDATE orders + publish event (не атомарно)
-- Используем: UPDATE orders + INSERT INTO outbox (атомарно)

BEGIN;
    UPDATE orders SET status = 'confirmed' WHERE id = 123;
    INSERT INTO outbox (aggregate_id, event_type, payload)
    VALUES (123, 'OrderConfirmed', '{"order_id": 123}');
COMMIT;

Отдельный процесс (relay) читает outbox и публикует события в Kafka/RabbitMQ:

type OutboxRelay struct {
    db     *sql.DB
    kafka  *kafka.Producer
}

func (r *OutboxRelay) Run(ctx context.Context) {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()
    
    for {
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            r.processBatch()
        }
    }
}

func (r *OutboxRelay) processBatch() {
    rows, _ := r.db.Query(`
        SELECT id, aggregate_id, event_type, payload 
        FROM outbox 
        ORDER BY created_at 
        LIMIT 100
    `)
    defer rows.Close()
    
    for rows.Next() {
        var event OutboxEvent
        rows.Scan(&event.ID, &event.AggregateID, &event.Type, &event.Payload)
        
        // Публикуем в Kafka
        r.kafka.Produce(event.Topic(), event.Payload)
        
        // Помечаем как обработанное
        r.db.Exec("DELETE FROM outbox WHERE id = $1", event.ID)
    }
}

Б. Saga Pattern:

Для распределённых транзакций через несколько сервисов. Два варианта:

Хореография (Choreography): Каждый сервис публикует события, другие реагируют:

Order Service → OrderCreated → Payment Service → PaymentProcessed → Shipping Service
                  ↓                                         ↓
           если ошибка:                           если ошибка:
           OrderCancelled                         PaymentRefunded

Оркестрация (Orchestration): Центральный оркестратор управляет потоком:

type OrderSaga struct {
    steps []SagaStep
}

type SagaStep struct {
    Action      func() error
    Compensation func() error
}

func (s *OrderSaga) Execute() error {
    for i, step := range s.steps {
        if err := step.Action(); err != nil {
            // Компенсируем все предыдущие шаги
            for j := i - 1; j >= 0; j-- {
                s.steps[j].Compensation()
            }
            return err
        }
    }
    return nil
}

// Использование
saga := OrderSaga{
    steps: []SagaStep{
        {
            Action:      func() error { return paymentService.Charge(100) },
            Compensation: func() error { return paymentService.Refund(100) },
        },
        {
            Action:      func() error { return shippingService.Ship(orderID) },
            Compensation: func() error { return shippingService.Cancel(orderID) },
        },
    },
}

C. Circuit Breaker:

Защита от каскадных отказов при вызове внешних сервисов:

type CircuitBreaker struct {
    failures    int
    threshold   int
    timeout     time.Duration
    lastFailure time.Time
    state       State // Closed, Open, HalfOpen
}

func (cb *CircuitBreaker) Call(fn func() error) error {
    if cb.state == Open {
        if time.Since(cb.lastFailure) > cb.timeout {
            cb.state = HalfOpen
        } else {
            return ErrCircuitOpen
        }
    }
    
    err := fn()
    if err != nil {
        cb.failures++
        cb.lastFailure = time.Now()
        if cb.failures >= cb.threshold {
            cb.state = Open
        }
        return err
    }
    
    cb.failures = 0
    cb.state = Closed
    return nil
}

D. Retry с exponential backoff:

func RetryWithBackoff(ctx context.Context, maxRetries int, fn func() error) error {
    var err error
    for i := 0; i < maxRetries; i++ {
        if err = fn(); err == nil {
            return nil
        }
        
        if !isRetryable(err) {
            return err
        }
        
        backoff := time.Duration(math.Pow(2, float64(i))) * time.Second
        backoff += time.Duration(rand.Int63n(int64(backoff))) // jitter
        
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-time.After(backoff):
        }
    }
    return err
}

3. Итого

Знание паттернов микросервисов — важный навык для любого уровня.
Middle-разработчику достаточно понимать назначение и базовую реализацию.
Ключевые паттерны: Transactional Outbox, Saga, Circuit Breaker, Retry.
Глубокое знание деталей реализации — область senior-уровня.
Понимание этих паттернов помогает принимать правильные архитектурные решения и общаться с коллегами на одном языке.

Вопрос 18. Насколько глубоко нужно знать Kubernetes разработчику?

Таймкод: 01:59:07

Ответ собеседника: Правильный. Достаточно понимать, что такое Kubernetes и зачем он нужен, иметь базовый опыт с деплойментами; глубокое знание — отдельная специализация; хороший продакшн-кластер — работа SRE/DevOps.

Правильный ответ:

1. Уровни знания Kubernetes

Junior — базовое понимание:

Что такое Pod, Deployment, Service
Как описать манифест для деплоя своего приложения
Основные команды kubectl: get, describe, logs, apply, delete

Middle — уверенное использование:

Написание манифестов (Deployment, Service, ConfigMap, Secret, Ingress)
Понимание жизненного цикла Pod'а
Работа с ресурсами (requests/limits)
Базовая отладка: просмотр логов, описание ресурсов, exec в контейнер
Понимание readiness/liveness probes
Работа с Helm-чартами (установка, базовая кастомизация values)

Senior — глубокое понимание:

Архитектура Kubernetes (control plane, kubelet, etcd)
Сетевая модель (CNI, Service mesh)
Безопасность (RBAC, NetworkPolicy, Pod Security)
Оптимизация ресурсов (HPA, VPA, cluster autoscaling)
Troubleshooting на уровне кластера
Проектирование инфраструктуры

2. Что должен знать разработчик (middle level)

А. Основные ресурсы:

# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3
        env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: my-app-config
              key: db-host
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-app-secrets
              key: db-password

Б. Базовые команды:

# Основные операции
kubectl get pods -n my-namespace
kubectl describe pod my-app-abc123
kubectl logs my-app-abc123 -f
kubectl exec -it my-app-abc123 -- /bin/sh

# Применение манифестов
kubectl apply -f deployment.yaml
kubectl apply -k ./kustomize/overlay/prod

# Отладка
kubectl get events --sort-by='.lastTimestamp'
kubectl port-forward pod/my-app-abc123 8080:8080
kubectl rollout status deployment/my-app
kubectl rollout undo deployment/my-app

В. Понимание probes:

// В приложении — endpoints для probes
http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    // Liveness: жив ли процесс?
    w.WriteHeader(http.StatusOK)
})

http.HandleFunc("/ready", func(w http.ResponseWriter, r *http.Request) {
    // Readiness: готов ли принимать трафик?
    if db.Ping() == nil && cache.IsConnected() {
        w.WriteHeader(http.StatusOK)
    } else {
        w.WriteHeader(http.StatusServiceUnavailable)
    }
})

3. Практические рекомендации

А. Использовать Helm для управления релизами:

# Установка
helm install my-app ./my-app-chart -f values-prod.yaml

# Обновление
helm upgrade my-app ./my-app-chart -f values-prod.yaml

# Просмотр истории
helm history my-app

Б. Структурировать манифесты с Kustomize:

base/
├── kustomization.yaml
├── deployment.yaml
├── service.yaml
└── configmap.yaml
overlays/
├── dev/
│   ├── kustomization.yaml
│   └── patch-replicas.yaml
└── prod/
    ├── kustomization.yaml
    └── patch-resources.yaml

В. Локальная разработка:

Minikube — локальный кластер Kubernetes
kind (Kubernetes in Docker) — лёгкий вариант для тестов
Docker Desktop — встроенный Kubernetes
Telepresence — локальная разработка с доступом к кластеру

4. Границы ответственности

Разработчику НЕ нужно:

Настраивать control plane
Управлять CNI-плагинами
Настраивать мониторинг кластера (это SRE/DevOps)
Управлять нодами и автоскейлингом

Разработчику НУЖНО:

Писать Dockerfile и манифесты для своего сервиса
Понимать, как его приложение ведёт себя в Kubernetes
Уметь отдебажить проблемы с деплоем
Сотрудничать с SRE по вопросам инфраструктуры

5. Итого

Middle-разработчику достаточно базового понимания Kubernetes и умения деплоить своё приложение.
Глубокое знание — отдельная специализация (SRE/DevOps).
Ключевые навыки: написание манифестов, понимание probes, базовая отладка.
Инструменты: kubectl, Helm, Kustomize, локальный кластер для разработки.
Важно понимать границы ответственности и уметь сотрудничать с инфраструктурной командой.

Вопрос 1. Как в Go передаются аргументы в функции — по значению или по ссылке?​

Вопрос 2. Что такое срез (slice) в Go, как он устроен и как передаётся в функцию?​

Вопрос 3. Что выведет код со срезами, демонстрирующий работу append, capacity и разделяемой памяти?​

Вопрос 4. Что такое map в Go, как работает эвакуация данных, как map передаётся в функцию, потокобезопасна ли она и гарантируется ли порядок итерации?​

Вопрос 5. Что такое интерфейс в Go, для чего он используется и как он устроен внутри?​

Вопрос 6. Что выведет код с интерфейсом, где метод возвращает nil-указатель на структуру, и при каких условиях возникнет nil pointer dereference?​

Вопрос 7. Что такое каналы в Go, какие бывают типы каналов и что роизойдёт при чтении/записи в неинициализированный (nil) канал?​

Вопрос 8. Что выведет код с горутинами, захватывающими переменную цикла, и какие проблемы есть в коде с мапой, каналом и группой горутин?​

Вопрос 9. Что такое context в Go, для чего он используется и что в него рекомендуется класть?​

Вопрос 10. Какие существуют способы синхронизации горутин в Go помимо каналов и зачем нужны мьютексы при наличии каналов?​

Вопрос 11. Чем горутины отличаются от потоков ОС, как устроен планировщик Go (GPM-модель) и что такое work stealing?​

Вопрос 12. Какие три кита мониторинга сервиса (метрики, логи, трассировка), какие инструменты используются и какие метрики стоит собирать?​

Вопрос 13. Что делать, если запросы к базе данных начали тормозить: какие инструменты диагностики использовать и какие причины могут быть?​

Вопрос 14. Что такое репликация в базах данных, как она работает, что такое мастер-реплика и что происходит при падении мастера?​

Вопрос 15. Что такое шардирование, какие стратегии шардирования существуют и что такое консистентное хеширование?​

Вопрос 16. Почему простое хеширование по модулю плохо работает при изменении количества шардов и что такое консистентное хеширование?​

Вопрос 17. Нужно ли разработчику знать паттерны проектирования микросервисов (transactional outbox, saga и т.д.)?​

Вопрос 18. Насколько глубоко нужно знать Kubernetes разработчику?​

Вопрос 1. Как в Go передаются аргументы в функции — по значению или по ссылке?

Вопрос 2. Что такое срез (slice) в Go, как он устроен и как передаётся в функцию?

Вопрос 3. Что выведет код со срезами, демонстрирующий работу append, capacity и разделяемой памяти?

Вопрос 4. Что такое map в Go, как работает эвакуация данных, как map передаётся в функцию, потокобезопасна ли она и гарантируется ли порядок итерации?

Вопрос 5. Что такое интерфейс в Go, для чего он используется и как он устроен внутри?

Вопрос 6. Что выведет код с интерфейсом, где метод возвращает nil-указатель на структуру, и при каких условиях возникнет nil pointer dereference?

Вопрос 7. Что такое каналы в Go, какие бывают типы каналов и что роизойдёт при чтении/записи в неинициализированный (nil) канал?

Вопрос 8. Что выведет код с горутинами, захватывающими переменную цикла, и какие проблемы есть в коде с мапой, каналом и группой горутин?

Вопрос 9. Что такое context в Go, для чего он используется и что в него рекомендуется класть?

Вопрос 10. Какие существуют способы синхронизации горутин в Go помимо каналов и зачем нужны мьютексы при наличии каналов?

Вопрос 11. Чем горутины отличаются от потоков ОС, как устроен планировщик Go (GPM-модель) и что такое work stealing?

Вопрос 12. Какие три кита мониторинга сервиса (метрики, логи, трассировка), какие инструменты используются и какие метрики стоит собирать?

Вопрос 13. Что делать, если запросы к базе данных начали тормозить: какие инструменты диагностики использовать и какие причины могут быть?

Вопрос 14. Что такое репликация в базах данных, как она работает, что такое мастер-реплика и что происходит при падении мастера?

Вопрос 15. Что такое шардирование, какие стратегии шардирования существуют и что такое консистентное хеширование?

Вопрос 16. Почему простое хеширование по модулю плохо работает при изменении количества шардов и что такое консистентное хеширование?

Вопрос 17. Нужно ли разработчику знать паттерны проектирования микросервисов (transactional outbox, saga и т.д.)?

Вопрос 18. Насколько глубоко нужно знать Kubernetes разработчику?