Обмен данными между двумя параллельно работающими шаблонами

Enigma

Client
Регистрация
16.06.2017
Сообщения
187
Благодарностей
31
Баллы
28
Планируется "шаблон1" с большим количеством блоков. Первые ~30% блоков будет идти сбор нужной информации для создания подходящего профиля (условно говоря). Как только нужную инфу собрал - сразу же нужно начать регистрацию с использованием этого профиля, причем параллельно выполнению основного "шаблона1", который ждать не может и продолжает собирать следующую порцию данных (они, в свою очередь, определят дальнейшие шаги после регистрации).
Если говорить проще, то "шаблон1" будет заниматься сбором инфы, а "шаблон2" - параллельным применением этой инфы.

Вопрос в том, как правильно организовать взаимодействие между этими шаблонами, чтобы не было костылей.

Насколько я понимаю, как только "шаблон1" соберет нужную инфу - нужно запускать батник "шаблона2", который будет выполнять регистрацию.
Однако как передать второму шаблону информацию собранных данных? "Проект в проекте" здесь явно не подходит, хотя было бы прекрасно если была бы галочка "не ждать завершения выполнения", но ее нет :-)
Глобальные переменные тоже, видимо, не подходят, т.к. взаимодействующих пар "шаблон1"-"шаблон2" будет несколько, и все переменные, естественно, будут разные.

В голову приходит только одна идея: обмен данными через файл. Например, "шаблон1" собрал инфу, сохранил файл, его подхватил "шаблон2", извлек данные и начал работу.
И в дальнейшем уже через этот файл "шаблон1" и "шаблон2" будут обмениваться флагами и данными.

Но, может быть, есть более цивилизованное решение, которое я упускаю из виду?

Если все же решение обмена данными через файл окажется оптимальным, то как лучше сделать, чтобы пара шаблонов четко знали, что это их файл (а не файл другой пары)? Имя файла = переменная?

Благодарю за уделенное время.
 

[Pacman]

Client
Регистрация
29.05.2017
Сообщения
279
Благодарностей
168
Баллы
43
В голову приходит только одна идея: обмен данными через файл. Например, "шаблон1" собрал инфу, сохранил файл, его подхватил "шаблон2", извлек данные и начал работу.
И в дальнейшем уже через этот файл "шаблон1" и "шаблон2" будут обмениваться флагами и данными.

Если все же решение обмена данными через файл окажется оптимальным, то как лучше сделать, чтобы пара шаблонов четко знали, что это их файл (а не файл другой пары)? Имя файла = переменная?

Благодарю за уделенное время.
По моему опыту(скромному) работа через файл оптимальный вариант.

По поводу батников и прочего, это все лишнее.
Можно сделать следующим образом.
Запущено 2 шаблона.
1.Первый шаблон парсер, парсит все что нужно и добавляет в файл то что напарсил, и пусть себе парсит так тут все понятно.
2.Второй шаблон тоже запущен постоянно. Подключен тот же файл.
У шаблона нужно сделать проверку. "Есть ли в данном файле информация удовлетворяющая заданным условиям"
Другими словами напарсил ли первый шаблон данные или нет. Если нет то таймер, и снова проверка.
Если да то забирает данные для разового действия из файла с их удалением и работает с ними. С удалением для того что бы брать каждый раз свежие данные, иначе он будет отрабатывать только по одним данным которые первые занесутся в файл. Отработал, снова проверка и так по кругу.
Про по кругу лучше не зацикливать, и сделать эдакий счетчик, 10-50 раз не взял файл, шаблон остановить. Зацикливание это плохо. Но это отступление от заданной темы.

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

Насколько понял, вы имеете ввиду что будет 20 потоков и нужно 20 файлов?
Нет! Хватит и одного файла. Хоть для 100 потоков. Парсеры добавляют в файл данные, а регистраторы забирают с удалением. То есть следующий поток который будет забирать данные заберет другие, так как эти уже забрал предыдущий поток и удалил из этого файла. Таким образом будет достаточно хорошо построена логика, и потоки не будут пересекаться. А если нужно что бы данные с парсера сохранялись, то просто сохраняйте их в 2 файла, один рабочий для регистратора, другой для себя как архив.
 
Последнее редактирование:
  • Спасибо
Реакции: Enigma и LiMe

Enigma

