👣 Как можно оценить работу кэша? Что можно кэшировать?

Работу кэша можно оценивать при помощи множества метрик разной степени полезности. Перечислим те, которые которые считаю базовыми и наиболее полезными.

▪Объем памяти, выделенной под кэш. Это базовый показатель, по которому можно судить, сколько используется ресурсов

▪RPS чтения/записи – количество операций чтения/записи за единицу времени. В обычной ситуации количество операций чтения должно быть в разы больше количества операций записи. Обратное соотношение свидетельствует о проблемах в работе кэша

▪Количество элементов в кэше. Его полезно знать в дополнение к объему памяти, чтобы обнаруживать большие записи

▪Hit rate – процент извлечения данных из кэша. Чем он ближе к 100%, тем лучше. Этот параметр буквально определяет то, насколько наш кэш полезен и эффективен

▪Expired rate – процент удаления записей по истечении TTL. Этот показатель помогает обнаружить проблемы с производительностью, вызванные большим количеством записей с одновременно истекшим TTL

▪Eviction rate – процент вытеснения записей из кэша при достижении лимита используемой памяти. Важный показатель при выборе стратегий вытеснения, о которых мы поговорим чуть позже

Что можно кэшировать?
Строго говоря, кэшировать можно что угодно, но не всегда это целесообразно. Все сильно зависит от данных и паттерна их использования.

Все данные можно условно разделить на 3 группы по частоте изменений:

▪Меняются часто. Такие данные изменяются в течение секунд или нескольких минут. Их кэширование чаще всего бессмысленно, хотя иногда может и пригодится.

Пример: ошибки (кэширование ошибок может быть настолько важным, что мы посвятили ему целую главу ближе к концу статьи)

▪Меняются нечасто. Такие данные изменяются в течение минут, часов, дней. Именно в этом случае вы чаще всего задаетесь вопросом “Стоит ли мне кэшировать это?”

Примеры: списки товаров на сайте, описания товаров

▪Меняются крайне редко или не меняются никогда. Такие данные меняются в течение недель, месяцев и лет. В этом случае данные можно спокойно кэшировать. НО! Ни в коем случае нельзя усыплять бдительность верой в то, что какие-либо данные никогда не изменятся. Рано или поздно они изменятся, поэтому всегда выставляйте всем данным разумный TTL. ВСЕГДА!

Напишите какие стратегии работы с кэшем вы знаете в комментариях 👇

@golang_interview

👣 Что выведет код ?

package main

import "fmt"

func sum(a, b any) any {
return a + b
}

func main() {
fmt.Println(sum(2, 3))
}

📌Ответ

@golang_interview

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

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

Для этого во многих рекурсивных функциях предусмотрены дополнительные аргументы, действующие в качестве флагов в тех ситуациях, когда на предыдущем или последующем уровне выполняются определённые условия.

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

На первый взгляд кажется, что эта задача легко решаема при помощи рекурсивной функции – нужно только обеспечить, чтобы она дошла прямым ходом до конца списка, не пропуская никакого состояния на вышестоящие уровни. Таким образом, первый из вышеперечисленных случаев пропускаем. Во втором случае перезаписываем указатель актуального узла. Третий случай вновь пропускаем. В четвёртом случае ещё раз перезаписываем.

Но задумайтесь, что случится, если вы достигнете конечного (nil), имея строку дублей. Допустим, мы работаем с 2 -> 3 -> 3 -> nil, давайте разберём вышеприведённые случаи узел за узлом:

2 -> 3

2 не равно 3, поэтому здесь мы никаких изменений в узел вносить не будем и вновь вызовем функцию, на этот раз передав ей в качестве аргумента узел '3'.

3 -> 3
a b

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

В данном случае мы можем перезаписать указатель 'a', так, чтобы он стал 'b' – в сущности, удалив 'a'. Теперь снова вызываем функцию, на этот раз передав ей узел 'b'.

3 -> nil
b

Как только мы достигнем nil, имея дубль, нам придётся попытаться перезаписать указатель, но мы не сможем — Go выдаст панику, поскольку нельзя присвоить указателю nil. Поэтому нам понадобится реализовать определённую логику, которая позволяла бы перехватывать ситуацию до возникновения паники, и просто возвращать nil, а не перезаписывать с заменой на nil. Но, если мы вернём nil, то всплывём на уровень вверх. Так мы не только потеряем контекст, позволявший судить, является ли данное значение дублем, но и не сможем изменять значение выше по рекурсивной цепочке, поскольку мы не меняли указатель напрямую.

