16. erlang

v0.6

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

Так это еще не все. Мы не просто машины состояний, мы еще и сервера сообщений. При этом же. OTP Эрланга можно будет положить полностью. И еще останется непридуманных программерами сущностей.

А теперь на секундочку к Эрлангу.Мы можем задавать любые аппликации с любыми методами взаимодействия сообщениями. Нужно задать правила, при которых выживать будут самые умные процессы. Надо дать им эволюцию - во всей ее блядь красе. Если я напишу такое - я это пойму.

Сможет ли так зародиться разум - я не знаю. Но двигаемся мы в правильном направлении.

Так вот, поведение человека наверняка смоделировать можно. Мы просто запишем некую машину состояний и воздействующих сообщений. Нам очень нужна непрерывная во времени, не дискретная, модель? Для рассмотрения ее с больших масштабов - политических, рекламных, исторических - хватит и дискретной машины состояний. Это для маленьких групп нужна большая точность. Как обычно - самое интересное труднодостижимо.

А борются за что люди? За силу, за счастье. Свет из жил друг у друга забирают. Честно ли это? Смотря с кем? Вот с тобой, если ты в жизни никого не обижал, не издевался, не пнул собачку - нельзя. Это и есть борьба такая. Вместог того, чтобы делать счастливыми себы, люди стараются сделать несчастными окружающих. И так чувствуют себя счастливее. Я понимаю что это звучит как психическое отклонение, за которое хочется пиздить. Но у нас сейчас это практически норма. Единственное что не дает пойти откопать стаорый пулемет - большая часть все-таки делает это неосознанно.

Оу! Параллельно можно даже моделировать что попроще - тараканов например. Потому как разумные особи у нас разнообразием не блещут - начнем с моделирования поведения тараканов в их головах. Шутка. Начнем с моделирования тела - именно оно определяет нашу среду существования. Потом инстинкты, рефлексы, привычки. Очень внимательно рассмотрим механизмы засирания сознания царям природы.

Но все равно - мы хотим модель члена социума. Так что конечный результат - все таки человек.

Спарк!

Центральным объектом должен стокен - отпшный апп_сервер, знающий связность между пуш-токенами и email-адресами (ящиками). Некая база, умеющая отвечать на один вопрос. За этими знаниями к ней потянутся все - и воркеры, и ENQL-щики. Воркеры - по необходимости - чтобы узнать свой пуш-токен и чтобы быстро находить своих коллег по несчастью - для формирования бейджа. Воркерам же поручается после первого получения всей необходимой для формирования пуша инфы хранить ее для дальнейших действий. И даже более того - именно к ним будут приходить в итоге настройки от клиента. А уже они по желанию их куда-нибудь дополнительно запишут. На всякий.

Почему мы сейчас не так делаем?

Фактически задача поддержания постоянных tcp-соединений от каждого имап-порта видится избыточной. Но красивой.

Основная идея: мы все блядь делаем не так. Одну задачу - постоянную поддержку значительного количества соединений и обработки инфы из них мы наконец-то научились вроде более-менее нормально делать. А вот вторую самую сложную задачу не только не решили - но еще и отодвинули ее решение к чертям. Я считаю, что почти вся инфа, необходимая для отправки пуша должна находиться в распоряжении обрабатывающего соединения кода - модуля, класса, еще кого - на самом деле все равно. Основное вот что надо сделать. Потому как все дальнейшие пуши нужно будет отправлять от этого самого имап-соединения. И все пуши с этого ящика отправляются на одни и те же. токены. Или не отправляются. И изменятся эта информация достаточно медленно. И мы сможем при запросе с клиента в течении секунд (хочется доли секунды - но эт если не на нагруженную) изменить параметрыименно в нужной точке - я с апп-токеном притопаю в стокен и по нему с ящиком узнаю pid процесса, обрабатывающего это соединение. Потому что он приходил за токеном. За пеуш токеном - нах ему апп сдался?

Так вот, а у нас мало того что вычислительные ресурсы расходуются на базы данных и очереди, так они еще и забиваются или лочаться и задерживают поток информации. А мы за них платим тащемта. Нахрена?

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

Г-г-г-г. Вот я вам и покажу что я имел в виду когда говорил о разнице мышлений на самом деле. Вот нахрена нужен минимализм и эстетствующий аскетизм.

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

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

Так, теперь о самом главном. Как я это вижу. Оговорюсь сразу - у меня тут только основная цепочка сообщений - пуши с имапа на apn и их же бейджи. Но вроде как с момента запуска это и есть самый большой геморр.

Писать хочу на эрланге. А что? Язык зрелый, годами доказанный. Вы на их с айт посмотрите! Они ж бедные, у них нихрена нет денег на лишние сервера - они вынуждены писать красиво)))

Мне, если чесно, кажется, что именно после этой схемы вы уже сами должны зажечься идеей. Я конечно это все и по вечерам сделаю, но уж очень уставать начал, не мальчик уже.

