3 место МногоПоток. Исключаем параллельное использование данных. (MySQL)

[AleXPrischepA]

Доброго времени форумчане, коллеги и просто прохожие....

Все мы, рано или поздно приходим к многопоточным шаблонам. А с многопотоком обязательно приходит вопрос "КААААК???" организовать ЗАПРЕТ на параллельное использование данных?! Ибо результаты "такого многопотока" никому не нужны...

Предлагаю вашему вниманию своё видение/решение этого вопроса. А вижу и понимаю я это так: если есть 2 "работника" и более, ТО уже нужен старший / управляющий, по другому практически невозможно.

И так есть 2 шаблона болванки: Manager.zp и Worker.zp (далее М и W соответственно), логика работы:
1) W генерирует уник. id_key и сохраняет его в таблицу tb_key нашей БД, с пометкой request. Также в БД сохраняется текущее время в unix формате (время требуется для контроля за ключами).
2) М видя ключ с пометкой request, берёт его и помечает свободные данные со статусом ready, в рабочих таблица tb_accounts и tb_proxy данным ключом + присваивает статус work / выдаёт работу W, и сам id_key помечается как work.
3) W получив "задание" - исполняет его, после чего помечает свой id_key как stop.
4) М видя id_key с пометкой stop, меняет статус данных на chill, а id_key удаляется из таблицы.

Спойлер: Таблица tb_key

Спойлер: Таблица tb_accounts

Спойлер: Таблица tb_proxy

!!! В таблице tb_key, данные столбца id_key помечены как PRIMARY KEY, это означает что даже если будет сгенерирован НЕ уникальный id_key, при попытке его сохранить в БД, сама база данных не позволит этого сделать.

Кроме раздачи заданий Manager.zp:
1) Выдаёт задачи с некоторой задержкой по времени. (полезно для "нагруженных" шаблонов, дабы равномерно распределить пиковые нагрузки, в результате одновременного выполнения которых, можно "положить" всю работу)
2) Удаляет ключи из таблицы tb_key которые небыли удаленны из-за какого либо сбоя.
3) Освобождает данные в таблицах tb_accounts и tb_proxy которые заняты длительное время (в результате каких либо ошибок).
4) Следит чтоб данные "ОСТЫЛИ" некоторое время, после использования.
5) Обеспечивает равномерное использование всех данных, в работу идут первыми данные которые дольше простаивают.

Все тайминги можно регулировать прямо на лету, так как они хранятся в таблице tb_config и подтягиваются по необходимости.

!!! ОБРАТИТЕ ВНИМАНИЕ !!! При задании временных промежутков/таймингов, на соответствующий ему комментарий. Если временные промежутки буду заданы НЕ верно = параллельное использование данных.

Почему именно так?! Потому что после сброса блокировки данных, данные помечаются статусом "ready" (готовы к использованию).

Спойлер: Таблица tb_config

Для работы шаблону необходимо:
1) База данных (у меня установлен Open Server 5.3.7, файл импорта БД приложу)
2) Для подключения к БД во входных настройках шаблона указать: имя БД, IP сервера, имя и пароль пользователя.
3) Дописать шаблоны под себя + заполнить таблицы своими данными.

Спойлер: Входные настройки

Для удобной работы с БД можно использовать HeidiSQL (установочный файл в архиве).

 

[ShikoFess]

А почему бы просто не сделать поле status, присвоить ему по умолчанию 0. Брать только WHERE status=0 и присваивать забранному аккаунту status = 1. Ты никак не возмешь этот же аккаунт в многопотоке

 

[Ахилес]

А почему бы просто не сделать поле status, присвоить ему по умолчанию 0. Брать только WHERE status=0 и присваивать забранному аккаунту status = 1. Ты никак не возмешь этот же аккаунт в многопотоке

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

 

[AleXPrischepA]

А почему бы просто не сделать поле status, присвоить ему по умолчанию 0. Брать только WHERE status=0 и присваивать забранному аккаунту status = 1. Ты никак не возмешь этот же аккаунт в многопотоке

Какое время пройдет между получением данных со status=0 и последующим присвоением этим данным status = 1 ?
При +/- параллельном старте потоков, как с добрым утром получишь параллельное использование.

 

[Jeronimo]

AleXPrischepA намудрили вы конечно)

Задача решается гораздо проще с помощью блокировки таблицы через запрос, и статус аккаунта в таблице БД.
В таблице с аккаунтами должен быть столбец "Статус".
Обычно он принимает следующие значения: free, busy, ban.

Алгоритм работы:
1. Рабочий поток отправляет SQL запрос на получение username аккаунта (с которым он будет в дальнейшем работать) по определённым критериям (например, только со статусом free). Открывается сессия, выполняет блокировка таблицы (чтобы другие потоки не могли к ней обращаться) по заданным критериям в переменную заносится username аккаунта. Далее в этой же сессии происходит смена статуса аккаунта (username которого получили ранее) на busy. Далее разблокировка таблицы и закрытие сессии. Все эти действия выполняются в одном c# кубике за доли секунды, что позволяет с высокой скоростью обращаться за нужными данными, избегая работы одних и тех же аккаунтов в разных потоках.
2. Выполняется SQL запрос на получение нужных данных по полученному username (куки, пароль и т.п.). Далее уже текущий поток начинает работу с аккаунтом. По завершении работы отправляет SQL запрос на смену статуса аккаунта на free.

