Забыть md5

Интересно, но я до сих пор считал, что md5 хеш в текстовом представлении (32 символа) для идентификации объектов — весьма не плохо. И коллизии маловероятны. Тем не менее, если не нужно привязываться к контенту объектов (как в git, к примеру, который, к слову, использует более длинный sha1), то можно поискать что-то более интересное и короткое.

Например, почитав статью Размещение, можно заключить, что у md5 при длине 32 символа возможно 16^32 вариантов. Это отлично! Однако не всегда нужно, поэтому могу предложить более простую реализацию: используя все символы английского алфавита и цифры можно получить достаточное количество вариантов ключей, надо лишь подобрать нужную длину для вашей задачи. При 5 (пяти, всего пяти!) знаках — это уже почти миллиард вариантов.

Это не моя идея, сервисы сокращения интернет ссылок используют этот механизм уже давно, но задуматься об эффективности перехода с md5 меня заставили собственные текущие задачи.

Регистрационный код по электронной почте, верификационный код какой-либо купонной системы, ссылка на информационный UGC элемент… Тут есть выигрыш при использовании более короткого кода. Хотя бы от того, что сам код становится менее страшным для человека (психологический момент использования сервиса) или ссылки в коде страницы станут короче (в случае UGC) — страница меньше и быстрее.

Это всё копейки. Но по копейкам набегают миллионы 😉

/*
 * Пример генерации кода на PHP
 */
function makeCode() {
  $a = '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; // 62 символа
  $l = strlen($a) - 1;
  $c = $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] .
  $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)] . $a[rand(0, $l)]; // 10 знаков
  return $c; // число возможных размещений: 62^10 = 8,392993659*10^17
}

PS: На коллизии не забывайте проверять!

комментария 2 »29.03.2012 13:00:25 | Изобретаю | ,

Грабельки deployment при наличии opcode кэша

Привет, PHP разработчик, администратор или релиз-менеджер! Наткнулся на интересное, спешу поделиться.

Дано:

Проект на PHP, одновременно работающий в режиме разработки («DEV», из SVN), а также боевом режиме («LIVE»), в который переводится ветка DEV после отлова багов. Сервер примечателен только тем, что PHP запускается через php-fpm и там включено opcode кэширование. У меня нижеследующее проявилось и при XCache и при APC.

Надо:

Перевести отлаженный проект из режима разработки в режим работы.

Решаем:

Итак, имеем примерно такую структуру проекта (ненужное вырезано):

.../dev/
       /app/
           /index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
       conf.php       : <?php $me = 'dev';
.../live/
       /app/
           /index.php : <?php require dirname(__FILE__).'/../conf.php'; print $me;
       conf.php       : <?php $me = 'live';

Два виртуальных хоста в web сервере берут данные из …/dev/ и …/live/, где лежит соответствующий код. Всё работает, opcode кэш ускорят работу, все счастливы. Запрос на …/dev/app/index.php возвращает «dev», на …/live/app/index.php — «live».

Но вот пришла пора выложить код из DEV в LIVE как можно более быстро и без глюков. Понятно, что вариантов море, один из пришедших в голову был таков: для deployment использовать 2 команды переименования каталогов. Это на самом деле весьма «дешево»: операционная система сделает очень мало работы в очень короткое время, сбои крайне маловероятны:

mv .../live/app .../bak && mv .../dev/app .../live

И вот в очень короткое время мы переместили код. Всё хорошо? Нет! Запрос на …/live/app/index.php возвращает «dev», сайт работает с тестовыми данными разработчика! 🙁

Расследование:

Собственно, поиск причины был не сильно долгим. Мы переместили ветку файловой системы, идентификаторы файлов («inode») внутри ветки не поменялись и op-кэш наивно думает, что ничего не поменялось, т.к. он идентифицирует код по идентификатору файла. Ну и в итоге в окружении LIVE лежит файл, который запускается интерпретатором PHP со включенным файлом конфигурации на момент попадания в кэш — это был файл из DEV ветки. Вот так.

Итого мораль — при переносе дерева файлов PHP в рамках обработчика PHP с включенным opcode кэшированием вы продолжаете использовать старый закэшированный код, даже если включенные из перенесенных файлы поменялись.

Что делать?

Один из вариантов, и как мне кажется правильный — это запустить два экземпляра php-fpm обработчика. Отдельно для DEV и LIVE окружений. Или полностью исключить некоторые файлы из кэширования.

Комментариев нет »10.02.2012 12:38:48 | Делаю | , ,