Скажите, я тут в более-менее правильном направлении разглагольствовал?
https://qna.habr.com/q/700342
https://qna.habr.com/q/700342
Нельзя. Ну так второй тупо ждать будет. И мы получим замедление вместо ускорения.без лока прочитать можно, но в 2 потоках захватить лок нельзя
Ну так задача изначально - избежать конкуренции, а не поставить всё коломблокировка на запись выполнит задачу не дать другому воркеру прочитать строку, и не начать её обарабывать, что бы это ни значило
CREATE TABLE `test1` (
`id` int(11) NOT NULL,
`data` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `test1` (`id`, `data`) VALUES
(1, 1),
(2, 1);
ALTER TABLE `test1`
ADD PRIMARY KEY (`id`);
#1 thread
mysql> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Query OK, 0 rows affected (0,00 sec)
mysql> START TRANSACTION;
Query OK, 0 rows affected (0,00 sec)
mysql> select * from test1 where data=1 limit 1 for update;
+----+------+
| id | data |
+----+------+
| 1 | 1 |
+----+------+
1 row in set (0,00 sec)
#
# выполняем #2thread
#
mysql> update test1 set data=2 where id=1;
Query OK, 1 row affected (0,00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0,03 sec)
mysql>
#2 thread
mysql> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Query OK, 0 rows affected (0,00 sec)
mysql> START TRANSACTION;
Query OK, 0 rows affected (0,00 sec)
mysql> select * from test1 where data=1 limit 1 for update;
#
# ОЖИДАЕТ
# вывод после commit из #1thread
+----+------+
| id | data |
+----+------+
| 2 | 1 |
+----+------+
1 row in set (34,30 sec)
mysql>
Ну вот в этом "ОЖИДАЕТ" ведь всё и дело!ОЖИДАЕТ
Гриш, ну в данном случае вопрос не в диссертации а в небольшом усилии чтобы вникнуть в задачувопрос настолько глубокий, что тут можно писать докторскую и посвятить этому жизнь
запомни id обнови data и закоммиться сразу, чтоб другие не ждали.Нам как раз не нужно чтобы ожидало! Нам надо чтобы летало! Чтобы разные воркеры не цепляли работу друг друга.
Ну я этот вариант и написал в ответе на тостере - что нужен третий статус.запомни id обнови data и закоммиться сразу, чтоб другие не ждали.
Почти.Скажите, я тут в более-менее правильном направлении разглагольствовал?
https://qna.habr.com/q/700342
У тупого шардирования есть недостаток: не получится просто так добавить пачку воркеров. Хорошо, конечно, если количество воркеров заранее планируется в соответствии с ростом нагрузки, но обычно воркеры добавляются, когда "блин, а че у нас очереди растут и растут?".Поэтому тупое шардирование мне кажется будет решать проблему куда лучше.
тут кстати не хватает информации worker_id=42 или чтото в этом роде, иначе не понятно какой из 2х "processing" принадлежит конкретному worker. при этом worker_id=42 - уж очень странная информациялибо UPDATE ... SET status = 'processing' WHERE status = 'queued',
Нет.Скажите, я тут в более-менее правильном направлении разглагольствовал?
https://qna.habr.com/q/700342
update table set
guid = {$GUID}
where ... limit 1;
... много кода ...
update table set
....
guid = null
where guid = {$GUID};