Каждое имап-соединение заворачиваем в эрланговский Порт - недопроцесс, умеющий только сообщать что ему пишут. И что его обрабатывает воркер. Сообщать он об этом будет своему обсерверу - "полю" таких же соединений. Размер поля предлагаю определять экспериментально. Я не уверен что хочу держать 260к связей у одного процесса, Но в то же время не вижу никакой необходимости в добавлении дополнительного слоя. Т.е. если они возьмут по 20к коннекшнов - я буду удовлетворен. Если по 2к - нет. Но даже тут можно бдудет что-то придумать, хотя уже не так и прикольно - не кластер взаимовыручающих обсерверов, так лишний слой обсерверов - опять хрен знает на что ресурсы тратим. Но вроде не замедляем поток сообщений. В общем и целом, судя по документации и словам Ромы, 260к процессов, не перегружающих проц никого сосбо напрягать не должны. Для простоты каждому из них прямо в зубы всучим все необходимые для формирования пушей с этого мыла данные. И, если помните, обеспечим условия для быстрого обновления этой инфы. И еще и позволяем отыскать этот процесс для отправки сообщения - надо просто спросить у знающего пиды всех 260к (Редис? Или сможем проиндексировать прямо в памяти у стокена? В эрланге наверняка можно построить какое-нибудь бинарное дерево или хеш! Это в JS у меня даже множества простого нет из коробки). Вторая лично меня уже не слишком шокирующая новость - воркер отвязывается от коннекшна. Легковесные воркеры а-ля nginx всем скопом обрабатывают поле несвоих соединений. Негры на плантации! Ок, тогда их надсмотрщик - обсервер, следящий за воркерами.

Два наших обсервера, кстати, не чисто служебные скрипты. Они уже выполняют достаточно важное взаимодействие. Если воркеры на поле не справляются - поле просит у плантатора новых негров. Серьезно. При превышении какого-нибудь персентиля среднегол по полю ожидания поле жалуется плантатаору, и тот стартует еще воркеров, если достаточно ресурсов.

А теперь самое вкусное - все это мы получаем практически из коробки. Передача сообщений, порты, сервера, машины состояний. А знаете зачем обсерверы нужны? Они служат для поддержания количества запущенных процессов. И не просто так - а одним из нескольких способов на выбор. Сразу же. Из коробки. И годами. А хотите знать что там еще есть? Виртуальная машина - облачная. Твой код выполняется сразу на всех машинах окружения. В едином адрессном пространстве. Если у них есть какая-то (у Ромы спрошу) система записи своего состояния на винт, и она будет распределяться между пятью машинами кластера - -нах нужен мускуль вообще?- остается решить проблему чтения этих данных руками. А может и запуска?

Ах, да. Дальше про схему.

Значит наш мегапродвинутый воркер (хранящий в себе ), или хай буде негр, обработал смену состояний соединения и сохранил его состояние, отчалив. При необхомисти проверил пуш на соответствие enql - наверняка найдутся причины сделать это отдельно от воркера. Письмо будет отправлено на адрес pusher0 - для облачка пушеров можно наверное попробовать одноранговую сетку с первым роутером. К нему же подключаются все остальные... Не, нафига колесо изобретать, да? Кинь отдельный сервер-обсервер и не парься. Нужно будет оптимизировать - займешься. Да, и пушеры у нас - просто Порты, можно даже с одним на всех обсервером-обработчиком.

Клиентгейт - простой веб-сервер, должны быть наверняка. Counter за тем же сервером. Клиентгейт может даже где-то как-то дождаться отправки своего письма сендером.

В принципе можно даже так кардинально и не сносить все. Один кеш аккаунтов на воркерах уже ускорит систему. Но я ни капельки не хочу убирать базу из js проекта. А из erlang мне кажется можно.

в проектирование конструкта

механизм мотивации для процессов

Придумать для фишеров как завязать качество и скорость их работы и количество направляемых на него сообщений - первое правило. Потому как реальзовать форк при превышения порогового значения для длины входной очереди или объема обработанного трафа не выглядит сильно сложеым. Эти два правила дадут фишерам стимул развития в сторону, необходимую нам. Дать бы им еще возможность развиваться. Потому как просто запустить разные типы Фишера не интересно.

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

Об\ясняю еще раз - мы только что придумали как "мотивировать" процесс на развитие. Нехватает негативного ограничения - убийства процессов с наименьшим количеством обрабатываемых сообщений. И механизмов изменчивости - при форке и/или при жизни процессов. В биологии есть и те, и те. Первые - смешение генов родителей, второй - накачиваемость определенных органов и даже систем. Можно сказать, что со внешними условиями мы определились и осталось разобраться со внутренними.

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

механизм мотивации для людей

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

Применение

Граф такого плана можно использовать для контроля еад распространением заболеваний в обществе. Это если нас заботят передающие эти заболевания контакты. Например - заболеваний венерических, типа сифилиса. Или умственных, типа поцреатизма. Или душевных, вроде желаний насиловать маленьких девочек.(Уверены что не заразно? Вы проверяли?А если я приведу статистику проблем с наервами по врачам психушки? А если покажу механизмы распространения?Модельки там всякие? А текперь что вы хотите услышать ву предсказании: я расскажу что вам завтра приснится или изменение орбиты еще не до конеца обнаруженной планеты?)