Как стать автором
Обновить

Комментарии 15

Забыли указать язык на который переписали сервис.
Но исходя из упоминания горутин можно предположить что так тщательно скрывали Go/Golang.

Антифрод, конечно, много что скрывает, но не в этот раз :)


В качестве основного инструмента распараллеливания был выбран Golang, по которому в компании есть хорошая экспертиза.
Что есть? ;)
Почему не удалось запускать несколько php процессов?
Как я понял все правила применяются в рамках одного водителя/клиента и это должно хорошо решаться запуском нескольких consumer

Этот вариант, безусловно, рассматривали, но аргументы были простыми в нашем случае.
1) Пока не перепишем модель запускать несколько consumer'ов опасно — быстрее положим базу.
2) На самой модели завязано порядка 70% кода.
3) Невозможно нормально параллелить независимые части одной проверки водителя/клиента или организовать какие то более сложные потенциальные зависимости.


То есть в итоге переписывание модели было неизбежно. Раз уж переписывать 70% кода, тогда можно переписать все сразу на Go и иметь возможности лучшего масштабирования в будущем.

Почему выбрали ElasicSearch? У нас стоял примерно такой же выбор — между денормализованной RDBMS и ES. Остановились на Postgres'e. У ES'a преимущество было только в оптимизированном full-text поиске.

Для построения отчетов по пойманным событиям нам нужна была OLAP подобная база в нашем случае. OLTP базу настраивать для аналитических целей всегда непросто: когда перед тобой десятки полей по которым хотят искать и агрегировать, то тяжело настроить правильно индексы. При необходимости быстрого поиска по новому полю, нужно делать альтеры.
Мы выбрали ElasticSearch как компромисс между OLTP и OLAP.
В эластике удобно: индекс по каждому полю, возможность агрегации и, как вы упомянули, full-text поиск, если он понадобится.
У меня нет опыта в администрировании Postgres, но кажется что маcштабировать ElasticSearch легче — так как его разработчики на старте продукта закладывали туда шардирование, реплицирование, алиасы и прочее.

А разве не MySQL у вас выступает в качестве OLTP? У нас четкое разделение: OLTP-операции проходят на разнородных базах и сервисах (обычно через 2PC), а в специальную базу для OLAP операций мы пишем только при синхронизации с основными базами (сразу прогоняем обновленную часть записи через очередь, обычно там не так много изменений за 1 раз).

MySQL конечно и есть OLTP, но он база монолита в первую очередь. Этот MySQL у нас источник данных — множество баз и таблиц. И работать по ним напрямую антифрод не может без риска положить их. Соответственно мы в начале переносим данные в ElasticSearch, а потом их же используем для анализа на фрод.

Сколько у вас на данный момент правил для антифрода?

Число приближается к сотне.

Есть значения текущей нагрузки?

Если брать проверку водителя/клиента, то порядка 50к rpm. Если учитывать анализ действия пользователей, то в пиковые часы доcтигало 3к rpS.

Ваша задача в теории* хорошо ложится на хранимые процедуры — все данные изначально лежат в базе, можно создать очередь задач и СУБД сама решит как их выполнять, в каком потоке, на каком ядре или ноде кластера, сама разберется с блокировками.

Скрытый текст
* К сожалению, теория от практики существенно отличается и мы 15 лет назад в похожей ситуации обнаружили вагон и маленькую тележку проблем:
— сама СУБД должна быть достаточно продвинутая, с хорошим языком запросов (T-SQL, PL/SQL), ей должно быть выделено достаточно ресурсов для выполнения ХП. При этом надо надеяться, что процедуры таки выполняться именно параллельно, а не по одной в одном потоке, блокируя все намертво;
— в общем случае набор правил быстрее и удобнее всего писать прямо в виде кода процедуры (или нескольких). За пару месяцев эта процедура (или сотня процедур) становятся страшным монстром, в котором мало кто разбирается, а покрыть это все тестами совсем не просто;
— заказчик не может сам писать правила и должен все время дёргать программиста. Если же таки заказчику нужен интерфейс и логика для работы с правилами, то мы падаем в бездонную кроличью нору, разрабатывая либо собственный интерпретатор правил в хранимой процедуре, либо компилируя правила в SQL код, который потом включается в процедуру. Оба варианта съедают жуткое количество времени на разработку и отладку.

В итоге мы сидели над этими хранимками долгие месяцы и мечтали все переписать на людский язык программирования, пока проект благополучно не закрылся :)

Написано очень красиво, но на самом деле дела обстоят не так радужно.
Отдел работает на 3 с минусом.

Описываю ситуацию своего автопарка в системе ситимобил. id 12294 парка.
В один день подключились 2 человека под видом водителей, как привлеченные лица на своих машинах. Сделали по одному заказу за наличные средства. Каждый заказ длился несколько минут несмотря на то, что дальность поездки была 280 километров по 1 заказу. По второму меньше. По окончании поездки водитель сумел выплатить сдачу на счет клиента ( баланс водителя был нулевой) ))))
По итогу автопарк попал на комиссию ситимобил за поездки которых не было!!!
Выданную сдачу несуществующему клиенту))))))

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

По обращению в ситимобил письма и звонки 2 недели!!! Антифродовая проверка в карточке водите ляпоказывала- ВСЕ OK!!!
написано 5 обращений, по результату мы получили супер ответ:

«Добрый день!
Вернуть д/с за заказ возможности нет, т.к. клиент, который получил сдачу за заказ, потратил бонусы.
На данный момент идёт разработка методов борьбы с мошенническими действиями.»

Вообщем на словах все здорово и статья классная, на практике пофигизм и отсутствие работы. За свой непрофессионализм они расплатились деньгами таксопарка.
Как система показывала, что проверка антифродовая проведена и все ОК, если заказ 280 км длился менее 5 минут.?
Как систему ненасторожило проблемы с показаниями gps?
Как система позволила выплатить сдачу на счет клиента при 0 балансе водителя?
Вообщем сотрудникам данного отдела стоит подумать над своей работой

Зарегистрируйтесь на Хабре , чтобы оставить комментарий