Client
Регистрация
16.06.2017
Сообщения
187
Благодарностей
31
Баллы
28
Большое спасибо за развернутый ответ! Он помог мне взглянуть на ситуацию как бы со стороны. Очень признателен.
 
Регистрация
15.04.2016
Сообщения
647
Благодарностей
107
Баллы
43
По моему опыту(скромному) работа через файл оптимальный вариант.

По поводу батников и прочего, это все лишнее.
Можно сделать следующим образом.
Запущено 2 шаблона.
1.Первый шаблон парсер, парсит все что нужно и добавляет в файл то что напарсил, и пусть себе парсит так тут все понятно.
2.Второй шаблон тоже запущен постоянно. Подключен тот же файл.
У шаблона нужно сделать проверку. "Есть ли в данном файле информация удовлетворяющая заданным условиям"
Другими словами напарсил ли первый шаблон данные или нет. Если нет то таймер, и снова проверка.
Если да то забирает данные для разового действия из файла с их удалением и работает с ними. С удалением для того что бы брать каждый раз свежие данные, иначе он будет отрабатывать только по одним данным которые первые занесутся в файл. Отработал, снова проверка и так по кругу.
Про по кругу лучше не зацикливать, и сделать эдакий счетчик, 10-50 раз не взял файл, шаблон остановить. Зацикливание это плохо. Но это отступление от заданной темы.

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

Насколько понял, вы имеете ввиду что будет 20 потоков и нужно 20 файлов?
Нет! Хватит и одного файла. Хоть для 100 потоков. Парсеры добавляют в файл данные, а регистраторы забирают с удалением. То есть следующий поток который будет забирать данные заберет другие, так как эти уже забрал предыдущий поток и удалил из этого файла. Таким образом будет достаточно хорошо построена логика, и потоки не будут пересекаться. А если нужно что бы данные с парсера сохранялись, то просто сохраняйте их в 2 файла, один рабочий для регистратора, другой для себя как архив.
А не лучше ли в этой ситуации сделать сохранение данных не в 1 файл, а в 1 папку? Каждый цикл сохранения будет создавать свой файл, с уникальным названием (рандомный набор букв).
Проект, который забирает инфу с файлов, будет сканировать и при наличии брать данные, удаляя за собой файл.
Поставить таймер на сканирование 10-15 секунд или добавить батник, который будет в вечном цикле синхронизировать количество попыток в ЗП и количество файлов в папке (такой проект можно зациклить, т.к. там всего 2 действия и он вообще незаметен).
В моих проектах стоит именно такой метод (ну и MySql ещё), ибо если мы все в 1 файл пихаем - в итоге получается конфликт и какие-то данные теряются или пишутся дважды. Этого не произойдет при работе с отдельными файлами.
 
  • Спасибо
Реакции: proffman

[Pacman]

Client
Регистрация
29.05.2017
Сообщения
279
Благодарностей
168
Баллы
43
А не лучше ли в этой ситуации сделать сохранение данных не в 1 файл, а в 1 папку? Каждый цикл сохранения будет создавать свой файл, с уникальным названием (рандомный набор букв).
Проект, который забирает инфу с файлов, будет сканировать и при наличии брать данные, удаляя за собой файл.
Поставить таймер на сканирование 10-15 секунд или добавить батник, который будет в вечном цикле синхронизировать количество попыток в ЗП и количество файлов в папке (такой проект можно зациклить, т.к. там всего 2 действия и он вообще незаметен).
В моих проектах стоит именно такой метод (ну и MySql ещё), ибо если мы все в 1 файл пихаем - в итоге получается конфликт и какие-то данные теряются или пишутся дважды. Этого не произойдет при работе с отдельными файлами.
Не сталкивался с таким что бы писалось дважды или терялось. Возможно если будет ну ооочень большой многопоток. Такой метод возможно целесообразен, если этот файл будет критически большим, то есть уменьшать скорость работы, то наверно да, целесообразно разбить на разные файлы. Опять же рандомный набор букв не пойдет, так как в теории может произойти перезапись даже если взять длинное название файла, лучше видимо счетчик с глоб переменной.
В общем метод специфический, более сложный в реализации, и нужно больше прописывать, но в некоторых случаях возможно будет лучшем решением, при неэффективности первого метода, в остальных случаях вряд-ли целесообразен.
 

Кто просматривает тему: (Всего: 2, Пользователи: 0, Гости: 2)