Идеальное время

20 Ноября 2010 Программирование
3 0

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

Пользователь заполнил форму со своими данными и отправил форму серверу. На сервере записи было установлено текущее время регистрации, и по каким-то причином код встал. Что-то подвисло почти на две минуты. У нас есть защита от повторной отправки формы, но каким-то макаром она не сработала и сервер получил второй запрос на регистрацию. Видимо это связано было с тем, что сервер протормозил с первым запросом.

У второй строки пользователя было установлено время регистрации и код пошел работать дальше. И тут самое интересное. Видимо первый сервер или другой поток, в котором спал первый запрос проснулся и две формы начали обрабатываться сервером одновременно. Система вставила в базу данных строку и установила время создание записей абсолютно одинаковым в плодь до миллисекунд. Ну ладно, такое возможно, что сервер вставляет две записи в одну и ту же миллисекунду. Я такого правда не видел, но допускаю.

После вставки нового пользователя ему прописывается куча дополнительных возможностей, добавляются уровни доступа и привелегии, и после этого строка пользователя обновляется. Во время обновления, изменяется и поле modified, которое отражает время последнего обновления записи. И тут оно снова идеально совпадает у двух записей. Просто идеальное совпадение вплодь до миллисекунд.

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

Защитится от подобного можно, но не нужно. Каждый дополнительный уровень защиты будет стоить производительности. А самое страшное что может быть, это один и тот же пользователь подпишется к своему же банковскому аккаунту два раза. Ничего страшного не вижу. За пять лет это произошло впервые.

В нашем случае отличной защитой являются ETL скрипты, которые тянут данные из рабочей базы в OLAP. После перетягивания на OLAP базе выполняется куча проверок, которые проверяют данные, чтобы не было никаких косяков. И если они вылавливают это, то я могу отреагировать и исправить код или данные. В данном случае имели смысл просто удалить один аккаунт пользователя и не заморачиваться.

В данном случае меня просто поразила швейцарская точность платформы Microsoft .NET и SQL Server.

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым