Открытое интервью на Middle Go-разработчика

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

Вопрос 1. Почему в Go NaN не равен NaN.

Таймкод: 00:04:15

Ответ собеседника: Правильный. NaN — это неопределённое значение, и его нельзя сравнивать с другим неопределённым значением. Это аналогично NULL в базах данных, где NULL нельзя сравнивать через операторы больше/меньше.

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

Ответ собеседника в целом верный по сути, но требует более глубокого технического объяснения.

Стандарт IEEE 754 и математическая обоснованность

NaN (Not a Number) не равен самому себе не просто «потому что это неопределённость», а потому что это прямо предписано стандартом IEEE 754 для арифметики с плавающей точкой. Логика в том, что NaN может возникать из совершенно разных операций — 0/0, Inf - Inf, sqrt(-1), и каждый из этих NaN может нести разный смысл. Если бы NaN == NaN возвращало true, то мы бы ложно утверждали, что два принципиально разных «неизвестных» значения идентичны, что нарушало бы базовые свойства отношения эквивалентности.

Более формально, оператор == в математике является отношением эквивалентности, которое обязано удовлетворять свойству рефлексивности: a == a всегда true. NaN намеренно нарушает это свойство, потому что NaN — это не число, а специальный маркер, и применять к нему свойства числовых типов некорректно.

Аналогия с NULL в SQL

Сравнение с NULL в SQL действительно точное. В SQL NULL = NULL возвращает UNKNOWN, а не TRUE, поэтому для проверки используется IS NULL. Аналогично в Go для проверки NaN используется функция math.IsNaN():

package main

import (
    "fmt"
    "math"
)

func main() {
    var a float64 = 0.0 / 0.0  // NaN
    var b float64 = math.Log(-1) // NaN

    // НЕПРАВИЛЬНО: всегда false
    fmt.Println(a == b)   // false
    fmt.Println(a == a)   // false

    // ПРАВИЛЬНО: используем math.IsNaN
    fmt.Println(math.IsNaN(a)) // true
    fmt.Println(math.IsNaN(b)) // true
}

Почему это важно на практике

Если бы NaN == NaN было true, это привело бы к багам в алгоритмах поиска, хеширования и дедупликации. Например, NaN мог бы быть найден в map по другому NaN-ключу, хотя они семантически различны. Кроме того, это позволило бы обнаружить наличие NaN через сравнение, что неявно нарушало бы принцип, что NaN — это «заглушка» для невалидных вычислений.

Итог: NaN != NaN — это не особенность Go, а следствие стандарта IEEE 754, который реализован аппаратно на уровне процессора. Все языки, работающие с float64/float32 (C, Java, Python, Rust), ведут себя одинаково.

Вопрос 2. Что хранится в пакете builtin в Go?

Таймкод: 00:05:18

Ответ собеседника: Неправильный. Кандидат не смог ответить на вопрос и признал, что не знает, что хранится в пакете builtin.

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

Пакет builtin в Go — это специальный документационный пакет. Важно понимать, что он не является обычным пакетом в привычном смысле.

Что на самом деле содержит builtin

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

Что описано в документации builtin

Пакет содержит документацию по всем встроенным (built-in) элементам языка Go, которые доступны без импорта какого-либо пакета:

Встроенные типы:

• Примитивы: int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, uintptr
• С плавающей точкой: float32, float64
• Комплексные числа: complex64, complex128
• Другие: bool, string, byte (alias для uint8), rune (alias для int32), any (alias для interface{}), comparable, error

Встроенные функции:

• append — добавление элементов к слайсу
• cap — ёмкость слайса/канала
• close — закрытие канала
• clear — очистка map или слайса (Go 1.21+)
• complex — создание комплексного числа
• copy — копирование слайсов
• delete — удаление элемента из map
• imag — мнимая часть комплексного числа
• len — длина коллекции
• make — создание слайсов, map, каналов
• new — выделение памяти, возврат указателя
• panic — вызов паники
• print / println — отладочный вывод (не рекомендуется для production)
• real — действительная часть комплексного числа
• recover — восстановление после паники

Встроенные константы:

• true, false
• iota

Встроенный интерфейс:

• error

Зачем он нужен

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

// Это НЕ скомпилируется:
import "builtin" // cannot import "builtin"

// Встроенные функции доступны без импорта:
s := make([]int, 0, 10)
s = append(s, 1)
fmt.Println(len(s))

Как посмотреть документацию:

go doc builtin
go doc builtin.append
go doc builtin.make

Ключевой вывод: builtin — это не импортируемый пакет, а документационный артефакт. Все описанные в нём функции, типы и константы являются частью самого языка и доступны глобально без какого-либо импорта.

Вопрос 3. Какие типы могут быть ключами в map в Go? Может ли структура быть ключом map?

Таймкод: 00:05:41

Ответ собеседника: Правильный. Ключами map могут быть любые сравнимые (comparable) типы. Структура быть ключом, если все её поля являются сравнимыми типами. Если в структуре есть слайсы или другие несравнимые типы, то она не может быть ключом map.

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

Ответ собеседника корректный. Дополним его деталями и примерами.

Ключевое правило: comparable

В Go ключом map может быть любой тип, который реализует неявный интерфейс comparable. Это означает, что значения этого типа можно сравнивать операторами == и !=.

Сравнимые типы (могут быть ключами):

• bool, int, uint, float, complex, string — все примитивные числовые типы и строки
• pointer — указатели (сравниваются по адресу)
• channel — каналы (сравниваются по идентичности)
• interface — интерфейсы (динамическое сравнение типа и значения)
• struct — структуры, если все их поля сравнимы
• array — массивы, если тип элемента сравним (массивы фиксированного размера сравниваются поэлементно)

Несравнимые типы (НЕ могут быть ключами):

• slice — слайсы
• map — мапы
• func — функции

Эти три типа несравнимы на уровне языка, потому что они являются ссылочными типами, и операция == для них не определена (кроме сравнения с nil).

Структуры как ключи map:

package main

import "fmt"

// Валидный ключ: все поля сравнимы
type Point struct {
    X int
    Y int
}

// Невалидный ключ: содержит слайс
type InvalidKey struct {
    Name    string
    Tags    []string // slice — несравнимый тип
}

func main() {
    // Работает: Point — comparable
    distances := map[Point]int{
        {X: 0, Y: 0}: 0,
        {X: 1, Y: 0}: 1,
        {X: 1, Y: 1}: 2,
    }
    fmt.Println(distances[Point{X: 1, Y: 1}]) // 2

    // Ошибка компиляции: InvalidKey — не comparable
    // m := map[InvalidKey]string{} // compile error: invalid map key type
}

Вложенные структуры:

Если структура содержит другую структуру, то вложенная структура тоже должна быть comparable:

type Address struct {
    City    string
    Street  string
}

type User struct {
    ID      int
    Address Address // Вложенная структура — comparable
}

// Работает: все поля User и вложенной Address — comparable
var cache map[User]string

Массивы vs слайсы как ключи:

Массивы фиксированного размера — сравнимы, слайсы — нет:

// Работает: массив — comparable
var m1 map[[3]int]string

// Ошибка: слайс — не comparable
// var m2 map[[]int]string // compile error

Почему слайсы, map и func нельзя сравнивать:

Слайс — это структура с полями pointer, len, cap. Два слайса могут указывать на одни и те же данные, но иметь разную длину или capacity. Содержимое базового массива может меняться. Глубокое сравнение содержимого — операция с непредсказуемой сложностью O(n), что противоречит ожиданиям от O(1) операции сравнения для map. Аналогичная логика применяется к map и func.

Практический паттерн: строковой ключ вместо структуры

Если структура содержит несравнимые поля, распространённый подход — сериализовать её в строку:

type Tag struct {
    Key   string
    Value string
}

type Resource struct {
    Name string
    Tags []Tag // слайс — несравнимый
}

// Паттерн: составной строковый ключ
func (r Resource) key() string {
    // Формируем уникальный ключ из полей
    return r.Name + ":" + fmt.Sprint(r.Tags)
}

func main() {
    cache := make(map[string]Resource)
    res := Resource{Name: "server-1", Tags: []Tag{{"env", "prod"}}}
    cache[res.key()] = res
}

Итог: Ключ map в Go должен быть comparable. Структура является comparable, если рекурсивно все её поля (включая вложенные структуры) — comparable. Слайсы, map и функции никогда не являются comparable и не могут быть ни ключами, ни частью ключа.

Вопрос 4. Какую роль в объектно-ориентированной модели играет структура в Go и что реализует интерфейс?

Таймкод: 00:06:18

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

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

Go — это не классический ОО-язык, но он реализует все три столпа ООП через свои механизмы. Важно чётко разделить роли структур и интерфейсов.

Структура (struct) — реализует наследование и инкапсуляцию

Наследование через встраивание (embedding):

В Go нет классического наследования с ключевым словом extends. Вместо этого используется композиция через встраивание структур. При этом методы встроенной структуры автоматически поднимаются (promoted) на уровень внешней:

type Animal struct {
    Name string
}

func (a *Animal) Speak() string {
    return "..."
}

func (a *Animal) Move() string {
    return a.Name + " moves"
}

// Dog "наследует" Animal через встраивание
type Dog struct {
    Animal // встраивание — без имени поля
    Breed  string
}

func (d *Dog) Speak() string {
    return d.Name + " barks" // переопределение метода
}

func main() {
    d := Dog{
        Animal: Animal{Name: "Rex"},
        Breed:  "Labrador",
    }

    // Прямой вызов метода Animal через встраивание
    fmt.Println(d.Speak())       // "Rex barks" — переопределённый метод
    fmt.Println(d.Move())        // "Rex moves" — унаследованный метод
    fmt.Println(d.Animal.Speak()) // "..." — прямой вызов родительского метода
}

Инкапсуляция через регистр первой буквы:

Go использует простое правило: идентификаторы с заглавной буквы — экспортируемые (public), со строчной — неэкспортируемые (private). Приватность действует на уровне пакета, а не на уровне структуры:

package account

type BankAccount struct {
    owner   string // private — доступен только внутри пакета account
    balance int    // private
}

func NewBankAccount(owner string) *BankAccount {
    return &BankAccount{owner: owner, balance: 0}
}

func (ba *BankAccount) Balance() int {
    return ba.balance // контролируемый доступ к приватному полю
}

func (ba *BankAccount) Deposit(amount int) {
    if amount > 0 {
        ba.balance += amount
    }
}

package main

import "myproject/account"

func main() {
    acc := account.NewBankAccount("John")
    acc.Deposit(100)
    fmt.Println(acc.Balance()) // 100

    // acc.balance = 999999 // ошибка компиляции: balance не экспортируется
}

Интерфейс — реализует полиморфизм

Интерфейс в Go определяет набор методов (контракт), который должен быть реализован. Реализация — неявная (duck typing): не нужно явно указывать, что тип реализует интерфейс. Если тип имеет все методы интерфейса — он его реализует автоматически.

package main

import "fmt"

// Интерфейс — контракт поведения
type Speaker interface {
    Speak() string
}

type Dog struct{ Name string }
func (d Dog) Speak() string { return d.Name + " barks" }

type Cat struct{ Name string }
func (c Cat) Speak() string { return c.Name + " meows" }

type Robot struct{ Model string }
func (r Robot) Speak() string { return r.Model + " beeps" }

// Полиморфная функция — работает с любым Speaker
func MakeItSpeak(s Speaker) {
    fmt.Println(s.Speak())
}

func main() {
    entities := []Speaker{
        Dog{Name: "Rex"},
        Cat{Name: "Whiskers"},
        Model: "R2-D2"},
    }

    // Полиморфизм: один интерфейс — разное поведение
    for _, e := range entities {
        MakeItSpeak(e)
    }
    // Rex barks
    // Whiskers meews
    // R2-D2 beeps
}

Таблица: распределение ролей ООП

Столп ООП	Механизм в Go	Кто реализует
Наследование	Встраивание структур (embedding)	struct
Инкапсуляция	Регистр первой буквы (экспортирование)	struct + package
Полиморфизм	Интерфейсы (неявная реализация)	interface

Важные нюансы интерфейсов в Go:

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

func PrintAnything(v interface{}) {
    fmt.Printf("type: %T, value: %v\n", v)
}

Композиция интерфейсов:

type Reader interface {
    Read(p []byte) (n int, err error)
}

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

type ReadWriter interface {
    Reader
    Writer
}

Утверждение типов (type assertion) для полиморфного поведения:

func Process(s Speaker) {
    // Проверяем конкретный тип для специфичного поведения
    if dog, ok := s.(Dog); ok {
        fmt.Printf("This is a dog named %s\n", dog.Name)
    }
    fmt.Println(s.Speak())
}

Итог: В Go структура отвечает за наследование (через эмбеддинг) и инкапсуляцию (через правила экспортирования). Интерфейс отвечает за полиморфизм — он определяет контракт, который типы реализуют неявно. Это принципиально отличается от классических ОО-языков, где наследование и полиморфизм обычно связаны через иерархию классов.

Вопрос 5. Что такое ресивер (receiver) в Go и что делает ресивер с указателем (pointer receiver)?

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

Ответ собеседника: Правильный. Ресивер определяет принадлежность метода к структуре. Ресивер с указателем позволяет изменять объект, на который указывает указатель, то есть модифицировать оригинальный объект, а не его копию.

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

Ответ собеседника корректный. Дополним его деталями, которые важно знать на интервью.

Что такое ресивер

Ресивер — это специальный параметр между func и именем метода, который привязывает функцию к конкретному типу. По сути, это аналог this в Java/C++ или self в Python, но в Go он является явным параметром:

type Counter struct {
    value int
}

// Value receiver — получает КОПИЮ объекта
func (c Counter) Value() int {
    return c.value
}

// Pointer receiver — получает УКАЗАТЕЛЬ на объект
func (c *Counter) Increment() {
    c.value++ // модифицирует оригинал
}

Value receiver vs Pointer receiver — ключевые различия

Value receiver (значение):

• Метод получает копию объекта
• Изменения внутри метода не влияют на оригинал
• Безопасен для конкурентного чтения (работает с копией)
• Подходит для небольших структур и методов-геттеров

type Point struct {
    X, Y float64
}

// Value receiver — не меняет оригинал
func (p Point) Move(dx, dy float64) Point {
    p.X += dx // меняем копию
    p.Y += dy
    return p // возвращаем новую точку
}

func main() {
    pt := Point{X: 1, Y: 2}
    newPt := pt.Move(10, 20)
    fmt.Println(pt)    // {1, 2} — оригинал НЕ изменился
    fmt.Println(newPt) // {11, 22}
}

Pointer receiver (указатель):

• Метод получает указатель на оригинальный объект
• Изменения внутри метода модифицируют оригинал
• Не создаёт копию — эффективен для больших структур
• Обязателен, если метод должен менять состояние объекта

type User struct {
    Name  string
    Email string
}

// Pointer receiver — модифицирует оригинал
func (u *User) UpdateEmail(newEmail string) {
    u.Email = newEmail // меняем оригинал
}

func main() {
    user := User{Name: "John", Email: "john@old.com"}
    user.UpdateEmail("john@new.com")
    fmt.Println(user.Email) // "john@new.com" — оригинал изменился
}

Автоматическое разыменование — важная особенность Go

Go автоматически конвертирует между значением и указателем при вызове метода:

type Counter struct{ value int }

func (c *Counter) Inc()  { c.value++ }
func (c Counter) Get() int { return c.value }

func main() {
    // Value может вызывать pointer receiver метод
    c := Counter{}
    c.Inc()              // Go автоматически берёт адрес: (&c).Inc()
    fmt.Println(c.Get()) // 1

    // Pointer может вызывать value receiver метод
    p := &Counter{}
    p.Inc()
    fmt.Println(p.Get()) // Go автоматически разыменовывает: (*p).Get()
}

