Простые highload паттерны на Go / Хабр

Привет, Хабр! Меня зовут Агаджанян Давид, хочу поделиться некоторыми инженерами рекомендациями, которые часто на моем опыте помогали держать highload нагрузку не прибегая к хардкору. Примеры будут на Go. Эти подходы довольно хорошо известны, но как мне кажется они недооценены и многие этими подходами пренебрегают. Если вы впервые видите их, то рекомендую хотя бы попробовать реализовать в своих проектах и провести бенчмарки, возможно вы будете приятно удивлены. Этих подходов в 90% случаях мне хватало за глаза, когда требовалось быстро и кратно увеличить перфоманс приложения в короткие сроки. Ну и конечно же делитесь своим опытом к каким подходам для оптимизаций вы прибегаете в первую очередь, буду рад взять себе интересное на заметку

Refresh-ahead caching

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

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

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

Реализация: ниже код, но если вам удобнее смотреть в github, welcome

package main

import (
	"context"
	"encoding/json"
	"net/http"
	"sync"
	"time"
)

type Movie struct {
	Title string `json:"Title"`
}

type CachedPopularItems struct {
	lock   sync.RWMutex
	Movies []Movie
}

func main() {
	ctx := context.Background()

	// initializing cache and fill
	cache := CachedPopularItems{}
	cache.Movies = getPopularMoviesFromDB()
	go func() {
		timer := time.NewTicker(1 * time.Second)
		defer timer.Stop()

		// initializing background job
		for {
			select {
			// refreshing cache
			case <-timer.C:
				movies := getPopularMoviesFromDB()

				// updating cache struct
				cache.lock.Lock()
				cache.Movies = movies
				cache.lock.Unlock()

			// app is terminating
			case <-ctx.Done():
				break
			}
		}
	}()

	http.HandleFunc("/getPopularMovies", func(writer http.ResponseWriter, request *http.Request) {
		cache.lock.RLock()
		movies := cache.Movies
		cache.lock.RUnlock()

		bytes, _ := json.Marshal(movies)

		writer.Header().Add("Content-Type", "application/json")
		writer.Write(bytes)
	})

	_ = http.ListenAndServe(":8890", nil)
}

// Getting from DB
func getPopularMoviesFromDB() []Movie {
	// simulation request to database with latency
	time.Sleep(5 * time.Second)

	return []Movie{{Title: "Avatar"}, {Title: "I Am Legend"}, {Title: "The Wolf of Wall Street"}}
}

Плюсы

Никакой логики, пришел запрос, сразу отдали ответ
Снимается нагрузка на хранилище, особенно если запрос тяжеловесный
Снимается сетевой поход в хранилище
Узкое горлышко приложения в таком случае - это кол-во открытых соединений и сетевой канал
В случае если хранилище будет недоступно, пользователи все равно будут получать данные

Минусы

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

Этот и другие подходы к кешированию можно прочитать в известном справочнике system-design-primer

Do once, give it to everyone

Если много пользователей приходят одновременно в сервис за одной и той же информацией, зачем ее выполнять в лучшем случае дважды, а в худшем тысячи раз?

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

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

Реализация: реализация на Go в github

package main

import (
	"encoding/json"
	"fmt"
	"math/rand"
	"net/http"
	"strconv"
	"strings"
	"time"

	"golang.org/x/sync/singleflight"
)

type Book struct {
	ID    int
	Title string `json:"Title"`
}

func main() {
	// Struct for syncing work
	s := singleflight.Group{}

	http.HandleFunc("/getBook/", func(writer http.ResponseWriter, request *http.Request) {
		bookID, _ := strconv.Atoi(strings.TrimLeft(request.RequestURI, "/getBook/"))
		workHash := fmt.Sprintf("book:%d", bookID)

		// Doing work with same hash once
		result, _, _ := s.Do(workHash, func() (interface{}, error) {
			return getBookFromDB(bookID), nil
		})

		book := result.(Book)
		bytes, _ := json.Marshal(book)

		writer.Header().Add("Content-Type", "application/json")
		writer.Write(bytes)
	})

	_ = http.ListenAndServe(":8890", nil)
}

// Getting from DB
func getBookFromDB(id int) Book {
	// simulation request to database with latency
	time.Sleep(1 * time.Second)

	return Book{ID: id, Title: randSeq(rand.Intn(30))}
}

var letters = []rune("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")

// Random string generator
func randSeq(n int) string {
	b := make([]rune, n)
	for i := range b {
		b[i] = letters[rand.Intn(len(letters))]
	}
	return string(b)
}

Плюсы

Предотвращение дублирования повторяющихся параллельных задач
Экономия ресурсов CPU/Сети

Минусы

Подойдет только при небольшой вариативности, иначе никакого профита этот подход не принесет

Worker pool

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

Пример 1: у вас есть сервис, который выполняет сложные вычислительные операции и инициализация объектов для выполнения - дорогая операция, поэтому необходимо подготовиться заранее, при этом нужно ограничить количество одновременно выполняемых вычислений

Пример 2: у вас есть сервис, который на один запрос выполняет множество операций (батч запрос) и их можно выполнить параллельно, собрав результаты в единый отчет

Концепт: на старте приложения инициализировать N воркеров, которые будут выполнять полезную работу, и сбрасывать состояние объектов воркера после завершения задачи

Реализация: реализация на Go в github

package main

import (
	"context"
	"encoding/json"
	"math/rand"
	"net/http"
	"time"
)

type WorkerPool struct {
	jobs chan WorkJob
}

func (w *WorkerPool) StartWorker() {
	go func() {
		for {
			work := <-w.jobs

			// simulating work
			time.Sleep(1 * time.Second)

			status := false
			if work.ID%10 > 5 {
				status = true
			}

			work.Result <- WorkJobResult{Status: status}
		}
	}()
}

// Adding work job to queue
func (w *WorkerPool) AddJob(ctx context.Context, id int) <-chan WorkJobResult {
	resultChan := make(chan WorkJobResult, 1)

	select {
	// trying to add wor job
	case w.jobs <- WorkJob{ID: id, Result: resultChan}:

	// in case if request is aborted
	case <-ctx.Done():
		return nil
	}

	// return chan where consumer can read result
	return resultChan
}

type WorkJob struct {
	ID     int
	Result chan WorkJobResult
}

type WorkJobResult struct {
	Status bool
}

func main() {
	// worker pool with three workers
	wp := WorkerPool{
		jobs: make(chan WorkJob, 3),
	}
	wp.StartWorker()
	wp.StartWorker()
	wp.StartWorker()

	http.HandleFunc("/handle", func(writer http.ResponseWriter, request *http.Request) {
		resultsChan := make([]<-chan WorkJobResult, 0)
		for i := 0; i < 10; i++ {
			resultChan := wp.AddJob(context.Background(), rand.Intn(100))
			resultsChan = append(resultsChan, resultChan)
		}

		status := false
		for _, res := range resultsChan {
			resStatus := <-res
			status = status && resStatus.Status
		}

		bytes, _ := json.Marshal(status)
		writer.Write(bytes)
	})

	_ = http.ListenAndServe(":8890", nil)
}

Плюсы

Ограничение пропускной способности приложения
Параллельное выполнение подзадач
Экономия ресурсов, так как вы можете переиспользовать в worker pool объекты между задачами и не генерировать лишнего мусора

Минусы

При работе с параллельностью легко допустить ошибку и сломать приложение

Итог

Делитесь своими любимыми практиками, буду рад открыть что-то новое. Буду признателен любым конструктивным замечаниям. Спасибо!