Медиа и хранилище: чтение кода и конфигов
Читай реальные обработчики загрузки, конфиги хранилища, логику синка и счётчики, затем выбирай сеньорскую починку: загрузку прямо в объектное хранилище, расчёт накладных erasure coding, сравнение чанков delta-синка и eventually-consistent счётчик просмотров.
Баги медиа прячутся в обработчике и конфиге: запрос, что буферизует гигабайты, фактор репликации, сравнение чанков, синхронный счётчик. Читай каждый сниппет, найди изъян дизайна и выбери изменение, что закоммитит сеньор.
Практикуй цикл дизайн-ревью: находи, где байты касаются пути приложения, где избыточность выбрана неверно, где синк двигает слишком много и где счётчик опасно синхронен.
Сниппет 1 — обработчик загрузки
@app.post("/upload")
def upload(req):
data = req.body.read() # всё видео, в памяти
db.execute("INSERT INTO videos (id, blob) VALUES (?, ?)", req.id, data)
return {"ok": True}Что не так с этим обработчиком загрузки и в чём починка?
Сниппет 2 — конфиг хранилища
# конфиг долговечности объектного хранилища
redundancy: replication
replication_factor: 3 # 3 полные копии каждого объекта
# нагрузка: эксабайты холодного архивного видео, редко читаетсяДля эксабайт холодного, редко читаемого архивного видео — сколько стоит этот конфиг и какая схема лучше?
Сниппет 3 — дифф синка
def sync_changes(local_file, remote_version):
local_chunks = [sha256(c) for c in chunk(local_file)]
remote_chunks = remote_version.chunk_hashes
to_upload = [h for h in local_chunks if h not in set(remote_chunks)]
upload(to_upload) # затем коммить новую версию со списком local_chunksПользователь дописывает абзац в файл на 200 МБ (~50 чанков). Примерно что это грузит и что демонстрирует?
Сниппет 4 — счётчик просмотров
def record_view(video_id):
db.execute(
"UPDATE videos SET views = views + 1 WHERE id = ?", video_id
) # один синхронный UPDATE на просмотр
# вирусное видео тянет ~200 000 просмотров/секундуПри ~200 000 просмотров/секунду на вирусном видео — что делает этот счётчик и каков верный дизайн?
- 01Как заметить баг байтов-на-пути-данных в обработчике загрузки и в чём починка?
- 02Дан конфиг 3× репликации для холодных данных и синхронный счётчик на просмотр — что меняешь и почему?
Каждое решение медиа в этом юните проявляется в коде, что можно прочесть. Обработчик загрузки, читающий всё тело и пишущий блоб в базу, — баг байтов-на-пути-данных — чини его presigned URL, чтобы клиент грузил напрямую в объектное хранилище, а база держала лишь ссылку-метаданные. Конфиг 3× репликации для холодных архивных данных тратит +200% накладных — переведи холодные данные на erasure coding (10+4 ≈ 1.4×, 4-потери), держа репликацию для малых горячих объектов. Дифф синка, сравнивающий хеши чанков, грузит лишь чанки с новыми хешами (~4–8 МБ для дописывания абзаца), суть delta-синка и где кросс-версионный дедуп выпадает бесплатно. А синхронный UPDATE на просмотр — горячая строка, что рушится под вирусной нагрузкой — сделай счёт eventually consistent, логируя события и агрегируя асинхронно. Сеньорская привычка одна во всех четырёх: найди, где байты или согласованность обрабатываются неверно, и выбери починку, что уважает структуру, а не маскирует её.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.