Когда использовать каждый тип ресивера

Используйте pointer receiver, когда:

• Метод должен модифицировать состояние ресивера
• Структура большая (копирование дорого)
• Нужна консистентность: если один метод структуры использует pointer receiver, то лучше все использовать pointer receiver

Используйте value receiver, когда:

• Метод только читает данные (геттеры)
• Структура маленькая (копирование дёшево)
• Тип должен быть безопасен для конкурентного доступа
• Тип реализует интерфейс sync.Locker или аналогичные

Вопрос 6. Если передать слайс как параметр в функцию, внутри вызвать sort.Ints для его сортировки и ничего не возвращать — изменится ли слайс снаружи после вызова функции?

Таймкод: 00:09:53

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

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

Ответ собеседника полностью корректный. Раскроем тему более детально, чтобы глубоко понять внутреннее устройство.

Внутренняя структура слайса

Слайс в Go — это структура из трёх полей (slice header):

// runtime/slice.go
type slice struct {
    array unsafe.Pointer // указатель на базовый массив
    len   int            // длина слайса
    cap   int            // ёмкость слайса
}

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

package main

import (
    "fmt"
    "sort"
)

func sortSlice(s []int) {
    sort.Ints(s) // мутирует базовый массив напрямую
}

func main() {
    data := []int{5, 3, 1, 4, 2}
    fmt.Println("before:", data) // [5 3 1 4 2]

    sortSlice(data)

    fmt.Println("after:", data)  // [1 2 3 4 5] — организм изменился
}

Критически важный нюанс: append ведёт себя иначе

Хотя мутация существующих элементов видна снаружи, append может создать новый базовый массив, и тогда оригинальный слайс не изменится:

func tryAppend(s []int) {
    s = append(s, 999) // может создать новый массив!
    fmt.Println("inside:", s)
}

func main() {
    data := []int{1, 2, 3}
    // cap(data) = 3, len(data) = 3
    tryAppend(data)
    fmt.Println("outside:", data) // [1 2 3] — НЕ изменился!
}

Это происходит потому, что при append с нехваткой capacity выделяется новый базовый массив, и локальная копия заголовка начинает указывать на него. Оригинальный заголовок по-прежнему указывает на старый массив.

Как гарантированно изменить слайс через append внутри функции:

// Вариант 1: Вернуть новый слайс
func appendAndReturn(s []int, val int) []int {
    return append(s, val)
}

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

func main() {
    data := []int{1, 2, 3}

    data = appendAndReturn(data, 4)
    fmt.Println(data) // [1 2 3 4]

    appendViaPointer(&data, 5)
    fmt.Println(data) // [1 2 3 4 5]
}

Сравнение поведения разных типов при передаче в функцию

Тип	Копирование при передаче	Мутация элементов видна снаружи	append виден снаружи
slice	Копируется заголовок (ptr, len, cap)	Да	Нет (нужно возвращать)
map	Копируется указатель на hash table	Да	Да (map всегда ссылочный)
chan	Копируется указатель на канал	Да	Да (канал всегда ссылочный)
array	Копируется весь массив целиком	Нет	Нет
struct	Копируется вся структура	Нет	—

Итог: sort.Ints мутирует элементы базового массива по месту (in-place), поэтому изменения видны снаружи. Однако это работает именно потому, что sort.Ints не делает append и не меняет len/cap слайса — он лишь переставляет существующие элементы. Если бы функция делала append, результат был бы другим.

Вопрос 7. Зачем нужна пустая структура (struct{}) в Go?

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

Ответ собеседния: Правильный. Пустая структура занимает ноль байт. Используется как сигнал в каналах и как значение в map для реализации set.

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

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

Ключевое свойство: нулевой размер

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var s struct{}
    fmt.Println(unsafe.Sizeof(s)) // 0 байт

    // Даже массив из миллиона пустых структур — 0 байт
    var arr [1_000_000]struct{}
    fmt.Println(unsafe.Sizeof(arr)) // 0 байт
}

Пустая структура не содержит полей, поэтому компилятору не нужно выделять память под данные. Однако она всё ещё является валидным типом с адресом в памяти.

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

1. Сигнальный канал (done channel)

Когда нужно только уведомить о событии без передачи данных:

package main

import (
    "fmt"
    "time"
)

func worker(done chan struct{}) {
    fmt.Println("working...")
    time.Sleep(2 * time.Second)
    fmt.Println("done!")
    close(done) // или done <- struct{}{}
}

func main() {
    done := make(chan struct{})

    go worker(done)

    // Блокируемся до получения сигнала
    <-done
    fmt.Println("worker finished")
}

Почему не chan bool? Потому что struct{} семантически точнее — мы не передаём значение, а только сигнал. Кроме того, chan struct{} ясно показывает намерение: «здесь нет данных, только факт события».

2. Реализация Set (множество)

В Go нет встроенного типа set, но его можно реализовать через map[K]struct{}:

package main

import "fmt"

type StringSet struct {
    items map[string]struct{}
}

func NewStringSet() *StringSet {
    return &StringSet{items: make(map[string]struct{})}
}

func (s *StringSet) Add(item string) {
    s.items[item] = struct{}{}
}

func (s *StringSet) Contains(item string) bool {
    _, exists := s.items[item]
    return exists
}

func (s *StringSet) Remove(item string) {
    delete(s.items, item)
}

func (s *StringSet) Size() int {
    return len(s.items)
}

func main() {
    set := NewStringSet()
    set.Add("apple")
    set.Add("banana")
    set.Add("apple") // дубликат — не добавится

    fmt.Println(set.Contains("apple"))  // true
    fmt.Println(set.Contains("cherry")) // false
    fmt.Println(set.Size())             // 2
}

Почему не map[K]bool? Потому что struct{} не занимает память, а bool занимает 1 байт. При миллионах элементов разница в потреблении памяти становится существенной.

3. Реализация интерфейса без состояния

Когда нужно реализовать интерфейс, но не нужно хранить данные:

type Logger interface {
    Log(msg string)
}

// NoOpLogger — заглушка, не хранящая состояния
type NoOpLogger struct{}

func (NoOpLogger) Log(msg string) {
    // ничего не делает
}

func Process(logger Logger) {
    logger.Log("processing...")
}

func main() {
    Process(NoOpLogger{}) // ноль байт на экземпляр
}

4. Использование с sync.Map и пулы объектов

// Пул пустых структур — всегда один и тот же адрес
var emptyStructPool = sync.Pool{
    New: func() interface{} {
        return struct{}{}
    },
}

5. Метка компилятора (build tags) и импорт с побочным эффектом

// Иногда используется для проверки выполнения интерфейса на этапе компиляции
var _ io.Writer = (*MyWriter)(nil) // проверка, что *MyWriter реализует io.Writer

// Аналогично с пустой структурой для проверки типа
type MyType struct{}
var _ MyInterface = MyType{}

Адрес пустой структуры

Несмотря на нулевой размер, пустая структура имеет адрес:

func main() {
    a := struct{}{}
    b := struct{}{}
    fmt.Println(&a == &b) // true — Go использует один глобальный адрес для всех struct{}
}

Компилятор Go использует специальный глобальный символ runtime.zerobase для всех значений нулевого размера. Все struct{} указывают на один и тот же адрес в памяти.

Итог: struct{} — это идиоматический инструмент Go для выражения «здесь нет данных». Основные применения — сигнальные каналы (chan struct{}), реализация множеств (map[K]struct{}), и заглушки интерфейсов без состояния. Нулевой размер делает её идеальной для сценариев, где важно только наличие ключа или факт события, а не хранимое значение.

Вопрос 8. Что такое интерфейс в Go изнутри (его внутренняя структура)?

Таймкод: 00:13:27

Ответ собеседника: Правильный. Интерфейс — это структура с ссылкой на реализующую структуру и itable (таблицей методов). Упомянуты iface, eface и пакет builtin.

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

Ответ собеседника в целом верный, но требует уточнения: описание интерфейсов находится не в builtin, а в runtime. Дополним деталями.

Два типа внутреннего представления интерфейса

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

1. iface — интерфейс с методами

Используется, когда интерфейс содержит хотя бы один метод (например, io.Reader, error).

// runtime/runtime2.go
type iface struct {
    tab  *itab          // указатель на itable (таблицу интерфейса)
    data unsafe.Pointer // указатель на данные (значение конкретного типа)
}

2. eface — пустой интерфейс

Используется для interface{} / any — интерфейса без методов.

// runtime/runtime2.go
type eface struct {
    _type *_type        // указатель на описание типа (type descriptor)
    data  unsafe.Pointer // указатель на данные
}

Структура itab — таблица интерфейса

// runtime/runtime2.go
type itab struct {
    inter *interfacetype // указатель на тип интерфейса
    _type *_type         // указатель на конкретный тип
    hash  uint32         // хеш типа (для оптимизации type assertion)
    _     [4]byte        // padding
    fun   [1]uintptr     // массив указателей на методы (размер 1 — трюк CGo)
}

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

Структура _type — описание типа

// runtime/type.go
type _type struct {
    size       uintptr
    ptrdata    uintptr
    hash       uint32
    tflag      tflag
    align      uint8
    fieldAlign uint8
    kind       uint8
    // ... и другие поля, включая указатель на строковое имя типа
}

Как это работает вместе

package main

import (
    "fmt"
    "unsafe"
)

type Speaker interface {
    Speak() string
}

type Dog struct{ Name string }

func (d Dog) Speak() string {
    return d.Name + " barks"
}

func main() {
    var s Speaker = Dog{Name: "Rex"}

    // Внутреннее представление:
    // s.tab -> itab{inter: Speaker, _type: Dog, fun: [Speak]}
    // s.data -> указатель на Dog{Name: "Rex"}

    // Размер интерфейса — всегда 16 байт (два указателя)
    fmt.Println(unsafe.Sizeof(s)) // 16 на 64-битной системе
}

Визуализация памяти:

┌─────────────────────────────────────────────┐
│ iface (интерфейс с методами)                │
├──────────────┬──────────────────────────────┤
│ tab *itab    │ data unsafe.Pointer          │
│ (8 байт)     │ (8 байт)                     │
└──────┬───────┴──────────┬───────────────────┘
       │                  │
       ▼                  ▼
┌──────────────┐   ┌─────────────────┐
│ itab         │   │ Dog{Name: "Rex"}│
├──────────────┤   └─────────────────┘
│ inter        │
│ _type        │
│ hash         │
│ fun[0] ─────────► Dog.Speak
└──────────────┘

┌─────────────────────────────────────────────┐
│ eface (пустой интерфейс interface{})        │
├──────────────┬──────────────────────────────┤
│ _type *_type │ data unsafe.Pointer          │
│ (8 байт)     │ (8 байт)                     │
└──────────────┴──────────────────────────────┘

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

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

Nil интерфейса vs интерфейс с nil значением

Это частая ловушка, связанная с внутренней структурой:

package main

import "fmt"

type Speaker interface {
    Speak() string
}

type Dog struct{ Name string }
func (d *Dog) Speak() string {
    if d == nil {
        return "nil dog"
    }
    return d.Name + " barks"
}

func main() {
    // Случай 1: nil интерфейса — оба поля nil
    var s Speaker
    fmt.Println(s == nil) // true

    // Случай 2: интерфейс содержит nil-указатель на тип
    var d *Dog = nil
    s = d
    fmt.Println(s == nil) // false! tab != nil, data == nil

    // Вызов метода возможен — он получит nil receiver
    fmt.Println(s.Speak()) // "nil dog"
}

Когда мы присваиваем nil указатель *Dog в интерфейс Speaker, поле tab указывает на валидный itab (тип *Dog реализует Speaker), а data — nil. Поэтому интерфейс не равен nil, хотя содержит nil значение.

Итог: Интерфейс в Go — это пара указателей. Для интерфейсов с методами это iface{tab *itab, data unsafe.Pointer}, где itab содержит таблицу указателей на методы. Для пустого интерфейса это eface{_type *_type, data unsafe.Pointer}. Размер любого интерфейса — 16 байт на 64-битной системе. Понимание внутренней структуры критически важно для понимания nil-интерфейсов, type assertions и производительности.

Вопрос 9. Приведи примеры ситуаций, когда без интерфейсов невозможно обойтись в Go.

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

Ответ собеседника: Правильный. Приведены примеры: http.ResponseWriter, моки в тестировании, паттерн фабрика с методом Run.

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

Ответ собеседника корректный. Расширим список примеров и добавим технических деталей.

1. HTTP-обработчики и middleware в net/http

Стандартный пакет net/http построен на интерфейсах. Без них невозможно было бы писать middleware:

type ResponseWriter interface {
    Header() Header
    Write([]byte) (int, error)
    WriteHeader(statusCode int)
}

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

// Middleware — возможен только благодаря интерфейсу
func LoggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)
        log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))
    })
}

Без интерфейса ResponseWriter нельзя было бы перехватывать и модифицировать ответ в middleware.

2. Тестирование и моки

В Go нет наследования и возможности подменить реализацию класса. Интерфейсы — единственный способ изоляции зависимостей:

// Интерфейс репозитория
type UserRepository interface {
    FindByID(ctx context.Context, id int64) (*User, error)
    Save(ctx context.Context, user *User) error
}

// Бизнес-логика зависит от интерфейса, а не конкретной реализации
type UserService struct {
    repo UserRepository
}

func (s *UserService) GetUserName(ctx context.Context, id int64) (string, error) {
    user, err := s.repo.FindByID(ctx, id)
    if err != nil {
        return "", err
    }
    return user.Name, nil
}

// Тест с моком
type MockUserRepository struct {
    users map[int64]*User
}

func (m *MockUserRepository) FindByID(ctx context.Context, id int64) (*User, error) {
    if user, ok := m.users[id]; ok {
        return user, nil
    }
    return nil, ErrNotFound
}

func (m *MockUserRepository) Save(ctx context.Context, user *User) error {
    m.users[user.ID] = user
    return nil
}

func TestGetUserName(t *testing.T) {
    mock := &MockUserRepository{
        users: map[int64]*User{
            1: {ID: 1, Name: "John"},
        },
    }
    service := &UserService{repo: mock}

    name, err := service.GetUserName(context.Background(), 1)
    assert.NoError(t, err)
    assert.Equal(t, "John", name)
}

3. Работа с разными хранилищами данных

type Cache interface {
    Get(ctx context.Context, key string) ([]byte, error)
    Set(ctx context.Context, key string, value []byte, ttl time.Duration) error
    Delete(ctx context.Context, key string) error
}

// Реализация для Redis
type RedisCache struct {
    client *redis.Client
}

// Реализация для in-memory (для тестов или локальной разработки)
type InMemoryCache struct {
    mu    sync.RWMutex
    items map[string][]byte
}

// Сервис работает с любым кешем
type ImageService struct {
    cache Cache
}

4. io.Reader и io.Writer — композиция потоков данных

Стандартная библиотека Go построена на интерфейсах io.Reader и io.Writer. Без них невозможна композиция:

// Чтение сжатого и одновременно хэшируемого файла
func processFile(filename string) (string, error) {
    f, err := os.Open(filename)
    if err != nil {
        return "", err
    }
    defer f.Close()

    // gzip.Reader оборачивает io.Reader
    gz, err := gzip.NewReader(f)
    if err != nil {
        return "", err
    }
    defer gz.Close()

    // hash пишет в io.Writer
    h := sha256.New()

    // io.Copy работает с любым Reader и Writer
    if _, err := io.Copy(h, gz); err != nil {
        return "", err
    }

    return hex.EncodeToString(h.Sum(nil)), nil
}

