Такой код недавно обсуждали в чате.

Задача

Здесь, судя по коду, требуется генерировать уникальные короткие ссылки “аля ютуб”, с проверкой на то, занята уже ссылка или нет.

Что если бы стояла задача сделать его максимально надёжным и производительным?

Решение

Я обошёлся бы вообще без обращения к БД.

Допустим у нас потолок системы это 1 миллион записей в сутки.

У нас есть восемь байт из примера.

Кодируем в первые два байта порядковый номер дня начиная с даты 1 января 1970 по UTC. Просто делим таймстемп на количество секунд в сутках и вуаля. Это даст нам отрезок до 2150 года.

Оставшиеся 6 байт будут случайными.

Сгенерировали миллион случайных строк, положили в Redis в виде списка.

Выдаëм эти коды по одному, например командой RPOP. Прошëл день — сгенерировали ещë пачку.

Можем напрямую у Redis запрашивать, можем в красивый сервис обернуть с HTTP интерфейсом. Тут уже по вкусу.

Redis однопоточный, поэтому Race Condition не будет.

Быстро, стабильно, надëжно. Гарантия отсутствия коллизий. Сумасшедшее быстродействие. Константная сложность. Короткие хеши.

Как это без коллизий?

Всё просто. Мы проверим отсутствие коллизий ещë на этапе генерации до сохранения списка в Redis.

Это будет очень быстро благодаря тому, что мы работаем только с оперативной памятью в PHP, не обращаясь к внешним источникам.

Ну а в целом вероятность того что хотя бы один шестибайтовый хеш повторится в миллионном списке, это 1 к 281 миллиардам.