Я думаю уже многие пользователи хабра знают что на прошлой недели закончился HighLoadCup от Mail.ru (из-за обилия количества статей от участников). Я хотел бы также поделиться своим решением с сообществом.

Описание задачи

Существует три вида сущностей: User, Location, Visit. Необходимо написать REST-API для доступа к ним, т.е. получается необходимо обработка 6 запросов.

{GET, POST} /user/:id — получение или изменение пользователя
{GET, POST} /location/:id — получение или изменение локации
{GET, POST} /visit/:id — получение или изменение посещения локации пользователем
POST /user/new — добавление нового пользователя
POST /location/new — добавление новой локации
POST /visit/new — добавление нового посещения локации пользователем

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

Начало

Изначально я начал писать на С++, но до релиза так и не дошло. Увидев большое количество решений в топе на Go я решил тоже попробовать его. Этот язык мне показался значительно более подходящим для разработки серверных приложения, он имеет из коробки весь необходимый функционал причём в очень качественном исполнении. Впрочем, уже после первых тестов стало понятно, что ни net/http, ни encoding/json не подходят для данного конкурса в связи с большим количеством мусора, который генерируется внутри них.

Раунд первый

Изначально данных было всего 200 мб в распакованном виде, поэтому я подумал что возможно даже хранить готовые JSON-строки для каждой сущность. В качестве http-сервера по советам гошников конкурса (спасибо им большое за оказанную помощь на старте знакомства с языком) я выбрал fasthttp, для парсинга JSON buger/jsonparser (позволяет парсинг без аллокаций и работать только с нужной информацией, игнорируя остальную), а генерацию производил руками, по-скольку никакой обработки русскоязычных строк не требовалось.

type User struct {
	id  uint
	email string
	first_name  string
	last_name string
	gender bool
	birth_date int64

	age   int
	visits Visits
	json []byte
}

type Location struct {
	id uint
	place string
	country string
	city string
	distance int64

	visits Visits
	json []byte
}

type Visit struct {
	id uint
	location *Location
	user *User
	visited_at int64
	mark int64

	json []byte
}

Такие сущности у меня вышли на старте, в посещении для ускорения я решил хранить сразу указатели на соответствующих пользователя и локацию. Итог получился весьма удовлетворительным, все данные прекрасно помещались и в итоге я даже смог попасть в 10-ку (не на долго правда).

Возраст

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

Итогом стал такой код:

func countAge(timestamp *int64) int {
	now := time.Now()
	t := time.Unix(*timestamp, 0)

	years := now.Year() - t.Year()
	if now.Month() > t.Month() || now.Month() == t.Month() && now.Day() >= t.Day() {
		years += 1
	}

	return years
}

Увеличение нагрузки

За несколько дней до финала после демократического и открытого голосования создатели конкурса в 10 раз увеличили количество данных и в 2 раза максимальный RPS. После этого моё решение перестало влезать в память и потребовало изменений. Пришлось убрать из структур заранее сгенерированный JSON и создавать его на лету при запросе, что увеличило, конечно же, реализм. В тоже время я подумал, а почему бы не добавить в структуры посетителя и локации сразу ссылки на посещения, которые с ними связаны. Это значительно увеличило скорость программы, так как не пришлось проходить каждый раз весь массив посещений (который теперь содержал 10 миллионов записей).

Решение после этого заработало, но по скорости стало уступать другим решениям и я рисковал не пройти в финал. Не долго думая я выкинул fasthttp и перешёл на tcp-сокеты и epoll. Размер окна в нашей системе был в районе 65кб и пакеты точно приходили и отправлялись полностью и это дало большое поле для костылей, которые в продакшене точно работать не будут.

Финал

К финалу я подошёл на 39 месте, чему я был несомненно очень рад. Это первое моё участие в подобном конкурсе, первое знакомство с Go и highload (хотя я бы не назвал это highload). Финал начался плохо, сервер вылетел из-за ошибки одновременного доступа на чтение и запись (до финала таких проблем не возникало и локеры были вырезаны), тем не менее на одной из волн удалось показать лучший результат за все запуски что дало возможность занять 28 место.

В целом это был очень интересный и познавательный (для меня, по крайней мере) конкурс. Я хотел бы выразить огромную благодарность организаторам и жду следующего учтя все ошибки и «фичи» нынешнего (busy-polling, например). Правда в будущем обещан был больший упор именно на логику, а не на сетевой стек, что будет более интересным.

P.S. Жду футболочку :)

Код (вдруг кому-то станет интересно) можно посмотреть в моём репозитории.

Очередное решение HighLoadCup на Go