Без интерфейсов io.Reader/io.Writer пришлось бы писать отдельный код для каждой комбинации (файл+хеш, сеть+gzip+хеш и т.д.).

5. Паттерн Strategy (стратегия)

type PricingStrategy interface {
    Calculate(price float64) float64
}

type RegularPricing struct{}
func (r RegularPricing) Calculate(price float64) float64 { return price }

type DiscountPricing struct {
    Percent float64
}
func (d DiscountPricing) Calculate(price float64) float64 {
    return price * (1 - d.Percent/100)
}

type Order struct {
    items  []Item
    pricing PricingStrategy
}

func (o *Order) Total() float64 {
    var sum float64
    for _, item := range o.items {
        sum += o.pricing.Calculate(item.Price)
    }
    return sum
}

6. Паттерн Plugin / расширяемая архитектура

type StoragePlugin interface {
    Name() string
    Open(connString string) (Storage, error)
}

type Storage interface {
    Read(key string) ([]byte, error)
    Write(key string, data []byte) error
}

// Регистрация плагинов
var plugins = map[string]StoragePlugin{}

func Register(name string, plugin StoragePlugin) {
    plugins[name] = plugin
}

func OpenStorage(name, connString string) (Storage, error) {
    plugin, ok := plugins[name]
    if !ok {
        return nil, fmt.Errorf("unknown storage: %s", name)
    }
    return plugin.Open(connString)
}

Итог: Интерфейсы в Go незаменимы в следующих сценариях: HTTP-обработчики и middleware, тестирование с моками, абстрагирование от конкретных реализаций (БД, кеш, внешние сервисы), композиция потоков данных через io.Reader/io.Writer, паттерны Strategy и Plugin. Без интерфейсов код становится жёстко связан с конкретными типами, что делает его невозможным тестировать, расширять и переиспользовать.

Вопрос 10. Расскажи про модель горутин в Go: как работает планировщик, что такое логические процессоры, треды, локальные и глобальная очереди горутин.

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

Ответ собеседника: Правильный. Описана модель M:P:G, локальные и глобальная очереди, парковка горутин при блокирующих операциях и возврат через глобальную очередь.

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

Ответ собеседника в целом корректный, но есть неточность: количество тредов (M) не всегда равно количеству логических процессоров (P). Дополним и уточним.

Модель GMP (Goroutine, Machine, Processor)

Планировщик Go использует модель из трёх сущностей:

G (Goroutine) — лёгкая зелёная нить (горутина). Изначальный стек ~2 КБ, может расти. Хранит контекст выполнения: счётчик программы, указатель стека, локальные переменные.

P (Processor / логический процессор) — контекст выполнения. Содержит локальную очередь горутин (runqueue), кэш памяти (mcache) и другие метаданные. Количество P по умолчанию равно runtime.NumCPU() и настраивается через runtime.GOMAXPROCS().

M (Machine / OS thread) — реальный поток операционной системы. Выполняет инструкции горутин. Количество M может быть больше, чем количество P. Если горутина выполняет блокирующий системный вызов (файловый ввод-вывод, сетевой вызов), M блокируется, и runtime может создать новую M для оставшихся P.

┌─────────────────────────────────────────────────┐
│                  Global Runqueue                 │
│          (глобальная очередь горутин)            │
└─────────┬──────────┬──────────┬─────────────────┘
          │          │          │
    ┌─────▼───┐ ┌───▼────┐ ┌──▼──────┐
    │   P0    │ │   P1   │ │   P2    │   ...  Pn
    │         │ │        │ │         │
    │ Local Q │ │Local Q │ │Local Q  │
    │ [G G G] │ │[G G G] │ │[G G G]  │
    └────┬────┘ └───┬────┘ └──┬──────┘
         │          │         │
    ┌────▼────┐ ┌───▼────┐ ┌──▼──────┐
    │   M0    │ │   M1   │ │   M2    │
    │ (OS     │ │ (OS    │ │ (OS     │
    │  thread)│ │ thread)│ │ thread) │
    └─────────┘ └────────┘ └─────────┘

Локальная очередь горутин

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

go func() {
    // эта горутина попадает в локальную очередь P,
    // на котором выполняется родительская горутина
}()

Локальная очередь работает по принципу FIFO с некоторыми оптимизациями: при переполнении половина горутин перемещается в глобальную очередь.

Глобальная очередь

Глобальная очередь (sched.runq) — это общая очередь для всех P. Горутины попадают сюда в нескольких случаях:

• Локальная очередь переполнена
• Горутина разблокировалась после системного вызова (netpoll)
• При работе runtime.Gosched() или операций с каналами/мьютексами, когда горутина перемещается между P

Work stealing — кража работы

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

1. Проверить глобальную очередь
2. Если пусто — украсть половину горутин из локальной очереди случайного P
3. Если и там пусто — проверить netpoll (готовые сетевые соединения)

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

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

    // 3. Проверить netpoll
    gp = netpoll(0) // non-blocking
    if gp != nil {
        return gp, false
    }

    // 4. Украсть работу у других P
    gp = stealWork()
    return gp, false
}

Блокирующие операции и парковка

Когда горутина выполняет блокирующую операцию, планировщик не блокирует M:

// Сетевой ввод-вывод — НЕ блокирует M (используется epoll/kqueue/IOCP)
conn.Read(buf)  // горутина паркуется, M выполняет другие горутины

// Каналы — НЕ блокирует M
value := <-ch   // горутина паркуется, M выполняет другие горутины

// Системные вызовы (файловый I/O) — БЛОКИРУЕТ M
file.Read(buf)  // M блокируется, runtime создаёт новую M для этого P

Для сетевого ввода-вывода Go использует netpoll (epoll на Linux, kqueue на macOS, IOCP на Windows). Горутина паркуется, M продолжает выполнять другие горутины, а когда данные готовы, горутина возвращается в глобальную очередь.

Привязка M к P

M не может выполнять горутины без P. P не может выполняться без M. Связь M-P является парой:

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

Настройка количества P

func main() {
    // По умолчанию равно runtime.NumCPU()
    runtime.GOMAXPROCS(4)
    fmt.Println(runtime.GOMAXPROCS(0)) // 4
}

Итог: Планировщик Go использует модель GMP с work stealing. P (логические процессоры) имеют локальные очереди горутин, общая глобальная очередь для балансировки. M (OS threads) может быть больше P — это необходимо для блокирующих системных вызовов. Сетевой I/O не блокирует M благодаря netpoll, а файловый I/O блокирует, и runtime создаёт дополнительные M. Work stealing обеспечивает балансировку нагрузки между P.

Вопрос 11. Где горутина аллоцирует себе память? Что такое escape analysis?

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

Ответ собеседния: Правильный. Описан резиновый стек горутины, хип, escape analysis. Не назвал флаг -gcflags='-m'.

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

Ответ собеседника корректный. Дополним техническими деталями.

Стек горутины

Каждая горутина начинается со стека размером 2 КБ (с Go 1.4+, ранее было 8 КБ). Стек горутины — «резиновый» (contiguous stack): когда стек заканчивается, runtime выделяет новый сегмент в 2 раза больше, копирует данные и обновляет все указатели на стековые переменные.

// Каждая горутина имеет свой стек
go func() {
    // локальные переменные здесь на стеке этой горутины
    var buf [1024]byte
    process(buf[:])
}()

Стек горутины хранится в куче (heap), но управляется как стек — LIFO порядок аллокации и освобождения.

Куча (heap)

Память в куче аллоцируется, когда:

• Компилятор определяет, что объект «убегает» за пределы стека
• Используется new() или make()
• Размер объекта неизвестен на этапе компиляции

Escape Analysis (анализ убегания)

Escape analysis — это оптимизация компилятора, которая определяет, где разместить переменную: на стеке или в куче. Если компилятор может доказать, что указатель на переменную не выходит за пределы функции, переменная размещается на стеке (быстро, без GC). Если не может — в куче (медленнее, требует GC).

Ключевые правила, когда переменная убегает в кучу:

1. Возврат указателя из функции:

func NewUser() *User {
    u := User{Name: "John"} // убегает в кучу — указатель возвращается
    return &u
}

func main() {
    u := NewUser() // u указывает на объект в куче
    fmt.Println(u.Name)
}

2. Запись в глобальную переменную или поле структуры:

var global *int

func setGlobal() {
    x := 42   // убегает в кучу — адрес записывается в глобальную переменную
    global = &x
}

3. Передача в интерфейс:

func printValue(v interface{}) {
    fmt.Println(v)
}

func main() {
    x := 42 // может убежать в кучу — interface{} требует heap allocation
    printValue(x)
}

4. Замыкание (closure) захватывает переменную:

func counter() func() int {
    i := 0       // убегает в кучу — захватывается замыканием
    return func() int {
        i++
        return i
    }
}

5. Слишком большой объект для стека:

func process() {
    var buf [1 << 20]byte // 1 МБ — может убежать в кучу из-за размера
    // ...
}

Как посмотреть escape analysis:

go build -gcflags='-m' ./...
go build -gcflags='-m=2' ./... # подробный вывод

Пример вывода:

func createUser() *User {
    u := User{Name: "John"}
    return &u
}

./main.go:5:2: moved to heap: u
./main.go:6:9: &u escapes to heap

Пример оптимизации:

// Плохо — аллокация в куче
func getID() *int {
    id := 42
    return &id // moved to heap: id
}

// Лучше — возврат значения (стек)
func getID() int {
    return 42 // не убегает — копируется в стек вызывающего
}

Стек vs Куча — сравнение:

Характеристика	Стек	Куча
Скорость аллокации	O(1) — сдвиг указателя	O(log n) — поиск свободного блока
Освобождение	Автоматически при выходе из функции	Garbage Collector
Размер	Ограничен (2 КБ на горутину, растёт)	Ограничен памятью системы
Конкурентность	Каждая горутина имеет свой стек	Общая для всех горутин
Фрагментация	Нет	Возможно

Итог: Горутина аллоцирует память на стеке (локальные переменные) и в куче (объекты, указатели на которые убегают за пределы функции). Escape analysis — оптимизация компилятора, определяющая размещение переменных. Переменная убегает в кучу, если указатель на неё возвращается из функции, записывается в глобальную переменную, передаётся в интерфейс или захватывается замыканием. Флаг -gcflags='-m' позволяет увидеть решения компилятора по escape analysis.

Вопрос 12. Что такое канал в Go? Какие виды каналов существуют, как они устроены внутри и какие операции с ними можно выполнять?

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

Ответ собеседника: Правильный. Описаны каналы как примитив синхронизации, буферизированные и небуферизированные, кольцевой буфер, handshake, операции (write, read, close), паника при записи в закрытый канал, двухзначное чтение.

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

Ответ собеседника полный и корректный. Дополним внутренней структурой и дополнительными нюансами.

Внутренняя структура канала

Канал в Go — это указатель на структуру hchan в runtime:

// 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          // мьютекс для защиты структуры
}

type waitq struct {
    first *sudog
    last  *sudog
}

type sudog struct {
    g    *g           // горутина
    elem unsafe.Pointer // данные для передачи
    next *sudog
    prev *sudog
}

Типы каналов

// Небуферизированный канал (синхронный)
ch1 := make(chan int) // буфер = 0

// Буферизированный канал (асинхронный до заполнения буфера)
ch2 := make(chan int, 10) // буфер = 10

// Канал только для чтения (ограничение на уровне компилятора)
var readOnly <-chan int

// Канал только для записи (ограничение на уровне компилятора)
var writeOnly chan<- int

Небуферизированный канал — handshake

Передача данных происходит только когда и писатель, и читатель готовы одновременно:

ch := make(chan int)

go func() {
    ch <- 42 // блокируется, пока кто-то не прочитает
}()

value := <-ch // блокируется, пока кто-то не напишет
fmt.Println(value) // 42

Внутри: горутина-писатель добавляется в sendq, паркуется. Когда приходит читатель, runtime копирует данные напрямую из стека писателя в стек читателя — без использования буфера.

Буферизированный канал — кольцевой буфер

ch := make(chan int, 3)

ch <- 1 // qcount=1, sendx=1
ch <- 2 // qcount=2, sendx=2
ch <- 3 // qcount=3, sendx=0 (кольцевой — завернулся)

// Запись в заполненный буфер блокирует писателя
// Чтение из пустого буфера блокирует читателя

Буфер до чтения:
┌───┬───┬───┐
│ 1 │ 2 │ 3 │
└───┴───┴───┘
        ↑sendx
  ↑recvx

После одного чтения:
┌───┬───┬───┐
│   │ 2 │ 3 │
└───┴───┴───┘
        ↑sendx
      ↑recvx (сдвинулся)

Операции с каналами

1. Запись и чтение:

ch <- value    // запись (блокирующая, если буфер полон или нет читателя)
value := <-ch  // чтение (блокирующее, если буфер пуст или нет писателя)

2. Закрытие канала:

close(ch)

// Чтение из закрытого канала возвращает zero value
v := <-ch // v = 0 (zero value для int)

// Двухзначное чтение — проверка закрытия
v, ok := <-ch // v = 0, ok = false (канал закрыт)

// Запись в закрытый канал — паника!
ch <- 42 // panic: send on closed channel

// Закрытие закрытого канала — паника!
close(ch) // panic: close of closed channel

3. Range по каналу:

for v := range ch {
    fmt.Println(v)
}
// range автоматически завершается при закрытии канала

4. Select — мультиплексирование каналов:

select {
case v1 := <-ch1:
    fmt.Println("ch1:", v1)
case v2 := <-ch2:
    fmt.Println("ch2:", v2)
case ch3 <- 42:
    fmt.Println("sent to ch3")
case <-time.After(5 * time.Second):
    fmt.Println("timeout")
default:
    fmt.Println("no channel ready")
}

Направленные каналы:

func producer(ch chan<- int) {
    for i := 0; i < 5; i++ {
        ch <- i
    }
    close(ch)
}

func consumer(ch <-chan int) {
    for v := range ch {
        fmt.Println(v)
    }
}

func main() {
    ch := make(chan int, 5)
    go producer(ch) // получает chan<- int (только запись)
    consumer(ch)    // получает <-chan int (только чтение)
}

Паттерны использования каналов

Done-канал для отмены:

func worker(done chan struct{}) {
    for {
        select {
        case <-done:
            fmt.Println("cancelled")
            return
        default:
            // работа
            time.Sleep(100 * time.Millisecond)
        }
    }
}

func main() {
    done := make(chan struct{})
    go worker(done)

    time.Sleep(1 * time.Second)
    close(done) // сигнал отмены
    time.Sleep(100 * time.Millisecond) // даём время на завершение
}

Fan-out / Fan-in:

// Fan-out: один канал читается несколькими горутинами
func fanOut(input chan int, n int) []chan int {
    outputs := make([]chan int, n)
    for i := range outputs {
        outputs[i] = make(chan int)
        go func(ch chan int) {
            for v := range input {
                ch <- v * 2
            }
            close(ch)
        }(outputs[i])
    }
    return outputs
}

// Fan-in: несколько каналов сливаются в один
func fanIn(channels ...chan int) chan int {
    merged := make(chan int)
    var wg sync.WaitGroup
    wg.Add(len(channels))

    for _, ch := range channels {
        go func(c chan int) {
            defer wg.Done()
            for v := range c {
                merged <- v
            }
        }(ch)
    }

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

    return merged
}

Итог: Канал — это потокобезопасная очередь с внутренней структурой hchan, содержащей кольцевой буфер, мьютекс и очереди ожидающих горутин (sendq, recvq). Небуферизированные каналы работают по принципу handshake (прямая передача), буферизированные — через кольцевой буфер. Основные операции: запись (ch <- v), чтение (v := <-ch), закрытие (close(ch)), select, range. Запись в закрытый канал вызывает панику. Двухзначное чтение (v, ok := <-ch) позволяет определить, закрыт ли канал.