Вот что можно сделать для решения этой проблемы: мы можем не только полагаться на флаг, сигнализирующий о дубле и посылаемый вниз по пути с рекурсивным изменением. Вдобавок давайте создадим флаг, сигнализирующий, не всплыли ли мы вверх с того уровня, где было дублирующееся значение, смежное с nil. Таким образом, у нас сохранится уловка, позволяющая добраться до nil, и вместе с тем мы сможем безопасно перезаписывать указатели. А если бы мы достигли уровня, имея этот флаг со значением true, мы переключаем узлы и устанавливаем его в false – так сообщается, что дубля в конце у нас уже нет.

📌Решение

@golang_interview

👣 Задача: Конференц-залы II.

Сложность задачи: Средняя

Условие задачи:
Дан массив интервалов времени проведения совещаний, intervals, где intervals[i] = [start(i), end(i)]. Найдите минимальное требуемое количество конференц-залов.

Пример:
Ввод: intervals = [[0,30],[5,10],[15,20]]
Вывод: 2

Ввод: intervals = [[7,10],[2,4]]
Вывод: 1

📌Решение

Пишите свое решение в комментариях👇

@golang_interview

💡 Задача: Самые дешевые авиабилеты в пределах K остановок

Условие: Имеется n городов, соединенных некоторым количеством рейсов. Вам дан массив flights, где flights[i] = [fromi, toi, pricei] означает, что существует рейс из города fromi в город toi со стоимостью pricei.

Также даны три целых числа src, dst и k, возвращаем самую дешевую цену из src в dst с не более чем k остановками. Если такого маршрута не существует, возвращается -1.

Пример:

Ввод: n = 4, flights = [[0,1,100],[1,2,100],[2,0,100],[1,3,600],[2,3,200]], src = 0, dst = 3, k = 1
Вывод: 700

Ввод: n = 3, flights = [[0,1,100],[1,2,100],[0,2,500]], src = 0, dst = 2, k = 1
Вывод: 200

Решение

Пишите свое решение в комментариях👇

@golang_interview

💡 Задача: Лучшая команда, в которой нет конфликтов

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

Однако в баскетбольной команде не должно быть конфликтов. Конфликт возникает, если младший игрок набрал строго больше очков, чем старший. Конфликт не возникает между игроками одного возраста.

Задав два списка, scores и ages, в которых каждый scores[i] и ages[i] представляет собой счет и возраст i-го игрока соответственно, верните наибольший общий балл среди всех возможных баскетбольных команд.

Пример:

Ввод: scores = [1,3,5,10,15], ages = [1,2,3,4,5]
Вывод: 34

Ввод: scores = [4,5,6,5], ages = [2,1,2,1]
Вывод: 16

Пишите свое решение в комментариях👇

@golang_interview

👣 Какие рекомендации по безопасности нужно учитывать при разработке Golang приложений?

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

▪Валидация ввода: Никогда не доверяйте входным данным. Всегда проводите валидацию и фильтрацию пользовательского ввода, чтобы предотвратить атаки типа SQL-инъекции, XSS и другие уязвимости.

▪Защита от переполнения буфера: Обязательно проверяйте размеры буферов и массивов при обработке данных. Используйте безопасные функции для работы с памятью, чтобы предотвратить переполнение буфера.

▪Использование параметризованных запросов: При работе с базами данных используйте параметризованные запросы, чтобы избежать SQL-инъекций. Никогда не создавайте запросы, включающие пользовательский ввод напрямую.

▪Защита от утечек памяти: Убедитесь, что ваши приложения Golang не страдают от утечек памяти. Правильно управляйте ресурсами и освобождайте память после использования.

▪Шифрование данных: При передаче и хранении конфиденциальных данных используйте шифрование для защиты данных от несанкционированного доступа.

▪Обновление зависимостей: Регулярно обновляйте зависимости в ваших Golang приложениях, чтобы исправить уязвимости и получить последние исправления ошибок.
Соблюдение этих рекомендаций поможет повысить безопасность ваших Golang приложений и защитить их от потенциальных атак.

Пишите свой ответ в комментариях👇

@golang_interview

👣 Что такое Overhead от стандартного профайлера?
Стандартный профайлер в Go имеет некоторый незначительный overhead, который может оказать влияние на производительность вашего приложения. Однако этот overhead обычно незначительный и не должен существенно замедлять ваше приложение.

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

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

Однако, стоит отметить, что overhead от профайлера обычно не является значительным и не должен быть проблемой в большинстве случаев. Если вы обнаружите, что профайлер существенно замедляет ваше приложение, то, возможно, имеет смысл использовать его только во время отладки и разработки, а не в продакшн-среде.

