Golang
Пиковая нагрузка: 25k чтений / 5k записей в секунду Объем новых данных: 10 ТБ в год Пиковый параллелизм: 120k одновременных запросов Годовой рост пользователей: 30% Целевой p99 задержки: <150 мс для чтений, <400 мс для записей Целевая доступность: 99.95% Ваша задача — разработать архитектурное решение, которое позволит устранить текущие проблемы, обеспечит согласованность и отказоустойчивость, а также внедрить механизмы трассировки для полного мониторинга жизненного цикла заказа. Опишите механизм обработки сбоев, план миграции с текущей архитектуры, и объясните, как предложенное решение улучшит надёжность и прозрачность системы.
Расскажи про брокеры сообщений, с которыми работал.
// Исправить код так, чтобы запросы были конкурентными и выводился код ответа // и в случае ошибки - выводили ее лог и продолжали обработку package main import "net/http" var addrs = []string{"[link] "[link] "[link] "[link] "[link] "[link] "[link] func main() { wg := sync.WaitGroup{} data := make(map[string]bool) for _, url := range addrs { wg.Add(1) if !data[url]{ data[url] = true go func(url string){ defer wg.Done() resp, err := http.Get(url) if err != nil { log.err return } log.info }(url) } } wg.Wait() }
Расскажи про модель GMP в Go. Как работают очереди, что такое handoff, work stealing, netpoller?
С чем связано решение уйти из Wildberries?
// Написать асинхронный обработчик задач как библиотеку // Клиент передаёт на вход некоторый объект (Task) с данными для выполнения задачи, // в нашем примере будем использовать пустую структуру. // Обработчик одновременно может обрабатывать не более N задач, // и не более X задач могут быть поставлены в очередь на обработку. // Если нет места в очереди, сразу возвращаем клиенту ошибку. // Задача берется в обработку если имеются на это свободные обработчики. // Иммитируем длительность обработки через time.Sleep(5*time.Second). // Как только очередная задача выполнилась - берём следующую задачу из очереди. // Если в очереди пусто, ожидаем новых задач от клиентов. // Со звездочкой: дополнить структуру Task и получать статусы задач через отдельный запрос
Если я сделаю 6 реплик сервиса при 3 партициях — это поможет ускорить чтение?
Почему умножение матриц задаётся именно таким правилом?
Был ли у вас опыт работы с миграциями и что это за механизм?
Напишите SQL-запрос, который выведет **имя клиента**, его **город** и **общую сумму** всех его заказов. В итоговую выборку должны попасть только те клиенты, суммарные траты которых составляют **более 1000** у.е. --- **Схема данных:** 1. **Таблица `customers`:** - `customer_id` (int) – уникальный идентификатор клиента. - `customer_name` (varchar) – имя клиента. - `city` (varchar) – город проживания. 2. **Таблица `orders`:** - `order_id` (int) – уникальный номер заказа. - `customer_id` (int) – ID клиента, совершившего покупку. - `total_amount` (decimal) – сумма конкретного заказа.
[имя] спросил: расскажите о составе команды на текущем месте работы в Nordite и на предыдущем месте в Легионе.
Умеешь работать без аналитиков?
В чём была проблема со старыми мапами в Go, что их полностью переписали на SwissMap с приростом производительности ~30%?
Балансировщик GeoDNS и Nginx — это разные вещи?
Как ты повлиял на изменение процесса с аналитикой?
Насколько приходилось погружаться в базы данных — писать и оптимизировать запросы?
С какого момента вы будете доступны?
Есть ли военный билет?
Ты позиционируешь себя как мидл или как сеньор разработчик?
На вход сервису поступают обновления документов message Document { string Url = 1; // URL документа, его уникальный идентификатор uint64 PubDate = 2; // время заявляемой публикации документа uint64 FetchTime = 3; // время получения данного обновления документа, может рассматриваться как идентификатор версии. Пара (Url, FetchTime) уникальна. string Text = 4; // текст документа uint64 FirstFetchTime = 5; // изначально отсутствует, необходимо заполнить } Документы могут поступать в произвольном порядке (не в том, как они обновлялись), также возможно дублирование отдельных сообщений. Необходимо на выходе формировать такие же сообщения, но с исправленными отдельными полями по следующим правилам (всё нижеуказанное - для группы документов с совпадающим полем Url): Поле Text и FetchTime должны быть такими, какими были в документе с наибольшим FetchTime, полученным на данный момент Поле PubDate должно быть таким, каким было у сообщения с наименьшим FetchTime Поле FirstFetchTime должно быть равно минимальному значению FetchTime Т. е. в каждый момент времени мы берём PubDate и FirstFetchTime от самой первой из полученных на данный момент версий (если отсортировать их по FetchTime), а Text - от самой последней. Интерфейс в коде можно реализовать таким: type Processor interface { Process(doc *Document) (*Document, error) } Данный код будет работать в сервисе, читающем входные сообщения из очереди сообщений (Kafka или подобное), и записывающем результат также в очередь. Если Process возвращает Null - то в очередь ничего не пишется.