Вопрос 13. Можно ли реализовать приоритетное чтение из двух каналов?

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

Ответ собеседника: Правильный. Описан подход с вложенными select: первый select с default для приоритетного канала, второй — для второстепенного.

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

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

Почему обычный select не подходит

select в Go гарантирует случайный выбор среди готовных каналов. Это сделано намеренно для предотвращения starvation:

// НЕ РАБОТАТ как приоритетный — выбор случайный
select {
case cmd := <-commands:
    processCommand(cmd)
case data := <-dataStream:
    processData(data)
}

Если оба канала готовы, Go выбирает случайный case с помощью fastrand().

Подход 1: Вложенные select (описан собеседником)

func priorityReader(commands chan Command, data chan Data) {
    for {
        // Сначала проверяем приоритетный канал
        select {
        case cmd := <-commands:
            processCommand(cmd)
            continue // обработали команду — снова проверяем команды
        default:
            // команд нет — проверяем оба канала
        }

        select {
        case cmd := <-commands:
            processCommand(cmd)
        case d := <-data:
            processData(d)
        }
    }
}

Проблема: между первым и вторым select может прийти команда, и она будет обработана с задержкой.

Подход 2: Неблокирующая проверка + блокирующая

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

func priorityReader(commands chan Command, data chan Data) {
    var cmd Command
    var d Data
    var ok bool

    for {
        // Всегда пытаемся прочитать команды первыми
        select {
        case cmd = <-commands:
            processCommand(cmd)
            continue
        default:
        }

        // Нет команд — блокируемся на любом канале
        select {
        case cmd = <-commands:
            processCommand(cmd)
        case d = <-data:
            processData(d)
        }
    }
}

Подход 3: Слияние каналов с приоритетом

func mergeWithPriority(high chan int, low chan int) chan int {
    merged := make(chan int)
    go func() {
        defer close(merged)
        for high != nil || low != nil {
            select {
            case v, ok := <-high:
                if !ok {
                    high = nil
                    continue
                }
                merged <- v
            case v, ok := <-low:
                if !ok {
                    low = nil
                    continue
                }
                // Проверяем, не пришло ли что-то в high между тем,
                // как мы выбрали low
                select {
                case v2 := <-high:
                    merged <- v2
                    merged <- v // отправляем low-значение после
                default:
                    merged <- v
                }
            }
        }
    }()
    return merged
}

Подход 4: Использование буфера для приоритетных сообщений

type PriorityQueue struct {
    high chan int
    low  chan int
}

func NewPriorityQueue(highBuf, lowBuf int) *PriorityQueue {
    return &PriorityQueue{
        high: make(chan int, highBuf),
        low:  make(chan int, lowBuf),
    }
}

func (pq *PriorityQueue) Read() int {
    // Сначала проверяем high-priority буфер
    select {
    case v := <-pq.high:
        return v
    default:
    }
    // Если пуст — ждём любой
    select {
    case v := <-pq.high:
        return v
    case v := <-pq.low:
        return v
    }
}

Проблема подхода с select и default

Основная проблема — busy waiting. Если в приоритетном канале нет данных, а во второстепенном — есть, первый select с default не заблокируется, а сразу перейдёт ко второму. Но между проверками может прийти приоритетное сообщение, и оно будет обработано с задержкой.

Альтернатива: единый канал с приоритетами

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

type Message struct {
    Priority int // 0 = highest
    Payload  interface{}
}

type PriorityQueue struct {
    items []Message
    mu    sync.Mutex
    cond  *sync.Cond
    ch    chan Message
}

func NewPriorityQueue() *PriorityQueue {
    pq := &PriorityQueue{
        ch: make(chan Message, 1),
    }
    pq.cond = sync.NewCond(&pq.mu)
    go pq.process()
    return pq
}

func (pq *PriorityQueue) Push(msg Message) {
    pq.mu.Lock()
    pq.items = append(pq.items, msg)
    pq.mu.Unlock()
    pq.cond.Signal()
}

func (pq *PriorityQueue) process() {
    for {
        pq.mu.Lock()
        for len(pq.items) == 0 {
            pq.cond.Wait()
        }
        // Находим сообщение с наивысшим приоритетом
        minIdx := 0
        for i := 1; i < len(pq.items); i++ {
            if pq.items[i].Priority < pq.items[minIdx].Priority {
                minIdx = i
            }
        }
        msg := pq.items[minIdx]
        pq.items = append(pq.items[:minIdx], pq.items[minIdx+1:]...)
        pq.mu.Unlock()

        pq.ch <- msg
    }
}

func (pq *PriorityQueue) Receive() <-chan Message {
    return pq.ch
}

Итог: В рамках одного select приоритетное чтение невозможно — выбор случайный. Решение — вложенные select: сначала неблокирующая проверка приоритетного канала, затем блокирующая проверка обоих. Альтернатива — слияние каналов в один с приоритетной обработкой. Нужно помнить о возможной задержке обработки приоритетных сообщений между проверками.

Вопрос 14. Какие есть способы пробросить логгер в приложение на Go?

Таймкод: 00:29:53

Ответ собеседника: Правильный. Названы три варианта: глобальный логгер, передача через структуру, через контекст. Предпочтение отдано передаче через структуру.

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

Ответ собеседника полный и корректный. Дополним деталями и рекомендациями от команды Go.

Подход 1: Глобальный логгер

package logger

import (
    "go.uber.org/zap"
    "sync"
)

var (
    globalLogger *zap.Logger
    once         sync.Once
)

func Init(cfg Config) {
    once.Do(func() {
        var err error
        globalLogger, err = cfg.Build()
        if err != nil {
            panic(err)
        }
    })
}

func L() *zap.Logger {
    if globalLogger == nil {
        panic("logger not initialized")
    }
    return globalLogger
}

// Использование
func main() {
    logger.Init(Config{Level: "debug"})
    logger.L().Info("application started")
}

func processOrder(id string) {
    logger.L().Info("processing order", zap.String("order_id", id))
}

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

Подход 2: Передача через структуру (рекомендуемый)

package main

import (
    "context"
    "go.uber.org/zap"
)

type Logger interface {
    Info(msg string, fields ...zap.Field)
    Error(msg string, fields ...zap.Field)
    With(fields ...zap.Field) Logger
}

type OrderService struct {
    logger Logger
    repo   OrderRepository
}

func NewOrderService(logger Logger, repo OrderRepository) *OrderService {
    return &OrderService{
        logger: logger.With(zap.String("component", "order_service")),
        repo:   repo,
    }
}

func (s *OrderService) ProcessOrder(ctx context.Context, orderID string) error {
    s.logger.Info("processing order", zap.String("order_id", orderID))
    
    order, err := s.repo.FindByID(ctx, orderID)
    if err != nil {
        s.logger.Error("failed to find order",
            zap.String("order_id", orderID),
            zap.Error(err),
        )
        return err
    }
    
    // обработка...
    s.logger.Info("order processed", zap.String("order_id", orderID))
    return nil
}

Тестирование с моком:

type MockLogger struct {
    InfoCalls  []LogCall
    ErrorCalls []LogCall
}

type LogCall struct {
    Msg    string
    Fields []zap.Field
}

func (m *MockLogger) Info(msg string, fields ...zap.Field) {
    m.InfoCalls = append(m.InfoCalls, LogCall{Msg: msg, Fields: fields})
}

func (m *MockLogger) Error(msg string, fields ...zap.Field) {
    m.ErrorCalls = append(m.ErrorCalls, LogCall{Msg: msg, Fields: fields})
}

func (m *MockLogger) With(fields ...zap.Field) Logger {
    return m
}

func TestProcessOrder_Success(t *testing.T) {
    mockLogger := &MockLogger{}
    mockRepo := &MockOrderRepository{
        orders: map[string]*Order{"1": {ID: "1", Status: "pending"}},
    }
    
    service := NewOrderService(mockLogger, mockRepo)
    err := service.ProcessOrder(context.Background(), "1")
    
    assert.NoError(t, err)
    assert.Len(t, mockLogger.InfoCalls, 2)
    assert.Equal(t, "processing order", mockLogger.InfoCalls[0].Msg)
}

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

Подход 3: Через контекст

type contextKey string

const loggerKey contextKey = "logger"

func WithLogger(ctx context.Context, logger Logger) context.Context {
    return context.WithValue(ctx, loggerKey, logger)
}

func LoggerFrom(ctx context.Context) Logger {
    if logger, ok := ctx.Value(loggerKey).(Logger); ok {
        return logger
    }
    return zap.NewNop() // fallback
}

// Использование
func (s *OrderService) ProcessOrder(ctx context.Context, orderID string) error {
    logger := LoggerFrom(ctx)
    logger.Info("processing order")
    // ...
}

Плюсы: логгер доступен в любом месте, где есть контекст. Минусы: неявная зависимость (скрыта в контексте), нельзя проверить на этапе компиляции, нарушение рекомендаций Go по использованию context.WithValue.

Официальная позиция Go по context.Value:

Из документации context: > Use context Values only for request-scoped data that transits process and API boundaries, not for passing optional parameters to functions.

Логгер — не request-scoped data, а зависимость сервиса. Поэтому передача через context считается антипаттерном.

Подход 4: Функциональные опции (гибридный)

type ServiceOption func(*OrderService)

func WithLogger(logger Logger) ServiceOption {
    return func(s *OrderService) {
        s.logger = logger
    }
}

func NewOrderService(repo OrderRepository, opts ...ServiceOption) *OrderService {
    s := &OrderService{
        repo:   repo,
        logger: zap.NewNop(), // default
    }
    for _, opt := range opts {
        opt(s)
    }
    return s
}

// Использование
service := NewOrderService(repo, WithLogger(myLogger))

Сравнительная таблица:

Подход	Явность зависимостей	Тестируемость	Гибкость	Рекомендация
Глобальный	Низкая	Низкая	Низкая	Не рекомендуется
Через структуру	Высокая	Высокая	Высокая	Рекомендуется
Через контекст	Низкая	Средняя	Средняя	Не рекомендуется
Функциональные опции	Высокая	Высокая	Высокая	Рекомендуется

Итог: Рекомендуемый подход — передача логгера через конструктор структуры. Это обеспечивает явные зависимости, лёгкое тестирование с моками и возможность иметь разные логгеры для разных компонентов. Передача через context нарушает рекомендации Go и делает зависимости неявными. Глобальный логгер допустим только для небольших утилит и CLI-инструментов.

Вопрос 15. Что такое context в Go? Для чего он был создан и какие методы предоставляет?

Таймкод: 00:32:04

Ответ собеседника: Правильный. Context создан для предотвращения утечек горутин, использует канал под капотом, предоставляет методы WithCancel, WithTimeout, WithDeadline, WithValue.

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

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

Проблема, которую решает context

Без context остановка горутин — ручная работа с каналами:

// Без context — ручное управление
func worker(stop chan struct{}) {
    for {
        select {
        case <-stop:
            return
        default:
            // работа
        }
    }
}

func main() {
    stop := make(chan struct{})
    go worker(stop)
    
    // Нужно не забыть закрыть канал
    close(stop)
}

Проблемы этого подхода:

• Нужно вручную пробрасывать stop канал через все уровни вызовов
• Нет каскадной отмены (если остановить родителя, дети продолжат работать)
• Нет таймаута
• Нет единого стандарта

Context решает все эти проблемы.

Внутренняя структура context

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

Конкретные реализации:

// emptyCtx — корневой контекст (context.Background, context.TODO)
type emptyCtx int

// cancelCtx — контекст с отменой
type cancelCtx struct {
    Context
    mu       sync.Mutex
    done     chan struct{}
    children map[canceler]struct{}
    err      error
}

// timerCtx — контекст с таймером
type timerCtx struct {
    cancelCtx
    timer    *timer.Timer
    deadline time.Time
}

// valueCtx — контекст со значениями
type valueCtx struct {
    Context
    key, val any
}

Методы создания context

1. context.Background() — корневой контекст

// Используется в main, init, тестах и как корень для других контекстов
ctx := context.Background()

2. context.TODO() — заглушка

// Используется, когда не знаете, какой контекст нужен
// или пока не решили, откуда получать контекст
ctx := context.TODO()

3. context.WithCancel(parent) — ручная отмена

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

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

time.Sleep(100 * time.Millisecond)
cancel() // отменяет контекст и всех детей

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

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // всегда вызывайте cancel для освобождения ресурсов

select {
case <-ctx.Done():
    fmt.Println("timeout:", ctx.Err()) // context deadline exceeded
}

5. context.WithDeadline(parent, time) — отмена по конкретному времени

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

6. context.WithValue(parent, key, val) — проброс значений

type contextKey string

const requestIDKey contextKey = "request_id"

ctx := context.WithValue(context.Background(), requestIDKey, "abc-123")

// Получение значения
if reqID, ok := ctx.Value(requestIDKey).(string); ok {
    fmt.Println("request ID:", reqID)
}

Каскадная отмена

Главное преимущество context — автоматическая отмена всех дочерних контекстов:

func main() {
    // Корневой контекст
    rootCtx, rootCancel := context.WithCancel(context.Background())
    
    // Дочерний контекст
    childCtx, childCancel := context.WithCancel(rootCtx)
    
    // Внук
    grandchildCtx := context.WithValue(childCtx, "key", "value")
    
    go func() {
        <-grandchildCtx.Done()
        fmt.Println("grandchild cancelled:", grandchildCtx.Err())
    }()
    
    go func() {
        <-childCtx.Done()
        fmt.Println("child cancelled:", childCtx.Err())
    }()
    
    // Отмена корня автоматически отменяет ВСЕХ потомков
    rootCancel()
    
    time.Sleep(100 * time.Millisecond)
    // Output:
    // child cancelled: context canceled
    // grandchild cancelled: context canceled
    
    // childCancel() уже не нужен — childCtx отменён через rootCancel()
    _ = childCancel
}

Дерево контекстов:

context.Background()
    └── cancelCtx (rootCtx) ← rootCancel() отменяет всех
            └── cancelCtx (childCtx)
                    └── valueCtx (grandchildCtx)

Использование в HTTP-сервере

func handler(w http.ResponseWriter, r *http.Request) {
    // r.Context() автоматически отменяется при закрытии соединения
    ctx := r.Context()
    
    result, err := longRunningOperation(ctx)
    if err != nil {
        if ctx.Err() == context.Canceled {
            // клиент закрыл соединение
            return
        }
        http.Error(w, err.Error(), 500)
        return
    }
    
    w.Write(result)
}

func longRunningOperation(ctx context.Context) ([]byte, error) {
    ctx, cancel := context.WithTimeout(ctx, 10*time.Second)
    defer cancel()
    
    // Передаём контекст в БД
    rows, err := db.QueryContext(ctx, "SELECT ...")
    if err != nil {
        return nil, err
    }
    defer rows.Close()
    
    // Передаём контекст в HTTP-запрос
    req, _ := http.NewRequestWithContext(ctx, "GET", "http://api.example.com", nil)
    resp, err := http.DefaultClient.Do(req)
    // ...
}

Важные правила использования

Всегда вызывайте cancel():

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // освобождает ресурсы (таймер, горутины)

Без cancel() таймер и связанные горутины останутся в памяти до срабатывания таймаута.

Context — первый аргумент функции:

// Правило из официальной документации Go
func DoSomething(ctx context.Context, arg Arg) error {
    // ...
}

Не храните context в структурах:

// Плохо
type Server struct {
    ctx context.Context
}

// Хорошо
func (s *Server) Handle(ctx context.Context, req Request) {
    // передавайте как параметр
}

