Мы в Badoo для конфигурационных файлов демонов используем как раз json. Похачили сишную json либу и теперь можем делать комментарии и оставлять последнюю запятую в списках.
А расскажите, пожалуйста, что такое CC и чем оно отличается от стандартных Фотошопов прошлого? Судя по названию Cloud программа теперь активно работает с сетью? Или не может работать без сети?
Демонов у нас штук 15 наберется, думаю. Они написаны на Си (на С++ есть несколько), используют асинхронную обработку (libevent). Перед тем как делать какую-то задачу, мы думаем можно ли ее сделать какими-то существующими продуктами. Если нет — пишем свой демон.
Черт, я перепутал наши топики на хабре. Прошу прощения. Подумал что вы спрашиваете про демон событий.
Возвращаясь к вашему вопросу. Глобально на этот вопрос не смогу, но по поводу поиска скажу что он — самописный демон. Очень шустрый, довольно сложный и данные для поиска находятся на одной машине. Слияние не нужно.
По поводу остального думаю кто-то из моих коллег еще ответит.
Данные пользователей хранятся не только в памяти, но и сохраняются на диск, поэтому уведомления не теряются [при перезапуске демона]. Каким образом вы обеспечиваете durability и высокую производительность [25kreq/s]? append-only + fsync на несколько событий или иным способом? Возможна ли все-таки потеря данных при падении демона?
Раз в n минут (для этого демона сделано вроде раз в 5-10 минут, если память не изменяет) демон форкается и потомок сохраняет новые данные в очередной файл изменений. Раз в k минут (1 или 2 часа, вроде) демон форкается и потомок сохраняет полный снепшот данных на диск. При загрузке, соответственно, сначала грузится последний снепшот, а затем накатываются изменения.
Таким образом, при падении демона, мы можем потерять новые события за максимум n минут + время на поднятие демона. Демон не настолько критичный, т.к. сами данные не теряются (они в реляционной СУБД), а событиями за небольшой промежуток времени можно пренебречь (пользователь все равно увидит новые события зайдя на сайт). Тем более что падения демона довольно редкое событие.
Временами n и k можно управлять, конечно. Основные затраты — время на системный вызов fork(). В случае если демон сжирает значительное кол-во памяти (скажем 60 GiB и больше), системный вызов fork() может выполняться 1-2 секунды, что недопустимо. Демон о котором здесь идет речь занимает в памяти примерно 4-5 GiB.
Некоторые демоны шардируются по user_id, некоторые шардируются по странам. Многие из них реплицируют данные на другую площадку (у нас на данный момент по 1 площадке на каждом полушарии).
В случае репликации консистентность опять же обеспечивается по-разному. В зависимости от типа хранимых данных. Например по времени. Типа «реплика, у тебя какое последнее время обновления? ну на тебе то что новее, теперь мы одинаковые». Это не 100% консистентность, но для наших задач ее хватает.
На ПХП написана вся «обертка» над этими демонами. Там куча логики и бизнеса. Взаимодействие между демонами (в плане работы с информацией) тоже на ПХП.
Кроме того на ПХП написано громадное кол-во скриптов, которые делают какие задачки в фоне.
Badoo очень большой проект все-таки.
Сейчас еще исследуем применимость Go для написания демонов. Беспокоит GC.
Возвращаясь к вашему вопросу. Глобально на этот вопрос не смогу, но по поводу поиска скажу что он — самописный демон. Очень шустрый, довольно сложный и данные для поиска находятся на одной машине. Слияние не нужно.
По поводу остального думаю кто-то из моих коллег еще ответит.
Раз в n минут (для этого демона сделано вроде раз в 5-10 минут, если память не изменяет) демон форкается и потомок сохраняет новые данные в очередной файл изменений. Раз в k минут (1 или 2 часа, вроде) демон форкается и потомок сохраняет полный снепшот данных на диск. При загрузке, соответственно, сначала грузится последний снепшот, а затем накатываются изменения.
Таким образом, при падении демона, мы можем потерять новые события за максимум n минут + время на поднятие демона. Демон не настолько критичный, т.к. сами данные не теряются (они в реляционной СУБД), а событиями за небольшой промежуток времени можно пренебречь (пользователь все равно увидит новые события зайдя на сайт). Тем более что падения демона довольно редкое событие.
Временами n и k можно управлять, конечно. Основные затраты — время на системный вызов fork(). В случае если демон сжирает значительное кол-во памяти (скажем 60 GiB и больше), системный вызов fork() может выполняться 1-2 секунды, что недопустимо. Демон о котором здесь идет речь занимает в памяти примерно 4-5 GiB.
В случае репликации консистентность опять же обеспечивается по-разному. В зависимости от типа хранимых данных. Например по времени. Типа «реплика, у тебя какое последнее время обновления? ну на тебе то что новее, теперь мы одинаковые». Это не 100% консистентность, но для наших задач ее хватает.