Если вы хотите более точно измерить overhead профайлера в вашем конкретном случае, вы можете использовать инструменты профилирования, такие как go tool pprof, чтобы анализировать профилировочные данные и определить, какое влияние профайлер оказывает на производительность вашего приложения.

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

@golang_interview

👣 Обновленный гайд с примерами от команды Go по использованию profile-guided optimization для версии 1.21.

https://go.dev/blog/pgo

@golang_interview

👣 Стандартный набор метрик prometheus в Go-программе?
В Go-программе для сбора и экспорта метрик в Prometheus обычно используется пакет github.com/prometheus/client_golang/prometheus. Этот пакет предоставляет стандартный набор метрик и инструментов для работы с Prometheus.

Вот несколько основных типов метрик, которые можно использовать с помощью пакета prometheus:

Counter: Счетчики (Counter) представляют собой метрики, которые увеличиваются только вверх и никогда не уменьшаются. Они полезны для подсчета количества событий или запросов. Пример:

counter := prometheus.NewCounter(prometheus.CounterOpts{
Name: "my_counter",
Help: "This is my counter",
})
counter.Inc()

Gauge: Градусники (Gauge) представляют собой метрики, которые могут изменяться вверх и вниз. Они полезны для отслеживания изменяющихся значений, таких как количество активных соединений или текущая нагрузка на систему. Пример:

gauge := prometheus.NewGauge(prometheus.GaugeOpts{
Name: "my_gauge",
Help: "This is my gauge",
})
gauge.Set(42)
Histogram: Гистограммы (Histogram) представляют собой метрики, которые измеряют распределение значений в заданном диапазоне. Они полезны для измерения времени выполнения операций или размера запросов. Пример:

histogram := prometheus.NewHistogram(prometheus.HistogramOpts{
Name: "my_histogram",
Help: "This is my histogram",
Buckets: []float64{0.1, 0.5, 1, 2, 5},
})
histogram.Observe(0.6)
Summary: Суммары (Summary) также представляют собой метрики, которые измеряют распределение значений, но с учетом квантилей. Они полезны для измерения производительности и времени выполнения операций. Пример:

summary := prometheus.NewSummary(prometheus.SummaryOpts{
Name: "my_summary",
Help: "This is my summary",
})
summary.Observe(2.5)
Кроме того, пакет github.com/prometheus/client_golang/prometheus также предоставляет дополнительные инструменты для регистрации метрик (Register), создания коллекторов (Collector), экспорта метрик (HTTPHandler) и т.д.

Это лишь небольшой обзор стандартного набора метрик, доступных в Go-программе через пакет prometheus. Более подробную информацию о создании и использовании метрик в Prometheus вы можете найти в официальной документации Prometheus для Go-программы: https://pkg.go.dev/github.com/prometheus/client_golang/prometheus

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

@golang_interview

👣 Как встроить стандартный профайлер в свое приложение?
В Go вы можете использовать встроенный профайлер для сбора информации о производительности вашего приложения. Для этого вам нужно импортировать пакет net/http/pprof и зарегистрировать его обработчики HTTP.

Вот простой пример того, как встроить стандартный профайлер в свое приложение:

package main

import (
"log"
"net/http"
_ "net/http/pprof"
)

func main() {
// Регистрируем обработчики профайлера
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()

// Ваше приложение

// ...
}
В этом примере мы импортируем пакет net/http/pprof и регистрируем его обработчики HTTP с помощью функции http.ListenAndServe(). Обработчики будут доступны по адресу localhost:6060.

После запуска вашего приложения вы можете открыть веб-браузер и перейти по адресу http://localhost:6060/debug/pprof/, чтобы получить доступ к различным профилировочным эндпоинтам. Например:

• http://localhost:6060/debug/pprof/profile - профилирование CPU

• http://localhost:6060/debug/pprof/heap - профилирование памяти

• http://localhost:6060/debug/pprof/block - профилирование блокировок

• http://localhost:6060/debug/pprof/goroutine - профилирование горутин

Вы можете использовать инструменты, такие как go tool pprof, чтобы анализировать собранные профилировочные данные и получать информацию о времени выполнения, утечках памяти, блокировках и других аспектах производительности вашего приложения.

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

@golang_interview

👣 Какие типы мьютексов предоставляет stdlib?

Стандартная библиотека Go (stdlib) предоставляет два типа мьютексов для синхронизации доступа к общим ресурсам:

sync.Mutex: Это самый простой тип мьютекса, который предоставляется стандартной библиотекой Go. Он обеспечивает эксклюзивную блокировку (exclusive lock), что означает, что только одна горутина может захватить мьютекс и получить доступ к общему ресурсу. Если другая горутина пытается захватить мьютекс, пока он уже заблокирован, она будет ожидать его освобождения.

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