Итог: Context — стандартный механизм для отмены операций и проброса request-scoped данных. Решает проблему утечек горутин через каскадную отмену. Основные методы: Background(), TODO(), WithCancel(), WithTimeout(), WithDeadline(), WithValue(). Всегда вызывайте cancel() для освобождения ресурсов. Context должен быть первым аргументом функции, а не полем структуры.

Вопрос 16. Будет ли конфликт при использовании одинаковых ключей в context.WithValue?

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

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

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

Ответ собеседника полностью корректный. Дополним примерами и объяснением.

Проблема со строковыми ключами

// Пакет A
ctx = context.WithValue(ctx, "id", "request-123")

// Пакет B (совершенно независимый)
ctx = context.WithValue(ctx, "id", "user-456")

// Пакет A пытается получить свой "id"
val := ctx.Value("id") // "user-456" — перезаписано пакетом B!

Строковые ключи — глобальное пространство имён. Два независимых пакета могут случайно использовать одинаковую строку, и один перезапишет значение другого.

Правильное решение: пользовательский тип ключа

package requestctx

// Приватный тип — другие пакеты не могут создать значение этого типа
type contextKey string

const (
    requestIDKey contextKey = "request_id"
    userIDKey    contextKey = "user_id"
)

func WithRequestID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, requestIDKey, id)
}

func RequestID(ctx context.Context) (string, bool) {
    id, ok := ctx.Value(requestIDKey).(string)
    return id, ok
}

func WithUserID(ctx context.Context, id int64) context.Context {
    return context.WithValue(ctx, userIDKey, id)
}

func UserID(ctx context.Context) (int64, bool) {
    id, ok := ctx.Value(userIDKey).(int64)
    return id, ok
}

package auth

// Другой пакет — свой приватный тип, никаких конфликтов
type contextKey string

const (
    claimsKey contextKey = "claims" // совпадает по строке, но другой тип!
)

func WithClaims(ctx context.Context, claims *Claims) context.Context {
    return context.WithValue(ctx, claimsKey, claims)
}

func Claims(ctx context.Context) (*Claims, bool) {
    c, ok := ctx.Value(claimsKey).(*Claims)
    return c, ok
}

Почему это работает

В Go тип requestctx.contextKey и тип auth.contextKey — это разные типы, даже если у них одинаковый строковый базовый тип. context.WithValue использует interface{} как ключ, и при сравнении интерфесных значений Go учитывает как тип, так и значение:

// Это разные ключи для context
var k1 requestctx.contextKey = "id"
var k2 auth.contextKey = "id"

// При сравнении через interface{} — разные типы
fmt.Println(k1 == k2) // ошибка компиляции: разные типы

Ещё более надёжный подход: неэкспортируемый тип + экспортированные функции

package middleware

// Тип не экспортирован — никто извне не может создать ключ
type contextKey struct {
    name string
}

var (
    requestIDKey = &contextKey{name: "request_id"}
    traceIDKey   = &contextKey{name: "trace_id"}
)

func WithRequestID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, requestIDKey, id)
}

func RequestID(ctx context.Context) string {
    if v, ok := ctx.Value(requestIDKey).(string); ok {
        return v
    }
    return ""
}

Использование указателя на структуру гарантирует уникальность: даже если другой пакет создаст структуру с таким же полем name, это будет другой указатель.

Итог: Для ключей context.WithValue всегда используйте неэкспортируемый пользовательский тип (struct или string-based type). Это гарантирует отсутствие коллизий между пакетами. Строковые ключи — антипаттерн. Дополнительно рекомендуется предоставлять экспортированные функции-геттеры и сеттеры для типобезопасного доступа к значениям.

Вопрос 17. Что делают переменные окружения GOPRIVATE, GONOSUMCHECK, GONOSUMDB?

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

Ответ собеседника: Неполный. Кандидат знает про GOPRIVATE, но не смог рассказать про GONOSUMCHECK и GONOSUMDB.

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

Эти три переменные окружения связаны с безопасностью и приватностью при работе с модулями Go.

GOPRIVATE — маркер приватных модулей

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

# Один модуль
export GOPRIVATE="github.com/mycompany/internal-lib"

# Несколько модулей (через запятую)
export GOPRIVATE="github.com/mycompany/*,gitlab.team.com/shared/*"

# Все модули домена
export GOPRIVATE="*.mycompany.com"

Что делает GOPRIVATE:

• Не отправляет запросы в sum.golang.org для проверки хэшей приватных модулей
• Не использует прокси-сервер (GOPROXY) для приватных модулей — загружает напрямую из исходного репозитория
• Не проверяет наличие модуля в публичном индексе

Без GOPRIVATE при попытке загрузить приватный модуль Go попытается найти его через прокси и в sum database, что приведёт к ошибке.

GONOSUMCHECK — отключение проверки хэш-сумм

Отключает проверку контрольных сумм модулей через sum database:

export GONOSUMCHECK="github.com/mycompany/*"

Что делает GONOSUMCHECK:

• Не проверяет, что go.sum файл соответствует записям в sum.golang.org
• Не загружает хэши из sum database

Зачем нужно: приватные модули не регистрируются в sum.golang.org, поэтому проверка хэшей не имеет смысла. Без GONOSUMCHECK Go будет выдавать ошибку:

verifying github.com/mycompany/lib@v1.0.0: 
github.com/mycompany/lib@v1.0.0: no secure request available

GONOSUMDB — отключение обращения к sum database

Отключает обращение к базе данных контрольных сумм:

export GONOSUMDB="github.com/mycompany/*"

Что делает GONOSUMDB:

• Не делает запросы к sum.golang.org для указанных модулей
• Не проверяет наличие модуля в публичном индексе

Различия между тремя переменными:

Переменная	Не использует прокси	Не проверяет в sum DB	Не проверяет go.sum
GOPRIVATE	Да	Да	Да
GONOSUMDB	Нет	Да	Нет
GONOSUMCHECK	Нет	Нет	Да

Важно: GOPRIVATE автоматически включает в себя поведение GONOSUMDB и GONOSUMCHECK. Если вы установили GOPRIVATE, то GONOSUMDB и GONOSUMCHECK для этих модулей уже не нужны.

Типичная конфигурация для компании:

# .bashrc или .env файл разработчика

# Все модули компании — приватные
export GOPRIVATE="github.com/mycompany/*,gitlab.mycompany.com/*"

# Или в go.env (Go 1.21+)
# go.env автоматически загружается Go
echo 'GOPRIVATE=github.com/mycompany/*' >> $(go env GOMODCACHE)/../go.env

Настройка доступа к приватным репозиториям:

# Настройка Git для доступа к приватным репозиториям через SSH
git config --global url."git@github.com:".insteadOf "https://github.com/"

# Или через .netrc для HTTPS
machine github.com
login myuser
password ghp_xxxxxxxxxxxx

Итог: GOPRIVATE — основная переменная для работы с приватными модулями. Она автоматически отключает и прокси, и проверку сумм. GONOSUMDB и GONOSUMCHECK — более гранулярные настройки для случаев, когда нужно отключить только часть проверок. В большинстве случаев достаточно установить только GOPRIVATE.

Вопрос 18. Что делает команда go mod tidy?

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

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

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

Ответ собеседника корректный. Дополним деталями.

Что делает go mod tidy

Команда синхронизирует go.mod и go.sum с реальным исходным кодом проекта:

1. Добавляет недостающие зависимости

Если в коде есть import "github.com/some/package", но его нет в go.mod — go mod tidy найдёт последнюю версию, добавит в go.mod и загрузит модуль.

2. Удаляет неиспользуемые зависимости

Если модуль указан в go.mod, но ни один .go файл его не импортирует — он будет удалён из go.mod.

3. Обновляет go.sum

Добавляет недостающие хэш-суммы для всех зависимостей (для безопасности).

4. Добавляет косвенные зависимости

Если прямая зависимость требует другой модуль, который не указан явно, go mod tidy добавит его с помеской // indirect.

Пример работы:

// main.go
package main

import (
    "fmt"
    "github.com/gorilla/mux" // используем этот пакет
)

func main() {
    r := mux.NewRouter()
    fmt.Println(r)
}

# До go.mod tidy
$ cat go.mod
module myproject

go 1.21

require (
    github.com/some/old-package v1.0.0  # не используется в коде
)

# Запускаем tidy
$ go mod tidy

# После go.mod tidy
$ cat go.mod
module myproject

go 1.21

require (
    github.com/gorilla/mux v1.8.0      # добавлено
)

# github.com/some/old-package удалён — не используется

Когда использовать:

# После добавления новых импортов
go mod tidy

# После удаления кода с зависимостями
go mod tidy

# Перед коммитом (рекомендуется в CI)
go mod tidy && git diff --exit-code go.mod go.sum

# Если go.mod в невалидном состоянии
go mod tidy

Типичная CI-проверка:

# .github/workflows/ci.yml
- name: Check go.mod is tidy
  run: |
    go mod tidy
    git diff --exit-code go.mod go.sum

Итог: go mod tidy приводит go.mod и go.sum в соответствие с реальным кодом проекта. Добавляет недостающие зависимости, удаляет неиспользуемые, обновляет хэш-суммы. Рекомендуется запускать перед каждым коммитом и в CI.

Вопрос 19. Как запускать определённый набор тестов в Go?

Таймкод: 00:37:47

Ответ собеседника: Неполный. Кандидат не был знаком с механизмом тегов и фильтрации тестов.

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

В Go есть несколько способов запускать определённый набор тестов.

1. Флаг -run — фильтрация по имени теста

# Запустить тесты, имя которых соответствует регулярному выражению
go test -run TestMyFunction ./...

# Запустить все тесты с префиксом "Integration"
go test -run "Integration" ./...

# Запустить конкретный тест
go test -run "^TestUserService_GetUser$" ./...

# Запустить подтесты (subtests)
go test -run "TestUserService/GetUser" ./...

# Комбинация с другими флагами
go test -v -run "TestAuth" -count=1 ./...

2. Build tags — разделение тестов по файлам

Позволяет включать/исключать файлы при компиляции:

// integration_test.go
//go:build integration
// +build integration

package mypkg

import "testing"

func TestDatabaseIntegration(t *testing.T) {
    // Этот файл будет скомпилирован только с тегом integration
    db := setupTestDB()
    defer db.Close()
    
    // тестирование с реальной БД
}

// unit_test.go (без тегов — компилируется всегда)

package mypkg

import "testing"

func TestUserService_ValidateEmail(t *testing.T) {
    // Этот файл компилируется всегда
    svc := NewUserService(nil)
    err := svc.ValidateEmail("invalid")
    if err == nil {
        t.Error("expected error for invalid email")
    }
}

# Запустить только unit-тесты (по умолчанию — без тегов)
go test ./...

# Запустить только integration-тесты
go test -tags=integration ./...

# Запустить оба набора
go test -tags=integration ./...

# Несколько тегов (OR логика)
go test -tags="integration,postgres" ./...

3. Короткий режим -short

// slow_test.go
func TestExpensiveOperation(t *testing.T) {
    if testing.Short() {
        t.Skip("skipping in short mode")
    }
    
    // долгая операция
    time.Sleep(30 * time.Second)
}

# Пропустить долгие тесты
go test -short ./...

# Запустить все тесты (включая долгие)
go test ./...

4. Переменные окружения для интеграционных тестов

// integration_test.go
func TestDatabaseQuery(t *testing.T) {
    connStr := os.Getenv("TEST_DATABASE_URL")
    if connStr == "" {
        t.Skip("TEST_DATABASE_URL not set, skipping integration test")
    }
    
    db, err := sql.Open("postgres", connStr)
    // ...
}

# Запуск с переменной окружения
TEST_DATABASE_URL="postgres://localhost/test" go test ./...

5. Типичная структура проекта

mypkg/
├── service.go
├── service_test.go           # unit-тесты (всегда компилируются)
├── handler.go
├── handler_test.go           # unit-тесты
└── integration_test.go       #go:build integration — интеграционные тесты

6. Makefile для удобства:

.PHONY: test test-unit test-integration

test-unit:
	go test -v -short -count=1 ./...

test-integration:
	go test -v -tags=integration -count=1 ./...

test: test-unit test-integration

7. Флаг -count — отключение кэширования тестов

# Запустить тесты, игнорируя кэш
go test -count=1 ./...

По умолчанию Go кэширует результаты успешных тестов. -count=1 отключает кэш.

