Multi-account management

[JohnPaine]

тащемто нужно сделать

• мультиаккаунт - в конфиге прописываем множество аксесстокенов, на каждый из них пул vkuser-ов.

• менеджемнт этого пула: приграшение аккаунта в чат, кик аккаунта из чата, статы аккаунтов

• балансировка нагрузки: выбор наименее загруженного аккаунта и приглашение его в чат, с автовыходом.

[detorto]

Есть мнение что нужно частично переделать арихитектуру

Основные сущности и их функции:

• тюлень:

  • работает от имени одно аккаунта
  • инкапсулирует в себе получение сообщений и ответы на них
  • модульная структура (как есть)
  • имеет механизм информирования мастер-процесса о различных событиях (обо всех событиях?)
    • очереди сообщеий вроде rabbitmq/zeromq?
    • события: срабатывание модуля (нужно доработать модули), заявка в друзя, другое
  • имеет API для управления (опять же очереди сообщеий?):
    • приглашение друга в беседу, уход из беседы, пост на стену, etc
  • фактически то что есть сейчас, с минимальными правками
  • должен уметь работаь без мастера, в режиме одного аккаунта.

• мастер процесс:

  • запускат пул тюленей со соответвующиеми конфиг-файлами

    • в конф файле предлагается использовать лист путей к акссес-файлам различных тюленей

  • является сервером очереди сообщеий?

    • тюлень при запуске регестрируется в ней и получает свой идентификатор (кажется, rabbit умеет все это)

  • предоставляет централизованое управление блэклистом:

    • просессы тюленя при запуске плучают от него блеклист
    • при добавлении уида в блеклист об этом информируется мастерпроцесс
    • при добавлении уида в блеклист мастер рассылает инфо об этом другим тюленям

  • делает управление нагрузкой:

    • основываясь на сообщениях с тюленей, создает представление о их загруженности (ответов в минуту)

    • имеется мастер-тюлень, сообщения о добавление в беседу которого обрабатываются следующим образом

      • выбрается самый слабозагруженный тюлень и ему посылается сообщение
      • мастер-процесс посылает сообщение мастер-тюленю о необходимости пригласить этого тюленя в беседу
      • мамтер процесс посылает сообщение мастер-тюленю о необходимости выйти из этой беседы

  • в песпективе: web-api и сайтик со статами и кнопками управления

Собственно первое что нужно сделать - мастер-процесс и механизм сообщеий.

• sealsbreeder.py [мастер процесс]
  - запускает сервер сообщений
  - читает файл кофнфигурации и запускает множество тюленей посредстом обычного Process. никаких threading и мы хотим что бы операционка распределяла процессы по ядрам нативно.
  реализует колбеки на различные сообщения (модульно? хардкод?)
  - считает нагрузку тюленей

• seal.py [надо бы переименовать наконец то]
  - добавить поддержку сообщений между мастером и им