- Регистрация
- 07.09.2016
- Сообщения
- 134
- Реакции
- 132
- Баллы
- 43
Всем привет. Поднял на своем (физическом) сервере парочку мобильных проксей на 3g/4g модемах, на разных операторах. Скорость работы шаблона на каждом из операторов разная. Работаю с аккаунтами из таблицы, в таблицу записываю саму проксю и айпиху модема, для того что бы шаблон перед загрузкой страницы передергивал модем.
Возникла следующая проблема, т.к. я каждому аккаунту присваиваю свою проксю, и работаю только с ней, необходимо сделать так, что бы в многопотоке прокси не пересекались, т.е. не происходило такого, что бы 2 аккаунта сразу взяли одну и ту же проксю и каждый из них ее передернул. На мой взгляд есть 2 решения этой задачи: либо сделать несколько копий шаблона по числу таких проксей и запускать каждый из них в 1 потоке, либо сделать все в одном шаблоне, но нужна проверка на занятость прокси. Первый вариант, конечно же не вариант, т.к. 2-3 модема еще можно запускать несколько копий, а вот 10 модемов уже такое себе.
Поэтому рассмотрел несколько вариантов второго решения:
1 вариант. Тупо разложить акки в правильном порядке, идея херня, т.к. шаблон на разных операторах да и на одном отрабатывают с разной скоростью и в конечном итоге порядок собьется.
2 вариант. Реализация именно проверки на занятость прокси. Решил сделать таблицу в которой в одном столбце прописал ip модемов, а во втором статус, таблица привязывается к файлу. Шаблон работает по следующей логике: берется аккаунт обычным зенковским кубиком ищу строку в таблице содержащую текст (ip модема) и сохраняю значение статуса в переменную. Следующим кубиком проверяю соответствует ли эта переменная статусу свободной прокси и если да, то уже шарпом записываю в нужную ячейку статус занятости, а дальше шаб работает в штатном режиме, передергиват проксю и делает хорошие дела. Если же нет, то следует пауза 5-6 секунд и опять повторяю кубик зенковский куб работы с таблицей. Выглядит это так
Т.е. по моей логике, из-за того, что в таблице аккаунты с разными проксями не чередуются по очереди, а могут идти подряд несколько штук, такой шаблон запущенный в количестве потоков превышающих количество проксей, все будет нормально работать, т.е. акки будут просто висеть в ожидании пока освободится прокся. На деле оказалось не так, почему-то после некоторого количества выполнений все же в разных потоках запускается одна и та же прокся. Такое может произойти только в том случае если одновременно 2 и более аккаунтов получают статус прокси, что она свободна, но понятие "одновременно" относительно. Я начиная работать с зенкой усвоил главный урок, что привязка таблицы к файлу позволяет работать в многопотоке и не будет возникать проблем с перезаписыванием данных. Оказывается данные записываются в файл из привязанной таблицы не достаточно быстро.
Хотел переписать этот блок шаблона полностью на шарпе (типа работает быстрее чем кубики), но по идее смысла нет, ведь проблема в самой таблице привязанной к файлу.
Подскажите как лучше можно решить мою задачу?
Возникла следующая проблема, т.к. я каждому аккаунту присваиваю свою проксю, и работаю только с ней, необходимо сделать так, что бы в многопотоке прокси не пересекались, т.е. не происходило такого, что бы 2 аккаунта сразу взяли одну и ту же проксю и каждый из них ее передернул. На мой взгляд есть 2 решения этой задачи: либо сделать несколько копий шаблона по числу таких проксей и запускать каждый из них в 1 потоке, либо сделать все в одном шаблоне, но нужна проверка на занятость прокси. Первый вариант, конечно же не вариант, т.к. 2-3 модема еще можно запускать несколько копий, а вот 10 модемов уже такое себе.
Поэтому рассмотрел несколько вариантов второго решения:
1 вариант. Тупо разложить акки в правильном порядке, идея херня, т.к. шаблон на разных операторах да и на одном отрабатывают с разной скоростью и в конечном итоге порядок собьется.
2 вариант. Реализация именно проверки на занятость прокси. Решил сделать таблицу в которой в одном столбце прописал ip модемов, а во втором статус, таблица привязывается к файлу. Шаблон работает по следующей логике: берется аккаунт обычным зенковским кубиком ищу строку в таблице содержащую текст (ip модема) и сохраняю значение статуса в переменную. Следующим кубиком проверяю соответствует ли эта переменная статусу свободной прокси и если да, то уже шарпом записываю в нужную ячейку статус занятости, а дальше шаб работает в штатном режиме, передергиват проксю и делает хорошие дела. Если же нет, то следует пауза 5-6 секунд и опять повторяю кубик зенковский куб работы с таблицей. Выглядит это так
Т.е. по моей логике, из-за того, что в таблице аккаунты с разными проксями не чередуются по очереди, а могут идти подряд несколько штук, такой шаблон запущенный в количестве потоков превышающих количество проксей, все будет нормально работать, т.е. акки будут просто висеть в ожидании пока освободится прокся. На деле оказалось не так, почему-то после некоторого количества выполнений все же в разных потоках запускается одна и та же прокся. Такое может произойти только в том случае если одновременно 2 и более аккаунтов получают статус прокси, что она свободна, но понятие "одновременно" относительно. Я начиная работать с зенкой усвоил главный урок, что привязка таблицы к файлу позволяет работать в многопотоке и не будет возникать проблем с перезаписыванием данных. Оказывается данные записываются в файл из привязанной таблицы не достаточно быстро.
Хотел переписать этот блок шаблона полностью на шарпе (типа работает быстрее чем кубики), но по идее смысла нет, ведь проблема в самой таблице привязанной к файлу.
Подскажите как лучше можно решить мою задачу?