Итог: Основные способы фильтрации тестов: флаг -run с регулярным выражением по имени, build tags для разделения по файлам (например, //go:build integration), флаг -short для пропуска долгих тестов, и переменные окружения для условного запуска. Build tags — рекомендуемый подход для разделения unit и integration тестов.

Вопрос 20. Что такое fuzzing (фаззинг) в Go?

Таймкод: 00:39:58

Ответ собеседника: Неполный. Кандидат имеет общее представление, но не знает деталей и не имеет практического опыта.

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

Что такое fuzzing

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

Встроенный фаззинг в Go (с Go 1.18+)

Go имеет встроенную поддержку фаззинга через testing.F:

package parser

import (
    "testing"
    "strconv"
)

func ParseNumber(s string) (int, error) {
    return strconv.Atoi(s)
}

// Обычный unit-тест
func TestParseNumber(t *testing.T) {
    result, err := ParseNumber("42")
    if err != nil || result != 42 {
        t.Errorf("expected 42, got %d, err: %v", result, err)
    }
}

// Fuzzing-тест
func FuzzParseNumber(f *testing.F) {
    // Seed corpus — начальные входные данные
    f.Add("0")
    f.Add("42")
    f.Add("-1")
    f.Add("999999999")
    f.Add("not a number")
    f.Add("")
    
    f.Fuzz(func(t *testing.T, input string) {
        // Функция не должна паниковать на любом входе
        result, err := ParseNumber(input)
        
        // Инварианты — свойства, которые всегда должны выполняться
        if err == nil {
            // Если парсинг успешен — обратное преобразование должно совпадать
            back := strconv.Itoa(result)
            if back != input && input != "0" && !strings.HasPrefix(input, "+") {
                // Проверка инварианта
            }
        }
    })
}

Запуск фаззинга:

# Запуск фаззинга (по умолчанию — до прерывания Ctrl+C)
go test -fuzz=FuzzParseNumber ./...

# Запуск с ограничением по времени
go test -fuzz=FuzzParseNumber -fuzztime=30s ./...

# Запуск с ограничением по количеству итераций
go test -fuzz=FuzzParseNumber -fuzztime=100x ./...

# Запуск конкретного тестового случая (для воспроизведения бага)
go test -run=FuzzParseNumber/abc123def ./...

Seed corpus и кэш фаззинга

Go сохраняет сгенерированные тестовые случаи, которые увеличивают покрытие:

testdata/fuzz/FuzzParseNumber/
├── 582811e9d1a41a8f   <- найденный баг (crash)
├── corpus1
├── corpus2
└── ...

Пример: фаззинг парсера

func FuzzParseJSON(f *testing.F) {
    // Seed corpus — валидные JSON-примеры
    f.Add(`{"name": "John", "age": 30}`)
    f.Add(`[1, 2, 3]`)
    f.Add(`"hello"`)
    f.Add(`42`)
    f.Add(`true`)
    f.Add(`null`)
    f.Add(`{}`)
    f.Add(`[]`)
    
    f.Fuzz(func(t *testing.T, input string) {
        var result interface{}
        err := json.Unmarshal([]byte(input), &result)
        
        if err == nil {
            // Если распарсили успешно — сериализация не должна паниковать
            _, marshalErr := json.Marshal(result)
            if marshalErr != nil {
                t.Errorf("Marshal failed for valid JSON: %v, input: %s", marshalErr, input)
            }
        }
    })
}

Пример: фаззинг сетевого протокола

func FuzzParseHTTPRequest(f *testing.F) {
    f.Add("GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")
    f.Add("POST /api/data HTTP/1.1\r\nContent-Length: 5\r\n\r\nhello")
    
    f.Fuzz(func(t *testing.T, input string) {
        reader := strings.NewReader(input)
        // Парсер не должен паниковать на любом входе
        _, err := http.ReadRequest(bufio.NewReader(reader))
        // Мы не проверяем err — ожидаем, что некорректный ввод вернёт ошибку
        // Но НЕ должен вызвать панику
    })
}
**

**Ключи к эффективному фаззингу:**

**1. Хороший seed corpus:**
```go
f.Add("typical input")
f.Add("edge case")
f.Add("")           // пустая строка
f.Add("0")          // zero value
f.Add(string(make([]byte, 10000))) // большой ввод

2. Проверка инвариантов:

f.Fuzz(func(t *testing.T, input string) \{
    result, err := MyFunction(input)
    
    // Инвариант 1: нет паник (проверяется автоматически)
    // Инвариант 2: если нет ошибки — результат валиден
    if err == nil \{
        if !isValid(result) \{
            t.Errorf("invalid result for input: %q", input)
        \}
    \}
    
    // Инвариант 3: идемпотентность
    result2, err2 := MyFunction(input)
    if err == err2 && !reflect.DeepEqual(result, result2) \{
        t.Errorf("non-deterministic result")
    \}
\})

Ограничения фаззинга в Go:

• Фаззинг не может проверять бизнес-логику — только находить паники и нарушения инвариантов
• Требует времени для нахождения багов
• Не заменяет unit-тесты, а дополняет их
• Каждый параметр фаззируемой функции должен быть из набора поддерживаемых типов: string, []byte, int, int8-int64, uint, uint8-uint64, float32, float64, bool

Итог: Fuzzing в Go — встроенный механизм автоматической генерации тестовых данных для обнаружения паник и нарушений инвариантов. Реализуется через testing.F и запускается командой go test -fuzz=.... Требует seed corpus (начальных данных) и проверки инвариантов. Особенно полезен для тестирования парсеров, сетевых протоколов и функций, обрабатывающих недоверенные входные данные.

Вопрос 21. Как локально профилировать и удалённо отлаживать приложение на Go?

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

Ответ собеседника: Правильный. Назван pprof для локальной отладки и выставление pprof-эндпоинтов для удалённой.

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

Ответ собеседника корректный. Дополним деталями и примерами.

Локальное профилирование с pprof

1. Инструментирование кода:

package main

import (
    "net/http"
    _ "net/http/pprof" // регистрирует эндпоинты /debug/pprof/*
    "log"
)

func main() {
    // pprof эндпоинты на отдельном порту (безопаснее)
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()
    
    // основное приложение
    http.ListenAndServe(":8080", handler)
}

2. Снятие профилей из командной строки:

# CPU профиль (30 секунд)
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# Heap профиль (аллокации в памяти)
go tool pprof http://localhost:6060/debug/pprof/heap

# Goroutine профиль
go tool pprof http://localhost:6060/debug/pprof/goroutine

# Block профиль (блокировки)
go tool pprof http://localhost:6060/debug/pprof/block

# Mutex профиль (конкуренция за мьютексы)
go tool pprof http://localhost:6060/debug/pprof/mutex

# Allocs профиль (все аллокации с момента старта)
go tool pprof http://localhost:6060/debug/pprof/allocs

3. Анализ в интерактивном режиме pprof:

# После подключения к профилю попадаем в интерактивный режим
(pprof) top          # топ функций по CPU/памяти
(pprof) top 20       # топ-20
(pprof) list main.   # листинг функций с аннотациями
(pprof) web          # открыть граф в браузере (требуется graphviz)
(pprof) png          # сохранить граф как PNG
(pprof) pdf          # сохранить как PDF
(pprof) traces       # показать трейсы

4. Программное создание профилей:

import (
    "os"
    "runtime/pprof"
)

func captureCPUProfile(filename string, duration time.Duration) error {
    f, err := os.Create(filename)
    if err != nil {
        return err
    }
    defer f.Close()
    
    if err := pprof.StartCPUProfile(f); err != nil {
        return err
    }
    defer pprof.StopCPUProfile()
    
    time.Sleep(duration)
    return nil
}

func captureHeapProfile(filename string) error {
    f, err := os.Create(filename)
    if err != nil {
        return err
    }
    defer f.Close()
    
    return pprof.WriteHeapProfile(f)
}

// Использование
captureCPUProfile("cpu.prof", 30*time.Second)
captureHeapProfile("heap.prof")

5. Анализ файлов профилей:

# Анализ сохранённого файла
go tool pprof cpu.prof
go tool pprof heap.prof

# Сравнение двух профилей (до и после оптимизации)
go tool pprof -base before.prof after.prof

Удалённое профилирование

1. Безопасная настройка — отдельный порт:

func main() {
    // Основной HTTP-сервер (публичный)
    publicMux := http.NewServeMux()
    publicMux.HandleFunc("/api/", apiHandler)
    
    // pprof сервер (только внутренний)
    internalMux := http.NewServeMux()
    internalMux.HandleFunc("/debug/pprof/", pprof.Index)
    internalMux.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
    internalMux.HandleFunc("/debug/pprof/profile", pprof.Profile)
    internalMux.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
    internalMux.HandleFunc("/debug/pprof/trace", pprof.Trace)
    
    // Слушаем на localhost — доступен только с той же машины
    go func() {
        log.Fatal(http.ListenAndServe("localhost:6060", internalMux))
    }()
    
    log.Fatal(http.ListenAndServe(":8080", publicMux))
}

2. Доступ через SSH-туннель:

# Создаём туннель к удалённому серверу
ssh -L 6060:localhost:6060 user@remote-server

# Теперь pprof доступен локально
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

3. Доступ через kubectl port-forward (Kubernetes):

# Пробрасываем порт из пода
kubectl port-forward pod/my-app-xyz 6060:6060

# Анализируем локально
go tool pprof http://localhost:6060/debug/pprof/heap

4. Визуализация через web-интерфейс:

# Открыть веб-интерфейс pprof в браузере
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap

Откроется браузер с интерактивными графами: flame graph, call graph, source view.

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

Проблема	Профиль	Что искать
Высокая CPU нагрузка	profile	Функции с наибольшим временем выполнения
Утечка памяти	heap	Объекты, которые не освобождаются
Утечка горутин	goroutine	Горутины, застрявшие в одном состоянии
Проблемы с блокировками	block	Каналы и мьютексы с долгим ожиданием
Конкуренция за мьютексы	mutex	Мьютексы с высокой конкуренцией

Итог: net/http/pprof — стандартный инструмент профилирования Go. Для локальной отладки — поднимаем эндпоинты на localhost и используем go tool pprof. Для удалённой — SSH-туннель или kubectl port-forward. Ключевые профили: profile (CPU), heap (память), goroutine (горутины), block (блокировки). Визуализация через go tool pprof -http=:8080.

Вопрос 22. Как понять, где тормозит в распределённой системе из нескольких сервисов?

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

Ответ собеседника: Правильный. Назван distributed tracing и Jaeger. Не имеет глубокого практического опыта.

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

Ответ собеседника корректный. Дополним деталями и примерами.

Distributed Tracing — основной инструмент

Distributed tracing позволяет отследить путь запроса через все сервисы системы и увидеть, сколько времени каждая операция занимает.

Ключевые понятия:

• Trace — полный путь одного запроса через все сервисы
• Span — одна операция внутри trace (HTTP-запрос, запрос к БД, вызов внешнего API)
• TraceID — уникальный идентификатор запроса, пробрасывается через все сервисы
• ParentSpanID — ссылка на родительский span

TraceID: abc123
├── Span: API Gateway (total: 250ms)
│   ├── Span: Auth Service (50ms)
│   │   └── Span: Redis GET (5ms)
│   ├── Span: Order Service (180ms) ← БОТТЛНЕК
│   │   ├── Span: PostgreSQL SELECT (150ms) ← МЕДЛЕННЫЙ ЗАПРОС
│   │   └── Span: Inventory Service (20ms)
│   └── Span: Response (20ms)

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

Инструмент	Особенности
Jaeger	CNCF, полноценная система трейсинга
Zipkin	Twitter, проще в настройке
Grafana Tempo	Интеграция с Grafana, хранение в S3/GCS
OpenTelemetry	Стандарт инструментирования (не бэкенд трейсинга)

OpenTelemetry — стандарт инструментирования

OpenTelemetry (OTel) — это стандарт для сбора трейсов, метрик и логов. Он не зависит от конкретного бэкенда:

package main

import (
    "context"
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/attribute"
    "go.opentelemetry.io/otel/exporters/jaeger"
    "go.opentelemetry.io/otel/sdk/resource"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
    semconv "go.opentelemetry.io/otel/semconv/v1.17.0"
)

func initTracer() (*sdktrace.TracerProvider, error) {
    // Экспорт в Jaeger
    exp, err := jaeger.New(jaeger.WithCollectorEndpoint(
        jaeger.WithEndpoint("http://jaeger:14268/api/traces"),
    ))
    if err != nil {
        return nil, err
    }
    
    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(exp),
        sdktrace.WithResource(resource.NewWithAttributes(
            semconv.SchemaURL,
            semconv.ServiceName("order-service"),
        )),
    )
    
    otel.SetTracerProvider(tp)
    return tp, nil
}

func main() {
    tp, err := initTracer()
    if err != nil {
        log.Fatal(err)
    }
    defer tp.Shutdown(context.Background())
    
    tracer := otel.Tracer("order-service")
    
    // Создание span
    ctx, span := tracer.Start(context.Background(), "process-order")
    defer span.End()
    
    // Добавление атрибутов
    span.SetAttributes(
        attribute.String("order.id", "123"),
        attribute.String("user.id", "456"),
    )
    
    // Проброс контекста в другие вызовы
    result, err := processOrder(ctx, "123")
    if err != nil {
        span.RecordError(err)
        span.SetStatus(codes.Error, "failed to process order")
    }
}

Проброс TraceID через HTTP:

// Middleware для извлечения/создания TraceID
func TracingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        tracer := otel.Tracer("http-server")
        
        // Извлекаем контекст из заголовков (или создаём новый)
        ctx := otel.GetTextMapPropagator().Extract(
            r.Context(),
            propagation.HeaderCarrier(r.Header),
        )
        
        // Создаём span
        ctx, span := tracer.Start(ctx, r.Method+" "+r.URL.Path)
        defer span.End()
        
        // Пробрасываем контекст дальше
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// HTTP-клиент с пробросом TraceID
func callInventoryService(ctx context.Context, itemID string) error {
    tracer := otel.Tracer("http-client")
    ctx, span := tracer.Start(ctx, "call-inventory-service")
    defer span.End()
    
    req, _ := http.NewRequestWithContext(ctx, "GET",
        "http://inventory-service/api/items/"+itemID, nil)
    
    // Внедряем TraceID в заголовки
    otel.GetTextMapPropagator().Inject(
        ctx,
        propagation.HeaderCarrier(req.Header),
    )
    
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        span.RecordError(err)
        return err
    }
    defer resp.Body.Close()
    
    return nil
}

Проброс TraceID через gRPC:

// gRPC interceptor для трейсинга
func UnaryServerInterceptor() grpc.UnaryServerInterceptor {
    return func(
        ctx context.Context,
        req interface{},
        info *grpc.UnaryServerInfo,
        handler grpc.UnaryHandler,
    ) (interface{}, error) {
        tracer := otel.Tracer("grpc-server")
        
        ctx, span := tracer.Start(ctx, info.FullMethod)
        defer span.End()
        
        resp, err := handler(ctx, req)
        if err != nil {
            span.RecordError(err)
        }
        return resp, err
    }
}

Что искать в трейсах:

• Длинные spans — операции, занимающие непропорционально много времени
• Глубокие деревья — избыточные вызовы между сервисами
• Параллельные spans — возможности для оптимизации (сделать параллельно)
• Ошибки — spans с ошибками, ретрии

Дополнительные инструменты:

• Метрики (Prometheus + Grafana) — для общей картины: latency percentiles, error rates, throughput
• Логи (ELK/Loki) — для детального анализа конкретных запросов
• Профилирование (pprof) — для анализа внутри конкретного сервиса

Итог: Distributed tracing — основной инструмент для анализа производительности распределённых систем. OpenTelemetry — стандарт инструментирования, Jaeger/Tempo/Zipkin — бэкенды для хранения и визуализации. TraceID пробрасывается через HTTP-заголовки или gRPC-метаданные. В трейсах ищем длинные spans, глубокие деревья вызовов и ошибки.

Вопрос 23. Зачем нужны метрики и как организовать сбор метрик с разных слоёв приложения?

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

Ответ собеседника: Неполный. Кандидат предложил контекст и канал с горутиной, но не знаком с Prometheus и стандартным подходом.

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

Ответ собеседника содержит рабочие идеи, но не описывает стандартный подход с Prometheus.

Зачем нужны метрики

Метрики — это числовые показатели состояния системы во времени. Они нужны для:

• Мониторинг здоровья — работает ли сервис, сколько запросов, какая ошибка
• Алертинг — уведомления при отклонении от нормы
• Capacity planning — прогнозирование роста нагрузки
• Отладка — понимание, что происходило до инцидента
• SLA/SLO — измерение соблюдения соглашений об уровне обслуживания

Типы метрик:

Тип	Описание	Пример
Counter	Только растёт	Количество запросов, ошибок
Gauge	Растёт и уменьшается	Текущее количество горутин, размер очереди
Histogram	Распределение значений	Время ответа (percentiles)
Summary	Квантили	Аналог histogram, но на стороне клиента

Стандартный подход: Prometheus + prometheus/client_golang

package metrics

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

var (
    // HTTP метрики
    httpRequestsTotal = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "path", "status"},
    )
    
    httpRequestDuration = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "http_request_duration_seconds",
            Help:    "HTTP request duration in seconds",
            Buckets: prometheus.DefBuckets, // 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10
        },
        []string{"method", "path"},
    )
    
    // Бизнес-метрики
    ordersProcessedTotal = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "orders_processed_total",
            Help: "Total number of processed orders",
        },
        []string{"status"}, // success, failed, cancelled
    )
    
    // Метрики кэша
    cacheHits = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "cache_hits_total",
            Help: "Total cache hits",
        },
        []string{"cache_name"},
    )
    
    cacheMisses = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "cache_misses_total",
            Help: "Total cache misses",
        },
        []string{"cache_name"},
    )
    
    // Метрики БД
    dbQueryDuration = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "db_query_duration_seconds",
            Help:    "Database query duration",
            Buckets: prometheus.DefBuckets,
        },
        []string{"operation", "table"}, // SELECT, INSERT / users, orders
    )
    
    dbConnectionsInUse = promauto.NewGauge(
        prometheus.GaugeOpts{
            Name: "db_connections_in_use",
            Help: "Current number of DB connections in use",
        },
    )
)

HTTP middleware для сбора метрик:

func MetricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        
        // Оборачиваем ResponseWriter для перехвата статуса
        wrapped := &responseWriter{ResponseWriter: w, statusCode: 200}
        
        next.ServeHTTP(wrapped, r)
        
        duration := time.Since(start).Seconds()
        status := strconv.Itoa(wrapped.statusCode)
        
        httpRequestsTotal.WithLabelValues(r.Method, r.URL.Path, status).Inc()
        httpRequestDuration.WithLabelValues(r.Method, r.URL.Path).Observe(duration)
    })
}

type responseWriter struct {
    http.ResponseWriter
    statusCode int
}

func (rw *responseWriter) WriteHeader(code int) {
    rw.statusCode = code
    rw.ResponseWriter.WriteHeader(code)
}

Метрики на уровне сервисного слоя:

type OrderService struct {
    repo   OrderRepository
    cache  Cache
}

func (s *OrderService) ProcessOrder(ctx context.Context, order Order) error {
    start := time.Now()
    defer func() {
        dbQueryDuration.WithLabelValues("INSERT", "orders").Observe(time.Since(start).Seconds())
    }()
    
    err := s.repo.Save(ctx, order)
    if err != nil {
        ordersProcessedTotal.WithLabelValues("failed").Inc()
        return err
    }
    
    ordersProcessedTotal.WithLabelValues("success").Inc()
    return nil
}

Метрики кэша:

type InstrumentedCache struct {
    inner Cache
}

func (c *InstrumentedCache) Get(ctx context.Context, key string) ([]byte, error) {
    val, err := c.inner.Get(ctx, key)
    if err == nil {
        cacheHits.WithLabelValues("main").Inc()
    } else {
        cacheMisses.WithLabelValues("main").Inc()
    }
    return val, err
}

Метрики пула соединений с БД:

import (
    "database/sql"
    "github.com/prometheus/client_golang/prometheus"
)

func RecordDBStats(db *sql.DB, dbName string) {
    go func() {
        for {
            stats := db.Stats()
            
            dbConnectionsInUse.Set(float64(stats.InUse))
            
            time.Sleep(10 * time.Second)
        }
    }()
}

Экспорт метрик через HTTP:

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

func main() {
    mux := http.NewServeMux()
    
    // Эндпоинт для Prometheus
    mux.Handle("/metrics", promhttp.Handler())
    
    // Основные эндпоинты
    mux.Handle("/api/", MetricsMiddleware(apiHandler))
    
    log.Fatal(http.ListenAndServe(":8080", mux))
}

Конфигурация Prometheus:

# prometheus.yml
scrape_configs:
  - job_name: 'order-service'
    scrape_interval: 15s
    static_configs:
      - targets: ['order-service:8080']
  
  - job_name: 'user-service'
    scrape_interval: 15s
    static_configs:
      - targets: ['user-service:8080']

Примеры алертов (Prometheus Alertmanager):

# alerts.yml
groups:
  - name: http
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          
      - alert: HighLatency
        expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "95th percentile latency > 2s"

Итог: Стандартный подход — Prometheus для сбора и хранения метрик, Grafana для визуализации. Библиотека prometheus/client_golang предоставляет все типы метрик. Метрики собираются на каждом слое: HTTP (middleware), сервисный слой (обёртки), кэш (instrumented wrapper), БД (stats). Алерты настраиваются через Alertmanager. Подход с каналом и горутиной от собеседника тоже рабочий, но изобретает велосипед — лучше использовать стандартные инструменты.

Вопрос 24. Что такое шардинг данных и какие виды шардинга существуют?

Таймкод: 00:50:06

Ответ собеседника: Неполный. Кандидат имеет общее представление, но не знает конкретных видов шардинга.

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

Что такое шардинг

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

Виды шардинга

1. Горизонтальный шардинг (Horizontal Sharding / Partitioning)

Строки одной таблицы распределяются между несколькими серверами:

┌─────────────────────┐      ┌─────────────────┐  ┌─────────────────┐
│  Все пользователи   │      │  Шар 1          │  │  Шар 2          │
│                     │      │  user_id: 1-1M  │  │  user_id: 1M-2M │
│  id | name | email  │ ──►  │                 │  │                 │
│  1  | John | ...    │      │  1  | John | ...│  │  1000001 | ...  │
│  2  | Jane | ...    │      │  2  | Jane | ...│  │  1000002 | ...  │
│  ...                │      │  ...            │  │  ...            │
└─────────────────────┘      └─────────────────┘  └─────────────────┘

2. Вертикальный шардинг (Vertical Sharding)

Столбцы таблицы распределяются между серверами. Разные группы таблиц живут на разных серверах:

┌──────────────────────────┐      ┌──────────────────┐  ┌──────────────────┐
│  Все данные              │      │  Сервер 1        │  │  Сервер 2        │
│                          │      │  (Профили)       │  │  (Заказы)        │
│  users | orders | items  │ ──►  │  users           │  │  orders          │
│                          │      │  profiles        │  │  items           │
└──────────────────────────┘      └──────────────────┘  └──────────────────┘

Стратегии горизонтального шардинга

A. Шардинг по диапазону (Range-based Sharding)

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

-- Шар 1: user_id 1 - 1,000,000
-- Шар 2: user_id 1,000,001 - 2,000,000
-- Шар 3: user_id 2,000,001 - 3,000,000

-- Определение шара
SELECT CASE
    WHEN user_id BETWEEN 1 AND 1000000 THEN 'shard_1'
    WHEN user_id BETWEEN 1000001 AND 2000000 THEN 'shard_2'
    WHEN user_id BETWEEN 2000001 AND 3000000 THEN 'shard_3'
END AS shard_name;

Плюсы: простые range-запросы (WHERE user_id BETWEEN 100 AND 200). Минусы: неравномерное распределение (hot spots), нужна ребалансировка.

B. Шардинг по хешу (Hash-based Sharding)

Хеш-функция от ключа определяет шар:

func GetShardID(userID int64, totalShards int) int {
    return int(userID) % totalShards
}

func GetShard(userID int64) *sql.DB {
    shardID := GetShardID(userID, 4)
    return shards[shardID]
}

// Пример:
// user_id=1 → shard 1
// user_id=2 → shard 2
// user_id=3 → shard 3
// user_id=4 → shard 0
// user_id=5 → shard 1

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

C. Шардинг по словарю (Directory-based Sharding)

Отображение ключей на шары хранится в отдельной таблице-справочнике:

CREATE TABLE shard_mapping (
    entity_type VARCHAR(50),
    entity_id   BIGINT,
    shard_name  VARCHAR(50),
    PRIMARY KEY (entity_type, entity_id)
);

-- Запрос к справочнику
SELECT shard_name FROM shard_mapping
WHERE entity_type = 'user' AND entity_id = 12345;

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

D. Географический шардинг (Geo-sharding)

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

func GetShardByRegion(userRegion string) *sql.DB {
    switch userRegion {
    case "EU":
        return euShard
    case "US":
        return usShard
    case "ASIA":
        return asiaShard
    default:
        return defaultShard
    }
}

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

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

Решает проблему ребалансировки при добавлении/удалении шаров:

// Упрощённая реализация консистентного хеширования
type ConsistentHash struct {
    ring       map[uint32]string // хеш -> имя ноды
    sortedKeys []uint32          // отсортированные хеши
    replicas   int               // количество виртуальных нод на реальную ноду
}

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++ {
        hash := ch.hash(fmt.Sprintf("%s:%d", node, i))
        ch.ring[hash] = node
        ch.sortedKeys = append(ch.sortedKeys, hash)
    }
    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]]
}

При добавлении новой ноды перемещается только 1/N данных, а не все данные перераспределяются.

Проблемы шардинга

• Cross-shard запросы — JOIN между шарами невозможен или очень дорог
• Ребалансировка — добавление шаров требует миграции данных
• Транзакции — распределённые транзакции сложны и медленны
• Согласованность — обеспечение консистентности между шарами
• Выбор ключа шардирования — неправильный выбор приводит к hot spots

Шардинг в PostgreSQL

PostgreSQL поддерживает партиционирование (встроенный шардинг на уровне таблицы):

-- Создание партиционированной таблицы
CREATE TABLE orders (
    id          BIGSERIAL,
    user_id     BIGINT NOT NULL,
    amount      DECIMAL(10,2),
    created_at  TIMESTAMP NOT NULL
) PARTITION BY RANGE (created_at);

-- Создание партиций
CREATE TABLE orders_2024_q1 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-04-01');

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

-- Запрос автоматически идёт в нужную партицию
EXPLAIN SELECT * FROM orders WHERE created_at = '2024-02-15';
-- ->  Seq Scan on orders_2024_q1

Итог: Шардинг — горизонтальное разделение данных между серверами. Основные виды: горизонтальный (строки по серверам), вертикальный (таблицы по серверам). Стратегии: по диапазону, по хешу, по словарю, географический. Консистентное хеширование минимизирует ребалансировку. Главные проблемы: cross-shard запросы, распределённые транзакции, выбор ключа шардирования.

Вопрос 25. Что такое репликация данных и какие виды репликации существуют?

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

Ответ собеседника: Неполный. Названы master-slave, master-master, синхронная/асинхронная, кворум. Нет глубокого понимания.

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

Что такое репликация

Репликация — это механизм копирования данных между несколькими узлами (серверами БД) для обеспечения отказоустойчивости, масштабирования чтения и географического распределения данных.

Топологии репликации

1. Primary-Secondary (Master-Slave)

Один узел (primary) принимает запись, реплики (secondary) копируют данные и обслуживают чтение:

        Writes
          │
          ▼
    ┌───────────┐
    │  Primary   │
    │  (Master)  │
    └─────┬─────┘
          │ replication
    ┌─────┼─────┐
    ▼     ▼     ▼
┌──────┐┌──────┐┌──────┐
│Secondary││Secondary││Secondary│
│  (R)  ││  (R)  ││  (R)  │
└──────┘└──────┘└──────┘

• Запись идёт только на primary
• Чтение распределяется между secondary
• При падении primary — ручное или автоматическое переключение (failover)

2. Primary-Primary (Multi-Master)

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

    ┌──────────┐  replication  ┌──────────┐
    │ Primary  │◄────────────►│ Primary  │
    │  (RW)    │               │  (RW)    │
    └────┬─────┘               └────┬─────┘
         │                          │
    ┌────▼─────┐               ┌────▼─────┐
    │Secondary │               │Secondary │
    └──────────┘               └──────────┘

• Оба узла принимают запись
• Сложности с конфликтами при одновременной записи одних данных
• Требует механизма разрешения конфликтов (CRDT, last-write-wins)

3. Ring / Circular Replication

┌────────┐    ┌────────┐    ┌────────┐
│ Node A │───►│ Node B │───►│ Node C │
└────────┘    └────────┘    └────────┘
    ▲                            │
    └────────────────────────────┘

Каждый узел реплицирует данные следующему в кольце.

Режимы репликации

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

Транзакция подтверждается только после записи на primary И все реплики:

Client ──WRITE──► Primary ──replicate──► Secondary 1 (ack)
                                    └──► Secondary 2 (ack)
                                    └──► Secondary 3 (ack)
                                              │
Client ◄──────────────────────────────────────┘

Плюсы: гарантированная консистентность, никакие данные не теряются. Минусы: высокая латентность, сбой одной реплики блокирует запись.

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

Транзакция подтверждается после записи на primary, репликация происходит в фоне:

Client ──WRITE──► Primary ──► ACK to Client
                        │
                        └──► (async) ──► Secondary 1
                                  └──► Secondary 2

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

3. Полусинхронная (Semi-synchronous) репликация

Гибрид: primary ждёт подтверждения от хотя бы одной реплики:

Client ──WRITE──► Primary ──replicate──► Secondary 1 (ack ✓)
                                    └──► Secondary 2 (ждём...)
                                    └──► Secondary 3 (ждём...)
                                              │
Client ◄──────────────────────────────────────┘
(после первого ack)

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

Кворумная репликация

Запись подтверждается при получении большинства (кворума) подтверждений:

// Псевдокод кворумной записи
func QuorumWrite(data Record, replicas []Replica) error {
    totalNodes := len(replicas) // например, 5
    quorum := totalNodes/2 + 1  // кворум = 3
    
    acks := 0
    errors := make(chan error, totalNodes)
    
    for _, replica := range replicas {
        go func(r Replica) {
            err := r.Write(data)
            if err == nil {
                acks++
            }
            errors <- err
        }(replica)
    }
    
    // Ждём кворума
    for i := 0; i < totalNodes; i++ {
        if acks >= quorum {
            return nil // успех
        }
        if err := <-errors; err != nil {
            log.Printf("replica error: %v", err)
        }
    }
    
    return fmt.Errorf("quorum not reached: %d/%d", acks, quorum)
}

Формула: W + R > N, где:

• N — общее количество реплик
• W — количество подтверждений для записи
• R — количество подтверждений для чтения

Примеры конфигураций:

• N=3, W=2, R=2 — сильная консистентность
• N=3, W=1, R=1 — высокая доступность, слабая консистентность
• N=3, W=3, R=1 — запись на все, чтение с одной

Replication lag (лаг репликации)

Время между записью на primary и появлением данных на реплике:

Timeline:
Primary:  W1 ──► W2 ──► W3 ──► W4
Secondary: ──► W1 ──► W2 ──► W3 (W4 ещё не дошла)
                        ▲
                    replication lag

Проблемы лага:

• Чтение устаревших данных (stale reads)
• Нарушение причинно-следственных связей
• Конфликты при переключении primary

Реализации в разных СУБД:

СУБД	Тип репликации	Особенности
PostgreSQL	Streaming replication	WAL-based, async/semi-sync
MySQL	Binary log replication	Row/Statement/Mixed format
MongoDB	Replica sets	Автоматический failover, oplog
CockroachDB	Multi-Paft (Raft)	Синхронная, кворумная
Redis	Async replication	PSYNC, partial resync

Итог: Репликация — копирование данных между узлами для отказоустойчивости и масштабирования. Топологии: primary-secondary (запись на один узел), primary-primary (запись на несколько). Режимы: синхронная (ждём все реплики), асинхронная (не ждём), полусинхронная (ждём хотя бы одну). Кворумная репликация требует подтверждения большинства узлов. Основная проблема асинхронной репликации — replication lag и возможная потеря данных.

Вопрос 26. Как организовать подключение к базам данных при разделении на master (запись) и slave (чтение)?

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

Ответ собеседника: Неполный. Предложил два пула соединений и два репозитория, но не предложил абстракцию для прозрачности.

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

Задача — сделать разделение read/write прозрачным для бизнес-логики, чтобы при изменении инфраструктуры (переход на одну БД, добавление шардов) не приходилось переписывать код.

Подход 1: Интерфейс с двумя реализациями

package database

import (
    "context"
    "database/sql"
)

// DB — единый интерфейс для работы с БД
type DB interface {
    QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error)
    QueryRowContext(ctx context.Context, query string, args ...interface{}) *sql.Row
    ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error)
    BeginTx(ctx context.Context, opts *sql.TxOptions) (*sql.Tx, error)
}

// ReadWriteDB — маркерный интерфейс для полного доступа
type ReadWriteDB interface {
    DB
    // Дополнительные методы для записи
}

// ReadOnlyDB — маркерный интерфейс только для чтения
type ReadOnlyDB interface {
    DB
}

Подход 2: Database Router — маршрутизация запросов

package database

import (
    "context"
    "database/sql"
)

type QueryType int

const (
    QueryRead  QueryType = iota
    QueryWrite
)

type Router interface {
    GetDB(ctx context.Context, qt QueryType) *sql.DB
}

type MasterSlaveRouter struct {
    master *sql.DB
    slaves []*sql.DB
    rr     int // round-robin counter
}

func NewMasterSlaveRouter(master *sql.DB, slaves []*sql.DB) *MasterSlaveRouter {
    return &MasterSlaveRouter{
        master: master,
        slaves: slaves,
    }
}

func (r *MasterSlaveRouter) GetDB(ctx context.Context, qt QueryType) *sql.DB {
    switch qt {
    case QueryWrite:
        return r.master
    case QueryRead:
        if len(r.slaves) == 0 {
            return r.master
        }
        // Round-robin между слейвами
        idx := atomic.AddInt32(&r.rr, 1) % int32(len(r.slaves))
        return r.slaves[idx]
    default:
        return r.master
    }
}

Подход 3: Автоматическая маршрутизация через обёртку

package database

import (
    "context"
    "database/sql"
    "strings"
    "sync/atomic"
)

type DB struct {
    master *sql.DB
    slaves []*sql.DB
    rr     int32
}

func NewDB(master *sql.DB, slaves ...*sql.DB) *DB {
    return &DB{
        master: master,
        slaves: slaves,
    }
}

func (db *DB) readDB() *sql.DB {
    if len(db.slaves) == 0 {
        return db.master
    }
    idx := atomic.AddInt32(&db.rr, 1) % int32(len(db.slaves))
    return db.slaves[idx]
}

func (db *DB) writeDB() *sql.DB {
    return db.master
}

// QueryContext — автоматически идёт на read replica
func (db *DB) QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error) {
    return db.readDB().QueryContext(ctx, query, args...)
}

// QueryRowContext — автоматически идёт на read replica
func (db *DB) QueryRowContext(ctx context.Context, query string, args ...interface{}) *sql.Row {
    return db.readDB().QueryRowContext(ctx, query, args...)
}

// ExecContext — автоматически идёт на master
func (db *DB) ExecContext(ctx context.Context, query string, args ...interface{}) (sql.Result, error) {
    return db.writeDB().ExecContext(ctx, query, args...)
}

// BeginTx — всегда на master
func (db *DB) BeginTx(ctx context.Context, opts *sql.TxOptions) (*sql.Tx, error) {
    return db.writeDB().BeginTx(ctx, opts)
}

// Close закрывает все соединения
func (db *DB) Close() error {
    var errs []error
    
    if err := db.master.Close(); err != nil {
        errs = append(errs, err)
    }
    
    for _, slave := range db.slaves {
        if err := slave.Close(); err != nil {
            errs = append(errs, err)
        }
    }
    
    if len(errs) > 0 {
        return fmt.Errorf("close errors: %v", errs)
    }
    return nil
}

Подход 4: Маршрутизация на уровне транзакций

package database

import (
    "context"
    "database/sql"
)

// TxContext — контекст с информацией о типе транзакции
type TxContext struct {
    ctx       context.Context
    readOnly  bool
}

func WithReadOnly(ctx context.Context) context.Context {
    return context.WithValue(ctx, txTypeKey, true)
}

func IsReadOnly(ctx context.Context) bool {
    if v, ok := ctx.Value(txTypeKey).(bool); ok {
        return v
    }
    return false
}

// TxDB — маршрутизатор с учётом контекста
type TxDB struct {
    master *sql.DB
    slaves []*sql.DB
    rr     int32
}

func (db *TxDB) BeginTx(ctx context.Context, opts *sql.TxOptions) (*sql.Tx, error) {
    if IsReadOnly(ctx) {
        // Read-only транзакция — можно на slave
        return db.readDB().BeginTx(ctx, &sql.TxOptions{
            Isolation: opts.Isolation,
            ReadOnly:  true,
        })
    }
    return db.master.BeginTx(ctx, opts)
}

func (db *TxDB) QueryContext(ctx context.Context, query string, args ...interface{}) (*sql.Rows, error) {
    if IsReadOnly(ctx) {
        return db.readDB().QueryContext(ctx, query, args...)
    }
    // Если нет маркера — определяем по запросу
    if isReadQuery(query) {
        return db.readDB().QueryContext(ctx, query, args...)
    }
    return db.master.QueryContext(ctx, query, args...)
}

func isReadQuery(query string) bool {
    // Простая эвристика: SELECT, SHOW, EXPLAIN — чтение
    trimmed := strings.TrimSpace(strings.ToUpper(query))
    return strings.HasPrefix(trimmed, "SELECT") ||
        strings.HasPrefix(trimmed, "SHOW") ||
        strings.HasPrefix(trimmed, "EXPLAIN")
}

Использование в репозитории:

type UserRepository struct {
    db *database.DB // или database.TxDB
}

func NewUserRepository(db *database.DB) *UserRepository {
    return &UserRepository{db: db}
}

func (r *UserRepository) FindByID(ctx context.Context, id int64) (*User, error) {
    // Автоматически пойдёт на read replica
    row := r.db.QueryRowContext(ctx,
        "SELECT id, name, email FROM users WHERE id = $1", id)
    
    var user User
    err := row.Scan(&user.ID, &user.Name, &user.Email)
    return &user, err
}

func (r *UserRepository) Save(ctx context.Context, user *User) error {
    // Автоматически пойдёт на master
    _, err := r.db.ExecContext(ctx,
        "INSERT INTO users (id, name, email) VALUES ($1, $2, $3)",
        user.ID, user.Name, user.Email)
    return err
}

Подход 5: Полностью прозрачный через интерфейс

package database

// Store — единый интерфейс для бизнес-логики
type Store interface {
    Users() UserRepository
    Orders() OrderRepository
    // ...
}

// Реализация с master-slave
type MasterSlaveStore struct {
    readDB  *sql.DB
    writeDB *sql.DB
}

func (s *MasterSlaveStore) Users() UserRepository {
    return &UserRepo{readDB: s.readDB, writeDB: s.writeDB}
}

func (s *MasterSlaveStore) Orders() OrderRepository {
    return &OrderRepo{readDB: s.readDB, writeDB: s.writeDB}
}

// Реализация с одной БД (для простых случаев)
type SingleDBStore struct {
    db *sql.DB
}

func (s *SingleDBStore) Users() UserRepository {
    return &UserRepo{readDB: s.db, writeDB: s.db}
}

func (s *SingleDBStore) Orders() UserRepository {
    return &OrderRepo{readDB: s.db, writeDB: s.db}
}

Бизнес-логика не знает о маршрутизации:

type UserService struct {
    store database.Store // интерфейс!
}

func (s *UserService) GetUser(ctx context.Context, id int64) (*User, error) {
    // Не знаем и не хотим знать — master или slave
    return s.store.Users().FindByID(ctx, id)
}

func (s *UserService) CreateUser(ctx context.Context, user *User) error {
    // Не знаем и не хотим знать — master или slave
    return s.store.Users().Save(ctx, user)
}

Конфигурация:

func NewStore(cfg Config) (database.Store, error) {
    if cfg.ReplicasEnabled {
        master, _ := sql.Open("postgres", cfg.MasterDSN)
        var slaves []*sql.DB
        for _, dsn := range cfg.ReplicaDSNs {
            db, _ := sql.Open("postgres", dsn)
            slaves = append(slaves, db)
        }
        return database.NewMasterSlaveStore(master, slaves), nil
    }
    
    db, _ := sql.Open("postgres", cfg.DSN)
    return database.NewSingleDBStore(db), nil
}

Итог: Ключевой принцип — бизнес-логика зависит от интерфейса, а не от конкретной реализации подключения к БД. Маршрутизация read/write происходит на уровне инфраструктурного слоя. При изменении топологии (одна БД → master-slave → шардинг) меняется только реализация интерфейса, бизнес-логика остаётся нетронутой.

Вопрос 27. Зачем нужен балансировщик (L7) и что такое ingress?

Таймкод: 00:57:02

Ответ собеседника: Неполный. Не смог объяснить назначение балансировщика, ingress описал поверхностно.

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

Балансировщик нагрузки (Load Balancer)

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

Уровни балансировки:

L4 (Transport Layer) — балансировка на уровне TCP/UDP:

                    ┌──────────────┐
Client ────────────►│   L4 LB      │
                    │  (IP + Port) │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ Backend 1│ │ Backend 2│ │ Backend 3│
        │ :8080    │ │ :8080    │ │ :8080    │
        └──────────┘ └──────────┘ └──────────┘

• Работает с IP-адресами и портами
• Не анализирует содержимое запроса
• Быстрый, но «глупый» — не понимает HTTP
• Примеры: AWS NLB, HAProxy (TCP mode), IPVS

L7 (Application Layer) — балансировка на уровне HTTP:

                         ┌──────────────┐
Client ─────────────────►│   L7 LB      │
                         │  (HTTP-aware)│
                         └──────┬───────┘
                                │
           ┌────────────────────┼────────────────────┐
           ▼                    ▼                    ▼
    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
    │ /api/users/* │    │ /api/orders/*│    │ /static/*    │
    │  User Service│    │ Order Service│    │ Static Files │
    └──────────────┘    └──────────────┘    └──────────────┘

• Анализирует HTTP-заголовки, URL, cookies
• Может маршрутизировать на основе пути, хоста, заголовков
• Может выполнять SSL termination
• Примеры: AWS ALB, NGINX, Envoy, Traefik

Зачем нужен L7 балансировщик:

1. Маршрутизация на основе URL:

# NGINX пример
server {
    listen 80;
    
    location /api/users {
        proxy_pass http://user-service:8080;
    }
    
    location /api/orders {
        proxy_pass http://order-service:8080;
    }
    
    location /static {
        proxy_pass http://static-service:8080;
    }
}

2. SSL/TLS termination:

Клиент устанавливает HTTPS-соединение с балансировщиком, а балансировщик общается с бэкендами по HTTP:

Client ──HTTPS──► L7 LB ──HTTP──► Backend
                  (SSL termination)

3. Sticky sessions (сессионная привязка):

upstream backend {
    ip_hash; # один клиент всегда попадает на один бэкенд
    server backend1:8080;
    server backend2:8080;
}

4. Rate limiting, circuit breaking, retry:

# Envoy пример
routes:
  - match:
      prefix: "/api/"
    route:
      cluster: backend_service
      retry_policy:
        retry_on: "5xx"
        num_retries: 3
    rate_limits:
      - actions:
          - remote_address: {}
        limit:
          requests_per_minute: 100

5. A/B тестирование и canary deployments:

split_clients "${remote_addr}" $variant {
    10%  "canary";
    *    "stable";
}

location /api/ {
    if ($variant = "canary") {
        proxy_pass http://canary-service:8080;
    }
    proxy_pass http://stable-service:8080;
}

Ingress в Kubernetes

Ingress — это ресурс Kubernetes, который управляет внешним доступом к сервисам в кластере, обычно HTTP/HTTPS.

                    Internet
                       │
                       ▼
              ┌─────────────────┐
              │  Load Balancer  │  (облачный или metalLB)
              │  (внешний IP)   │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │  Ingress        │  (NGINX, Traefik, Istio)
              │  Controller     │
              └────────┬────────┘
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
   ┌───────────┐ ┌───────────┐ ┌───────────┐
   │ Service A │ │ Service B │ │ Service C │
   │ (Pods)    │ │ (Pods)    │ │ (Pods)    │
   └───────────┘ └───────────┘ └───────────┘

Ресурс Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
  tls:
    - hosts:
        - api.example.com
      secretName: tls-secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /api/users
            pathType: Prefix
            backend:
              service:
                name: user-service
                port:
                  number: 8080
          - path: /api/orders
            pathType: Prefix
            backend:
              service:
                name: order-service
                port:
                  number: 8080
    - host: static.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: static-service
                port:
                  number: 8080

Зачем нужен Ingress:

• Единая точка входа — один внешний IP для всех сервисов
• Маршрутизация по хостам и путям — разные домены и URL идут в разные сервисы
• SSL termination — один TLS-сертификат на все сервисы
• Централизованная конфигурация — rate limiting, CORS, заголовки

Ingress Controller — это реализация Ingress:

Controller	Особенности
NGINX Ingress	Самый популярный, основан на NGINX
Traefik	Автоматическое обнаружение сервисов
Istio Gateway	Service mesh, расширенные возможности
HAProxy Ingress	Высокая производительность
AWS ALB Ingress	Интеграция с AWS ALB

Итог: L7 балансировка нужна для маршрутизации на основе HTTP-заголовков, URL, хостов, SSL termination, rate limiting и canary deployments. В Kubernetes Ingress — это ресурс, который описывает правила маршрутизации внешнего трафика к сервисам внутри кластера. Ingress Controller (NGINX, Traefik, Istio) — это реализация, которая применяет эти правила.

Вопрос 28. Что такое автоскейлинг приложений и зачем нужен rate limit?

Таймкод: 00:57:55

Ответ собеседника: Правильный. Описан горизонтальный автоскейлинг, rate limit для защиты от DDoS, HTTP 429.

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

Ответ собеседника корректный. Дополним деталями.

Автоскейлинг (Autoscaling)

Автоскейлинг — автоматическое изменение количества экземпляров приложения в зависимости от нагрузки.

Виды автоскейлинга в Kubernetes:

1. Horizontal Pod Autoscaler (HPA) — горизонтальное масштабирование

Увеличивает/уменьшает количество подов:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70  # масштабировать при CPU > 70%
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

2. Vertical Pod Autoscaler (VPA) — вертикальное масштабирование

Изменяет requests/limits подов:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"

3. Cluster Autoscaler — масштабирование кластера

Добавляет/удаляет ноды в кластере при нехватке ресурсов.

Кастомные метрики для HPA:

metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"  # масштабировать при > 1000 RPS на под

Rate Limiting

Rate limit — ограничение количества запросов от клиента за единицу времени.

Зачем нужен:

• Защита от DDoS — предотвращение перегрузки сервера
• Защита от злоупотреблений — ограничение количества запросов
• Справедливое распределение ресурсов — каждый клиент получает свою долю
• Защита от сканирования — брутфорс, сканирование API

HTTP-коды:

Код	Название	Когда используется
429	Too Many Requests	Клиент превысил лимит запросов
503	Service Unavailable	Сервер перегружен, временная недоступность

Заголовки rate limiting:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1634567890
Retry-After: 60

Реализация rate limiting в Go:

package ratelimit

import (
    "net/http"
    "sync"
    "time"
    "golang.org/x/time/rate"
)

type IPRateLimiter struct {
    ips     map[string]*rate.Limiter
    mu      sync.RWMutex
    rate    rate.Limit
    burst   int
}

func NewIPRateLimiter(r rate.Limit, b int) *IPRateLimiter {
    return &IPRateLimiter{
        ips:   make(map[string]*rate.Limiter),
        rate:  r,
        burst: b,
    }
}

func (i *IPRateLimiter) GetLimiter(ip string) *rate.Limiter {
    i.mu.Lock()
    defer i.mu.Unlock()
    
    limiter, exists := i.ips[ip]
    if !exists {
        limiter = rate.NewLimiter(i.rate, i.burst)
        i.ips[ip] = limiter
    }
    return limiter
}

func RateLimitMiddleware(limiter *IPRateLimiter) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            ip := r.RemoteAddr
            l := limiter.GetLimiter(ip)
            
            if !l.Allow() {
                w.Header().Set("Retry-After", "60")
                w.Header().Set("X-RateLimit-Limit", "100")
                w.Header().Set("X-RateLimit-Remaining", "0")
                http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
                return
            }
            
            next.ServeHTTP(w, r)
        })
    }
}

Алгоритмы rate limiting:

Алгоритм	Описание	Плюсы	Минусы
Token Bucket	Токены добавляются с постоянной скоростью	Позволяет burst	Сложнее в реализации
Leaky Bucket	Запросы обрабатываются с постоянной скоростью	Равномерная нагрузка	Теряет запросы при переполнении
Fixed Window	Счётчик в фиксированном окне времени	Простой	Burst на границах окна
Sliding Window	Скользящее окно времени	Точнее	Требует больше памяти

Итог: Автоскейлинг — автоматическое масштабирование приложения. HPA в Kubernetes масштабирует поды по CPU/памяти/кастомным метрикам. Rate limit защищает от DDoS и злоупотреблений, возвращает HTTP 429 (Too Many Requests). Реализуется алгоритмами token bucket, leaky bucket, sliding window.