Работаю по такому алгоритму достаточно давно. Нагрузка на БД большая, запросов очень много, но при этом ни один поток не работает одновременно с одним и тем же аккаунтом.

 

[AleXPrischepA]

AleXPrischepA намудрили вы конечно)

Согласен... , про блокировку и c# слышал, знаю... Но нужно знание c#, коих у меня маловато..., а стандартными кубиками блокировки нет, в рамках одного подключения к БД, два и более запроса не выполнить.

 

[Ахилес]

Jeronimo про

Согласен... , про блокировку и c# слышал, знаю... Но нужно знание c#, коих у меня маловато..., а стандартными кубиками блокировки нет, в рамках одного подключения к БД, два и более запроса не выполнить.

не крутится весь мир вокруг C#....
изучите как работает механизм транзакций (ну хотя бы для начала https://blog-kopilka.ru/blog/transaction) и сразу станет ясно что речь идет про одну атомарную транзакцию, которую можно и нужно выполнять за один раз... ну и естественно стандартный кубик легко с этим справится... ведь он отправляет только текст... а вот смысловой текст уже зависит от уровня знания SQL языка.

 

[ShikoFess]

Согласен... , про блокировку и c# слышал, знаю... Но нужно знание c#, коих у меня маловато..., а стандартными кубиками блокировки нет, в рамках одного подключения к БД, два и более запроса не выполнить.

Так я тебе тоже самое и написал, ок про блокировку не указал в сообщении. Мудреный шаб получается слишком. https://zenno.club/discussion/threads/zagotovka-dlja-raboty-s-bd-mysql-v-kubike-c.64766/ Вот тут все есть просто 1 кубиком C# решается с локом бд

 

[Jeronimo]

Согласен... , про блокировку и c# слышал, знаю... Но нужно знание c#, коих у меня маловато..., а стандартными кубиками блокировки нет, в рамках одного подключения к БД, два и более запроса не выполнить.

Честно говоря, и я не знаток c#. Лет 5 назад мне за 20$ написали кусочек кода, который юзаю по сей день.
Готов поделиться им с комьюнити бесплатно:

Спойлер

project.Variables["username"].Value = null; //не обязательно!!! Только для обнуления переменной, если не перезапускаете шаблон полностью

Sql sqlConn = new Sql(project); //Подключаемся к БД
var cmd = sqlConn.Cmd();
cmd.Connection.Open(); //открываем сессию
cmd.DbLock("" + project.Variables["bd_tableName"].Value + " WRITE"); //Блокируем таблицу

var reader = cmd.ExReader(String.Format("SELECT username FROM "+ project.Variables["bd_tableName"].Value +" WHERE STATUS='free' LIMIT 1;")); //Получаем username аккаунта, подходящего по условиям запроса.

if(reader.HasRows) //проверяем имеются ли данные в ответе. Если имеются, то переходим к считыванию
{
    while (reader.Read()) // построчно в цикле (while) считываем данные. Получим максимум 1 строку, т.к. в запросе стоит LIMIT 1
    {
        string dbUsername = reader["username"].ToString(); //получаем задание. В нашем случае это ссылка для парсинга.
        project.Variables["username"].Value = dbUsername; //сохраняем link в переменную зеннопостера
    }
}
reader.Close();

//Обновление статуса. Выполняется только если было получено задание (если id не пустое!)
if(!string.IsNullOrEmpty(project.Variables["username"].Value))
{
    //после получения задания необходимо поменять статус задания, чтобы другие потоки больше его не видели после разблокировки таблицы
    cmd.ExNonQ(String.Format("UPDATE "+ project.Variables["bd_tableName"].Value +" SET status='busy' WHERE username= '" + project.Variables["username"].Value + "';"));
}
    
cmd.DbUnLock(); //разблокировка всех таблиц
cmd.Connection.Close(); //закрываем сессию

 

[Ахилес]

Честно говоря, и я не знаток c#. Лет 5 назад мне за 20$ написали кусочек кода, который юзаю по сей день.
Готов поделиться им с комьюнити бесплатно:

Спойлер

project.Variables["username"].Value = null; //не обязательно!!! Только для обнуления переменной, если не перезапускаете шаблон полностью

Sql sqlConn = new Sql(project); //Подключаемся к БД
var cmd = sqlConn.Cmd();
cmd.Connection.Open(); //открываем сессию
cmd.DbLock("" + project.Variables["bd_tableName"].Value + " WRITE"); //Блокируем таблицу

var reader = cmd.ExReader(String.Format("SELECT username FROM "+ project.Variables["bd_tableName"].Value +" WHERE STATUS='free' LIMIT 1;")); //Получаем username аккаунта, подходящего по условиям запроса.

if(reader.HasRows) //проверяем имеются ли данные в ответе. Если имеются, то переходим к считыванию
{
    while (reader.Read()) // построчно в цикле (while) считываем данные. Получим максимум 1 строку, т.к. в запросе стоит LIMIT 1
    {
        string dbUsername = reader["username"].ToString(); //получаем задание. В нашем случае это ссылка для парсинга.
        project.Variables["username"].Value = dbUsername; //сохраняем link в переменную зеннопостера
    }
}
reader.Close();

//Обновление статуса. Выполняется только если было получено задание (если id не пустое!)
if(!string.IsNullOrEmpty(project.Variables["username"].Value))
{
    //после получения задания необходимо поменять статус задания, чтобы другие потоки больше его не видели после разблокировки таблицы
    cmd.ExNonQ(String.Format("UPDATE "+ project.Variables["bd_tableName"].Value +" SET status='busy' WHERE username= '" + project.Variables["username"].Value + "';"));
}
   
cmd.DbUnLock(); //разблокировка всех таблиц
cmd.Connection.Close(); //закрываем сессию

Sql sqlConn = new Sql(project); //Подключаемся к БД

а толку от этого кусочка кода, когда нет кастомного класса Sql из общего кода ?

 

[AleXPrischepA]

изучите как работает механизм транзакций (ну хотя бы для начала https://blog-kopilka.ru/blog/transaction) и сразу станет ясно что речь идет про одну атомарную транзакцию, которую можно и нужно выполнять за один раз... ну и естественно стандартный кубик легко с этим справится...

Благодарю за наводку...

 

[ShikoFess]

Работают со множествов шабов в многопотоке по примерам из ссылке выше. Ни разу не было замечено чтобы разные потоки брали один аккаунт. Все работает как часы

 

[WebBot]

Все это делается в два запроса, без всяких блокировок таблиц и прочих танцев с бубном

первый запрос меняет статус строки .. при UPDATE происходит автоматическая блокировка на уровне строк таблицы (не всей таблицы, а только строки которая апдейтиться), поэтому 1 и ту же строку не могут апдейтить одновременно несколько потоков, а после апдейта и разблокировки строки она уже не будет подходить по параметрам ( status уже будет не 0 )

UPDATE tbl SET id=LAST_INSERT_ID(id), status=1 WHERE status=0 LIMIT 1

следующей функцией получаем id той строки статус которой был изменен

SELECT LAST_INSERT_ID()

такое работает если нужно что бы каждый поток брал 1 строку ... и UPDATE и SELECT должны выполняться в одной сессии

 

[Ахилес]

Все это делается в два запроса, без всяких блокировок таблиц и прочих танцев с бубном

первый запрос меняет статус строки .. при UPDATE происходит автоматическая блокировка на уровне строк таблицы (не всей таблицы, а только строки которая апдейтиться), поэтому 1 и ту же строку не могут апдейтить одновременно несколько потоков, а после апдейта и разблокировки строки она уже не будет подходить по параметрам ( status уже будет не 0 )

UPDATE tbl SET id=LAST_INSERT_ID(id), status=1 WHERE status=0 LIMIT 1

следующей функцией получаем id той строки статус которой был изменен

SELECT LAST_INSERT_ID()

такое работает если нужно что бы каждый поток брал 1 строку ... и UPDATE и SELECT должны выполняться в одной сессии

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

START TRANSACTION;

UPDATE tbl
SET id = LAST_INSERT_ID(id), status = 1
WHERE status = 0
LIMIT 1;

SELECT LAST_INSERT_ID();

COMMIT;

 

[DeepFarm]

string zapros = @"LOCK TABLES webhook WRITE;
SELECT data FROM webhook WHERE mode=""odobr"" LIMIT 1;
DELETE FROM webhook WHERE mode=""odobr"" LIMIT 1;
UNLOCK TABLES;";

project.Variables["responce"].Value = ZennoPoster.Db.ExecuteQuery(zapros, null, ZennoLab.InterfacesLibrary.Enums.Db.DbProvider.MySqlClient, "server="+project.Variables["hostMySQL"].Value+";user id="+project.Variables["loginMySQL"].Value+";password="+project.Variables["passMySQL"].Value+";database="+project.Variables["baseMySQL"].Value+";port="+project.Variables["portMySQL"].Value+"", " ", "");

Вот запрос в c# без колдовства... берет одну строку - одним потоком

 

[Petr_G]

Благодарю за наводку...

И open server совсем не нужен! Mysql прекрасно ставится на windows.

 

[marushin]

И open server совсем не нужен! Mysql прекрасно ставится на windows.

и намертво приколачивается к системе, быкапы только через сам мускул, нельзя скопировать просто директорию. с open server, копируй - переноси куда хочешь

По теме, в MySQL уже всё придумано, нет смысла что то изобретать. Как выше ответили, транзакции решают вопрос многопотока, собственно они для этого и нужны.

 

[Wide]

быкапы только через сам мускул

HeidiSQL

 

[marushin]

HeidiSQL

А что не так, HeidiSQL через мускул быкап делает, те же яйца только сбоку.
В open server просто копируешь папку.