var mutex sync.Mutex
var sharedResource int

// Горутина 1
mutex.Lock()
sharedResource = 42
mutex.Unlock()

// Горутина 2
mutex.Lock()
fmt.Println(sharedResource)
mutex.Unlock()

sync.RWMutex: Этот тип мьютекса, называемый также мьютексом чтения/записи (read/write mutex), обеспечивает более гибкую блокировку. Он позволяет нескольким горутинам захватывать мьютекс только для чтения (shared lock), разрешая параллельный доступ к общему ресурсу для чтения. Однако, при записи (exclusive lock) мьютекс блокируется, и другие горутины должны ждать его освобождения.

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

var rwMutex sync.RWMutex
var sharedResource int

// Горутина 1 для записи
rwMutex.Lock()
sharedResource = 42
rwMutex.Unlock()

// Горутина 2 для чтения
rwMutex.RLock()
fmt.Println(sharedResource)
rwMutex.RUnlock()

Оба типа мьютексов, sync.Mutex и sync.RWMutex, являются потокобезопасными и предоставляют механизмы для синхронизации доступа к общим ресурсам в многопоточной среде. Выбор между ними зависит от требований вашего кода: если вам нужна только эксклюзивная блокировка, используйте sync.Mutex, а если вам требуется поддержка одновременного чтения и блокировки записи, используйте sync.RWMutex.

Пишите свой ответ в комментариях👇

@golang_interview

👣 Fixing For Loops in Go 1.22

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

https://go.dev/blog/loopvar-preview

@golang_interview

👣 Каков порядок перебора map?

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

Если вам требуется определенный порядок элементов, вам необходимо явно сортировать ключи или значения перед их использованием. Например, вы можете сначала извлечь ключи из map в срез (slice), отсортировать этот срез и затем итерироваться по отсортированным ключам для доступа к значениям.

Пример сортировки ключей map перед итерацией:

m := map[string]int{
"banana": 2,
"apple": 1,
"cherry": 3,
}

keys := make([]string, 0, len(m))
for k := range m {
keys = append(keys, k)
}

sort.Strings(keys)

for _, k := range keys {
fmt.Println(k, m[k])
}
В этом примере мы создаем map с неупорядоченными ключами и значениями. Затем мы извлекаем ключи из map в срез keys, сортируем этот срез с помощью sort.Strings, а затем итерируемся по отсортированным ключам, чтобы получить доступ к соответствующим значениям.

Важно отметить, что сортировка выполняется на ключах, а не на значениях map. Если вам нужно сортировать по значениям, вы можете использовать дополнительные структуры данных или преобразовывать map в список пар ключ-значение и сортировать его.

@golang_interview

👣 Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется? Почему?

Описание интерфейса следует помещать в пакете, где этот интерфейс используется, а не в пакете с реализацией. Это согласуется с принципом разделения интерфейса и реализации (Interface Segregation Principle) из принципов SOLID.

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

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

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

@golang_interview

👣 Как вы отсортируете массив структур по алфавиту по полю Name?

Для сортировки массива структур по алфавиту по полю Name в Go, вы можете использовать интерфейс sort.Interface и функцию sort.Sort() из пакета sort.

Вот пример кода, который демонстрирует, как отсортировать массив структур по полю Name:

package main

import (
"fmt"
"sort"
)

type Person struct {
Name string
Age int
}

type ByName []Person

func (a ByName) Len() int { return len(a) }
func (a ByName) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByName) Less(i, j int) bool { return a[i].Name < a[j].Name }

func main() {
people := []Person{
{Name: "Alice", Age: 25},
{Name: "Charlie", Age: 30},
{Name: "Bob", Age: 20},
}

sort.Sort(ByName(people))

for _, person := range people {
fmt.Println(person.Name, person.Age)
}
}
В этом примере мы определяем тип Person для представления структуры человека с полями Name и Age. Затем мы определяем тип ByName, который является срезом структур Person. Мы также реализуем методы Len(), Swap(), и Less() для типа ByName, чтобы он соответствовал интерфейсу sort.Interface.

Затем мы создаем срез структур Person и заполняем его некоторыми значениями. Далее мы вызываем sort.Sort(ByName(people)), чтобы отсортировать срез структур по полю Name. Наконец, мы проходимся по отсортированному срезу и выводим отсортированные значения.

В результате выполнения этого кода вы увидите отсортированный по алфавиту список людей по полю Name, сопровождающийся их возрастом.

@golang_interview