Создаём с нуля высоконагруженное приложение на Tarantool10.07.2020 19:18

В 2013 я пришел в Mail.ru Group, и я решал задачу, в которой мне нужна была очередь. Есть много разных инструментов для построения очередей, но я решил для начала узнать, что уже имеется в компании. Услышал, что есть такой продукт — Tarantool. Узнал, как он устроен, и мне показалось, что в него отлично может быть встроен брокер очередей.

Я пошёл к главному по Tarantool — Косте Осипову — и постарался объяснить, что я хочу получить. Предполагалось, что код очереди будет написан на C, как и остальной код Tarantool, но… На следующий день Костя дал мне скрипт на 250 строк, который реализовывал почти всё, что я хотел.

С того момента я влюбился в Tarantool. Оказалось, что можно написать совсем немного кода на очень простом скриптовом языке и получить совершенно новую для этой СУБД функциональность.

Прошло много времени, Tarantool развивался, в том числе и под влиянием наших запросов, но основные идеи и подходы сохранились. Я расскажу, как реализовать собственную очередь на современном Tarantool, например версии 2.2.

На тот момент я был знаком с несколькими реализациями очередей, и мне нравился простой и быстрый Beanstalkd. У него довольно удобный интерфейс, отслеживание состояния задачи по соединению (обрыв клиента возвращал задачу в очередь), а также удобные возможности по работе с отложенными задачами. При реализации очереди мне хотелось получить что-то подобное.

Сам сервис можно представить следующим образом: у нас есть процесс брокера очереди, который принимает и хранит задачи; есть клиенты: продюсеры, которые приносят задачи (метод put); и консюмеры, которые берут задачи в работу (метод take).

Жизненный цикл одной задачи можно описать следующей схемой. Задача появляется при помощи метода put и переходит в состояние ready. Операция take переводит задачу в taken. Из taken задача может быть обработана (ack) и удалена, или возвращена в ready (release).

Также мы можем расширить эту диаграмму и ввести дополнительно отложенную обработку задач:

Подготовка окружения

Tarantool сегодня — это, в том числе, LuaJIT-интерпретатор. Чтобы начать с ним работать, нужно создать стартовый файл init.lua, точку входа, и прописать там вызов box.cfg(), который запускает внутренности СУБД.

Для локальной разработки осталось только подключить и запустить консоль. Затем создайте вот такой файл и запустите его:

require'strict'.on()

box.cfg{}

require'console'.start()
os.exit()

Консоль интерактивная, в ней сразу можно что-то делать. Не нужно долго и много устанавливать и настраивать инструменты, разбираться в них. Просто пишете 10–15 строчек на любой локальной машине

Также я рекомендую сразу включить strict. Язык Lua довольно свободен в объявлении переменных, и этот режим должен немного помочь вам при ошибках. Кстати, если собрать Tarantool самому в режиме DEBUG, то strict будет включён по умолчанию.

Далее остаётся только запустить наш файл при помощи tarantool:

tarantool init.lua

Вы должны увидеть что-то похожее:

2020-07-09 20:00:11.344 [30043] main/102/init.lua C> Tarantool 2.2.3-1-g98ecc909a
2020-07-09 20:00:11.345 [30043] main/102/init.lua C> log level 5
2020-07-09 20:00:11.346 [30043] main/102/init.lua I> mapping 268435456 bytes for memtx tuple arena...
2020-07-09 20:00:11.347 [30043] main/102/init.lua I> mapping 134217728 bytes for vinyl tuple arena...
2020-07-09 20:00:11.370 [30043] main/102/init.lua I> instance uuid 38c59892-263e-42de-875c-8f67539191a3
2020-07-09 20:00:11.371 [30043] main/102/init.lua I> initializing an empty data directory
2020-07-09 20:00:11.408 [30043] main/102/init.lua I> assigned id 1 to replica 38c59892-263e-42de-875c-8f67539191a3
2020-07-09 20:00:11.408 [30043] main/102/init.lua I> cluster uuid 7723bdf4-24e8-4957-bd6c-6ab502a1911c
2020-07-09 20:00:11.425 [30043] snapshot/101/main I> saving snapshot `./00000000000000000000.snap.inprogress'
2020-07-09 20:00:11.437 [30043] snapshot/101/main I> done
2020-07-09 20:00:11.439 [30043] main/102/init.lua I> ready to accept requests
2020-07-09 20:00:11.439 [30043] main/104/checkpoint_daemon I> scheduled next checkpoint for Thu Jul  9 21:11:59 2020
tarantool> 

Пишем очередь

Создадим отдельный файл queue.lua для написания нашего приложения. Конечно, можно было бы писать всё прямо в init.lua, но работать с отдельным файлом будет удобнее.

Подключим queue в виде модуля из файла init.lua:

require'strict'.on()

box.cfg{}

queue = require 'queue'

require'console'.start()
os.exit()

Все дальнейшие модификации мы будем делать в queue.lua.

Поскольку мы делаем очередь, нам понадобится где-то хранить информацию о задачах. Создадим спейс (space) — таблицу для данных. Можно создавать его без опций, но мы сразу кое-что добавим. Чтобы нормально перезапускаться, мы укажем, что спейс нужно создавать только в том случае, если он не существует (if_not_exists). Также в современном Tarantool можно указывать формат полей с описанием содержимого (лучше так и делать). Так мы и поступим.

Под очередь возьмём совсем простую структуру. Мне понадобятся только id задач, их статусы и какие-то произвольные данные. Мне не важно, что там будет лежать. Работать с данными без первичного индекса нельзя, поэтому сразу создадим индекс по id. Проверяйте, чтобы тип поля совпадал и в формате, и в индексе.

box.schema.create_space('queue',{ if_not_exists = true; })

box.space.queue:format( {
    { name = 'id';     type = 'number' },
    { name = 'status'; type = 'string' },
    { name = 'data';   type = '*'      },
} );

box.space.queue:create_index('primary', {
   parts = { 1,'number' };
   if_not_exists = true;
})

Объявим глобальную таблицу queue, которая будет нести в себе наши функции, атрибуты и методы. И для начала объявим две функции: положить задачу (put) и взять задачу (take).

У задач в очереди будут состояния. Для обозначения статуса заведём отдельную таблицу со статусом. В качестве значения можно использовать числа или строки, но я люблю использовать однобуквенные значения: их можно выбрать семантически значимыми и они занимают минимум места при хранении. Для начала сделаем два статуса: R=READY и T=TAKEN.

local queue = {}

local STATUS = {}
STATUS.READY = 'R'
STATUS.TAKEN = 'T'

function queue.put(...)

end

function queue.take(...)

end

return queue

Как сделать put? Очень просто. Нам нужно сгенерировать id и вставить данные в спейс со статусом READY. Есть много разных способов генерирования идентификатора, мы возьмём clock.realtime. Для очереди он хорош тем, что автоматически определяется порядок сообщений (но учтите, что часы могут жёстко переводиться, и в этом случае порядок задач может быть нарушен). Также, теоретически, может возникнуть ситуация, когда в очереди уже будет задача с таким же значением. Поэтому можно посмотреть, нет ли задачи с таким id, и в случае коллизии добавить единицу. На это уйдут микросекунды, и это крайне маловероятная ситуация, поэтому производительность не пострадает.

Все аргументы функции мы просто вставляем в качестве начинки в нашу задачу:

local clock = require 'clock'
function gen_id()
    local new_id
    repeat
        new_id = clock.realtime64()
    until not box.space.queue:get(new_id)
    return new_id
end

function queue.put(...)
    local id = gen_id()
    return box.space.queue:insert{ id, STATUS.READY, { ... } }
end

Как только мы написали функцию put, можем перезапустить Tarantool и сразу вызвать эту функцию. Видим, что задача положена в очередь, она выглядит как тапл (кортеж). В него можно класть произвольные данные и даже вложенные структуры. Таплы, в которых Tarantool хранит данные, упаковываются в MessagePack, что позволяет сохранять такие структуры.

tarantool> queue.put("hello")
---
- [1594325382148311477, 'R', ['hello']]
...

tarantool> queue.put("my","data",1,2,3)
---
- [1594325394527830491, 'R', ['my', 'data', 1, 2, 3]]
...

tarantool> queue.put({ complex = { struct = "data" }})
---
- [1594325413166109943, 'R', [{'complex': {'struct': 'data'}}]]
...

Всё, что мы кладём, находится в спейсе. Можно взять команды спейса и посмотреть, что там лежит.

tarantool> box.space.queue:select()
---
- - [1594325382148311477, 'R', ['hello']]
  - [1594325394527830491, 'R', ['my', 'data', 1, 2, 3]]
  - [1594325413166109943, 'R', [{'complex': {'struct': 'data'}}]]
...

Теперь нужно научиться брать задачи — сделаем функцию take. Для этого поработаем со статусом. Мы берем те задачи, которые готовы к обработке, то есть находятся в статусе READY. Можно было бы, конечно, пройтись по первичному ключу и найти первую готовую задачу, но в условиях нагрузки и большого количества обрабатываемых задач этот сценарий нам не подойдёт. Нужен отдельный индекс по полю статуса. Одна из основных черт Tarantool, которые отличают его от key-value баз, это возможность создавать различные индексы, почти как в реляционных базах: на разные поля, композитные, разного типа.

Создадим второй индекс, в котором укажем, что первое поле — это статус. По нему и будем искать. А второе поле — это id. Он упорядочит по возрастанию задачи в рамках одного статуса.

box.space.queue:create_index('status', {
    parts = { 2, 'string', 1, 'number' };
    if_not_exists = true;
})

Возьмём встроенные функции для выборки. Есть специальный итератор, который применяется к спейсу как pairs. В него мы передаем часть ключа. Здесь мы сталкиваемся с составным индексом, который состоит из двух полей: ищем по первому, а упорядочиваем по второму. Говорим системе найти нам таплы, которые по первой части индекса равняются статусу READY. И будем их получать уже упорядоченными по второй части индекса. Если мы что-то нашли, то берём задачу, обновляем и возвращаем. Обновляем для того, чтобы никто другой, кто придет с таким же вызовом take, не взял её. Если задач нет, то возвращаем ничего.

function queue.take()
    local found = box.space.queue.index.status
        :pairs({STATUS.READY},{ iterator = 'EQ' }):nth(1)
    if found then
        return box.space.queue
            :update( {found.id}, {{'=', 2, STATUS.TAKEN }})
    end
    return
end

Также стоит обратить внимание на то, что первый уровень тапла в Tarantool представлен в виде массива. Он не имеет имен, он нумерованный, поэтому при таких операциях, как update, до совсем недавнего времени нужно было указывать номер поля. В качестве вспомогательного элемента сделаем табличку, в которой сопоставим имя поля и номер. Для формирования этой таблицы мы можем воспользоваться уже описанным нами форматом:

local F = {}
for no,def in pairs(box.space.queue:format()) do
    F[no] = def.name
    F[def.name] = no
end

Для большей наглядности можем поправить описание индексов:

box.space.queue:format( {
    { name = 'id';     type = 'number' },
    { name = 'status'; type = 'string' },
    { name = 'data';   type = '*'      },
} );

local F = {}
for no,def in pairs(box.space.queue:format()) do
    F[no] = def.name
    F[def.name] = no
end

box.space.queue:create_index('primary', {
   parts = { F.id, 'number' };
   if_not_exists = true;
})

box.space.queue:create_index('status', {
    parts = { F.status, 'string', F.id, 'number' };
    if_not_exists = true;
})

Теперь можно реализовать take целиком:

function queue.take(...)
    for _,t in
        box.space.queue.index.status
        :pairs({ STATUS.READY },{ iterator='EQ' })
    do
        return box.space.queue:update({t.id},{
            { '=', F.status, STATUS.TAKEN }
        })
    end
    return
end

Проверим, как это работает. Положим одну задачу и вызовем take дважды. Если к этому моменту у нас есть данные в спейсе, можем его очистить командой box.space.queue:truncate():

tarantool> queue.put("my","data",1,2,3)
---
- [1594325927025602515, 'R', ['my', 'data', 1, 2, 3]]
...

tarantool> queue.take()
---
- [1594325927025602515, 'T', ['my', 'data', 1, 2, 3]]
...

tarantool> queue.take()
---
...

Первый take возвращает нам ту самую задачу, которую мы положили. А когда вызовем take повторно, то больше ничего не вернется, потому что ready-задач (в статусе R) больше нет. Можем убедиться в этом, выполнив select из спейса:

tarantool> box.space.queue:select()
---
- - [1594325927025602515, 'T', ['my', 'data', 1, 2, 3]]
...

Потребитель, который берет задачу, должен либо подтвердить её обработку, либо вернуть без обработки, если по какой-либо причине не справляется. Тогда задачу сможет взять кто-то другой. Реализуем для этого две функции: ack и release. Они принимают id задачи и ищут её. Если у задачи статус взятой, то мы обрабатываем её. Эти функции очень похожи. Одна удаляет обработанные задачи, другая возвращает их в статус ready.

function queue.ack(id)
    local t = assert(box.space.queue:get{id},"Task not exists")
    if t and t.status == STATUS.TAKEN then
        return box.space.queue:delete{t.id}
    else
        error("Task not taken")
    end
end

function queue.release(id)
    local t = assert(box.space.queue:get{id},"Task not exists")
    if t and t.status == STATUS.TAKEN then
        return box.space.queue:update({t.id},{{'=', F.status, STATUS.READY }})
    else
        error("Task not taken")
    end
end

Посмотрим, как это работает со всеми четырьмя функциями. Кладём две задачи и берём первую, затем освобождаем её. Она возвращается обратно в статус R. Второй вызов take берёт ту же задачу. Если мы её обработаем, она удалится. Третий вызов take возьмёт уже вторую задачу. Порядок соблюдается. Если задача взята, то она не выдается ещё кому-нибудь.

tarantool> queue.put("task 1")
---
- [1594326185712343931, 'R', ['task 1']]
...

tarantool> queue.put("task 2")
---
- [1594326187061434882, 'R', ['task 2']]
...

tarantool> task = queue.take() return task
---
- [1594326185712343931, 'T', ['task 1']]
...

tarantool> queue.release(task.id)
---
- [1594326185712343931, 'R', ['task 1']]
...

tarantool> task = queue.take() return task
---
- [1594326185712343931, 'T', ['task 1']]
...

tarantool> queue.ack(task.id)
---
- [1594326185712343931, 'T', ['task 1']]
...

tarantool> task = queue.take() return task
---
- [1594326187061434882, 'T', ['task 2']]
...

tarantool> queue.ack(task.id)
---
- [1594326187061434882, 'T', ['task 2']]
...

tarantool> task = queue.take() return task
---
- null
...

Получилась корректно работающая очередь. Мы уже можем написать потребителя, который будет обрабатывать задачи. Но у него есть, как минимум, одна проблема. Когда мы вызываем take, функция сразу возвращает либо задачу, либо пустую строку. Если написать цикл обработки задач и запустить его, то работать он будет, но вхолостую, ничего не делая, просто потребляя CPU.

while true do
    local task = queue.take()
    if task then
        -- ...
    end
end

Чтобы это исправить, нам понадобится примитив «канал» (или channel). Он позволяет передавать сообщения. По сути, это FIFO-очередь для общения между файберами. У нас есть файбер, который кладет задачи, когда мы приходим в базу данных по сети или работаем с ней из консоли. В файбере исполняется наш Lua-код, ему нужно через какой-то примитив сообщить другому файберу, который ждёт задачи, что появилась новая.

Канал работает так: в нем может быть буфер на N слотов, в которые можно положить сообщение, даже если никто не читает из канала. Также можно создать канал без буферной ёмкости, тогда положить можно будет только в те слоты, которые кто-то ждет. Например, мы создаем канал на два буферных элемента. В нем два слота под put. Если на канале будет ожидать один потребитель, он создаст третий слот под put. Если мы будем класть сообщения в этот канал, то три операции put выполнятся без блокировки, а четвертый put заблокирует нам тот файбер, который кладет в этот канал. Это позволяет организовать межфайберное взаимодействие. Если вдруг вы знакомы с каналами в Go, то там они фактически такие же:

Немного переделаем нашу функцию take. Сначала добавим новый аргумент — таймаут: мы готовы ждать задачу в течение определённого времени. Сделаем цикл, который будет искать готовую задачу. Если не найдёт, то будет вычислять, сколько времени ему осталось ждать.

Создадим канал, который будет ждать с этим таймаутом. Ели файбер «спит» в ожидании на канале, то его можно разбудить извне, передав сообщение в этот канал.

local fiber = require 'fiber'
queue._wait = fiber.channel()
function queue.take(timeout)
    if not timeout then timeout = 0 end
    local now = fiber.time()
    local found
    while not found do
        found = box.space.queue.index.status
            :pairs({STATUS.READY},{ iterator = 'EQ' }):nth(1)
        if not found then
            local left = (now + timeout) - fiber.time()
            if left <= 0 then return end
            queue._wait:get(left)
        end
    end
    return box.space.queue
        :update( {found.id}, {{'=', F.status, STATUS.TAKEN }})
end

Итого: take пытается взять задачу, если получилось, то возвращает её. Но если задачи не нашлось, то можно подождать в течение остатка таймаута. Причем другая сторона, которая будет производить задачу, может этот файбер разбудить.

Чтобы удобно было проводить различные тесты, можем в файле init.lua подключить модуль fiber глобально:

fiber = require 'fiber'

Давайте посмотрим, как это будет работать без пробуждения файбера. В отдельном файбере положим задачу через 0,1 с. То есть сначала очередь пустая, а через 0,1 с. после запуска появляется задача. При этом вызов take сделаем с таймаутом 3. После запуска take попытается найти задачу. Не найдя её, он уснёт на 3 с. Затем проснётся, снова поищет и найдёт задачу.

tarantool> do
    box.space.queue:truncate()
    fiber.create(function()
        fiber.sleep(0.1)
        queue.put("task 3")
    end)
    local start = fiber.time()
    return queue.take(3), { wait = fiber.time() - start }
end

---
- [1594326905489650533, 'T', ['task 3']]
- wait: 3.0017817020416
...

Теперь сделаем так, чтобы take просыпался при появлении задачи. Для этого возьмем старую функцию put и добавим в нее отправку сообщения в канал. В качестве сообщения можно отправить что угодно, пусть в этом случае будет true.

Ранее я показывал, что put может заблокироваться, если в канале недостаточно места. При этом производителю задач не важно, есть с той стороны потребители или нет. Он не должен блокироваться в ожидании потребителя. Поэтому логично поставить здесь нулевой таймаут на блокировку. Если там есть потребители, то есть те, кому нужно сообщить о новой задаче, мы его разбудим. Иначе у нас сообщение в этот канал не положится. Или, в качестве альтернативного варианта, можно проверить, есть ли у канала активные читатели.

function queue.put(...)
    local id = gen_id()

    if queue._wait:has_readers() then
        queue._wait:put(true,0)
    end

    return box.space.queue:insert{ id, STATUS.READY, { ... } }
end

После этого тот же самый код take начнет работать совершенно иначе. Мы создаём задачу через 0,1 с. и take сразу же просыпается и получает её. Мы избавились от горячего цикла, который непрерывно висел в ожидании задачи. Если мы не положим задачу, то файбер будет ждать три секунды.

tarantool> do
    box.space.queue:truncate()
    fiber.create(function()
        fiber.sleep(0.1)
        queue.put("task 4")
    end)
    local start = fiber.time()
    return queue.take(3), { wait = fiber.time() - start }
end

---
- [1594327004302379957, 'T', ['task 4']]
- wait: 0.10164666175842
...

На текущий момент мы протестировали работу внутри экземпляра, теперь поработаем по сети. В первую очередь нам нужно наш сервер сделать сервером. Добавим в файле init.lua в box.cfg опцию listen — порт, на котором он будет слушать. Вместе с этим нам понадобится сделать разрешения. Не будем сейчас детально рассматривать настройку привилегий, сделаем так, чтобы любое подключение имело привилегии на исполнение. Про права вы можете почитать отдельно.

require'strict'.on()
fiber = require 'fiber'

box.cfg{
    listen = '127.0.0.1:3301'
}
box.schema.user.grant('guest', 'super', nil, nil, { if_not_exists = true })

queue = require 'queue'

require'console'.start()
os.exit()

Создадим клиент-producer для генерирования задач. В поставке Tarantool уже есть модуль, который позволяет подключаться к другому Tarantool.

#!/usr/bin/env tarantool

if #arg < 1 then
    error("Need arguments",0)
end

local netbox = require 'net.box'
local conn = netbox.connect('127.0.0.1:3301')

local yaml = require 'yaml'
local res = conn:call('queue.put',{unpack(arg)})
print(yaml.encode(res))
conn:close()

$ tarantool producer.lua "hi"
--- [1594327270675788959, 'R', ['hi']]
...

Потребитель (consumer) будет подключаться, вызывать take с таймаутом и обрабатывать результат. Если он получил задачу, то будем печатать её и освобождать. Мы сейчас пока не будем обрабатывать. Допустим, задача получена.

#!/usr/bin/env tarantool

local netbox = require 'net.box'
local conn = netbox.connect('127.0.0.1:3301')
local yaml = require 'yaml'

while true do
    local task = conn:call('queue.take', { 1 })

    if task then
        print("Got task: ", yaml.encode(task))
        conn:call('queue.release', { task.id })
    else
        print "No more tasks"
    end
end

Но при попытке освободить задачу у нас произойдёт какая-то фигня.

$ tarantool consumer.lua 
Got task:
        --- [1594327270675788959, 'T', ['hi']]
...

ER_EXACT_MATCH: Invalid key part count in an exact match (expected 1, got 0)

Давайте разберёмся. При повторной попытке исполнения потребителя мы обнаружим, что при предыдущем запуске он задачу взял, но не смог вернуть: у него произошла ошибка и задача застряла. Такие задачи больше никто не сможет взять, но и некому их вернуть, потому что код, который их брал, завершился.

$ tarantool consumer.lua 
No more tasks
No more tasks

С помощью select можно увидеть, что задачи взяты.

tarantool> box.space.queue:select()
---
- - [1594327004302379957, 'T', ['task 3']]
  - [1594327270675788959, 'T', ['hi']]
...

Здесь есть сразу несколько проблем, поэтому давайте начнём с автоматического освобождения задач при отключении клиента.

В Tarantool есть триггеры на подключение и отключение клиентов. Если мы их добавим, то сможем о фактах подключения и отключения.

local log = require 'log'

box.session.on_connect(function()
    log.info( "connected %s from %s", box.session.id(), box.session.peer() )
end)

box.session.on_disconnect(function()
    log.info( "disconnected %s from %s", box.session.id(), box.session.peer() )
end)

2020-07-09 20:52:09.107 [32604] main/115/main I> connected 2 from 127.0.0.1:36652
2020-07-09 20:52:10.260 [32604] main/116/main I> disconnected 2 from nil
2020-07-09 20:52:10.823 [32604] main/116/main I> connected 3 from 127.0.0.1:36654
2020-07-09 20:52:11.541 [32604] main/115/main I> disconnected 3 from nil

Есть понятие session id, и можно узнать, с какого IP было подключение и время отключения. Правда, есть один нюанс. Вызов session.peer() по сути вызывает getpeername(2) непосредственно на сокете. Поэтому при отключении мы уже не видим, кто отключается (getpeername вызывается на закрытом сокете). Cделаем небольшой хак. В Tarantool есть box.session.storage — временная таблица, в которую можно сохранять всё, что хочется, на время существования сессии. Во время подключения запомним, кто к нам подключился, чтобы знать, кто отключится. Это облегчает отладку.

box.session.on_connect(function()
    box.session.storage.peer = box.session.peer()
    log.info( "connected %s from %s", box.session.id(), box.session.storage.peer )
end)

box.session.on_disconnect(function()
    log.info( "disconnected %s from %s", box.session.id(), box.session.storage.peer )
end)

Теперь у нас есть событие отключения клиента. Нам нужно как-то освободить взятые им задачи. Введем понятие «владения задачей». Та сессия, которая взяла задачу, должна за неё отвечать. Заведем две таблички, в которые будем сохранять эти данные, и модифицируем функцию take.

queue.taken = {}; -- список взятых задач
queue.bysid = {}; -- список задач для конкретной сессии

function queue.take(timeout)
    if not timeout then timeout = 0 end
    local now = fiber.time()
    local found
    while not found do
        found = box.space.queue.index.status
            :pairs({STATUS.READY},{ iterator = 'EQ' }):nth(1)
        if not found then
            local left = (now + timeout) - fiber.time()
            if left <= 0 then return end
            queue._wait:get(left)
        end
    end

    local sid = box.session.id()
    log.info("Register %s by %s", found.id, sid)
    queue.taken[ found.id ] = sid
    queue.bysid[ sid ] = queue.bysid[ sid ] or {}
    queue.bysid[ sid ][ found.id ] = true

    return box.space.queue
        :update( {found.id}, {{'=', F.status, STATUS.TAKEN }})
end

Мы в ней запомним, что конкретная задача взята конкретной сессией. Также нам понадобится модифицировать код возврата задач, ack и release. Сделаем одну общую функцию. Будем проверять, что задача есть и взята, причём взята конкретной сессией. Таким образом нельзя будет из одного соединения взять задачу, а из другого прийти и сказать: «удалите её, я обработал».

local function get_task( id )
    if not id then error("Task id required", 2) end
    local t = box.space.queue:get{id}
    if not t then
        error(string.format( "Task {%s} was not found", id ), 2)
    end
    if not queue.taken[id] then
        error(string.format( "Task %s not taken by anybody", id ), 2)
    end
    if queue.taken[id] ~= box.session.id() then
        error(string.format( "Task %s taken by %d. Not you (%d)",
            id, queue.taken[id], box.session.id() ), 2)
    end
    return t
end

Теперь функции ack и release становятся очень простыми. Мы в них вызываем get_task, который проверяет, что задача принадлежит нам и взята. И дальше уже с ней работаем.

function queue.ack(id)
    local t = get_task(id)
    queue.taken[ t.id ] = nil
    queue.bysid[ box.session.id() ][ t.id ] = nil
    return box.space.queue:delete{t.id}
end

function queue.release(id)
    local t = get_task(id)
    if queue._wait:has_readers() then queue._wait:put(true,0) end
    queue.taken[ t.id ] = nil
    queue.bysid[ box.session.id() ][ t.id ] = nil
    return box.space.queue
        :update({t.id},{{'=', F.status, STATUS.READY }})
end

Для сброса состояния всех задач в R можно воспользоваться SQL или Lua-cниппетом:

box.execute[[ update "queue" set "status" = 'R' where "status" = 'T' ]]
box.space.queue.index.status:pairs({'T'}):each(function(t) box.space.queue:update({t.id},{{'=',2,'R'}}) end)

Когда мы вызовем consumer повторно, он ответит task ID required.

$ tarantool consumer.lua 
Got task:
        --- [1594327004302379957, 'T', ['task 3']]
...

ER_PROC_LUA: queue.lua:113: Task id required

Так мы находим первую проблему в нашем коде. Когда мы работаем внутри Tarantool, кортеж всегда ассоциирован со спейсом. У того есть формат, а у формата есть имена полей. Поэтому в тапле можно пользоваться именами полей. А когда мы выносим это за пределы базы, тапл становится просто массивом с набором полей. Доработаем формат возврата из функций и будем возвращать не таплы, а объекты с именами. Для этого воспользуемся методом :tomap{ names_only = true }:

function queue.put(...)
    --- ...
    return box.space.queue
        :insert{ id, STATUS.READY, { ... } }
        :tomap{ names_only = true }
end

function queue.take(timeout)
    --- ...
    return box.space.queue
        :update( {found.id}, {{'=', F.status, STATUS.TAKEN }})
        :tomap{ names_only = true }
end

function queue.ack(id)
    --- ...
    return box.space.queue:delete{t.id}:tomap{ names_only = true }
end

function queue.release(id)
    --- ...
    return box.space.queue
        :update({t.id},{{'=', F.status, STATUS.READY }})
        :tomap{ names_only = true }
end

return queue

Поменяв это, мы столкнёмся с новой проблемой.

$ tarantool consumer.lua 
Got task:
        --- {'status': 'T', 'data': ['hi'], 'id': 1594327270675788959}
...

ER_PROC_LUA: queue.lua:117: Task 1594327270675788959ULL not taken by anybody

При попытке освободить задачу система ответит, мы её не брали. При этом визуально мы увидим, что ID один и тот же. Только есть еще какая-то суффикс ULL.

Здесь мы сталкиваемся с одной особенностью расширения LuaJIT: FFI (Foreign Function Interface). Давайте рассмотрим детальнее. Положим в таблицу пять значений, используя в качестве ключей различные варианты записи числа 1.

tarantool> t = {}
tarantool> t[1] = 1
tarantool> t["1"] = 2
tarantool> t[1LL] = 3
tarantool> t[1ULL] = 4
tarantool> t[1ULL] = 5
tarantool> t
---
- 1: 1
  1: 5
  1: 4
  '1': 2
  1: 3
...

Можно было бы предположить, что они положатся как 2 (строка + число). Максимум как 3 (строка, число, LL). Но при выводе на экран окажется, что все ключи лежат в таблице раздельно: мы видим все значения 1, 2, 3, 4, 5. Более того, при сериализации мы не видим разницы между обычными, знаковыми и беззнаковыми числами.

tarantool> return t[1], t['1'], t[1LL], t[1ULL]
---
- 1
- 2
- null
- null
...

Но самое веселье наступает, если попытаться достать данные из таблицы. С обычными Lua-типами всё хорошо (number и string), а вот с LL (long long) и ULL (unsigned long long) — нет. Эти типы являются отдельным типом cdata. Он предназначен для работы с типами из языка C. И при сохранении в Lua-таблицу cdata хэшируется по адресу, а не по значению. У двух, пусть и одинаковых по значению, чисел просто два разных адреса. И когда мы складываем ULL в таблицу, то потом не можем по такому же значению достать его из таблицы.

Поэтому нам придется немного переделать нашу очередь и владение ключами. Шаг вынужденный, но он позволяет нам в дальнейшем модифицировать наши ключи произвольным образом. Нам нужно каким-либо образом превратить наш ключ в строку или число. Возьмем MessagePack. В Tarantool он используется для хранения таплов и будет упаковывать наши значения так же, как это делает сам Tarantool. С его помощью мы превратим произвольный ключ в строку, которая будет являться ключом в нашей таблице.

local msgpack = require 'msgpack'

local function keypack( key )
    return msgpack.encode( key )
end

local function keyunpack( data )
    return msgpack.decode( data )
end

Добавляем в take упаковку ключа и сохраняем его в таблице. В функции get_task проверим, что ключ прошел в правильном формате, и если это не так, то превратим его в int64. После этого воспользуемся тем же самым keypack, который упакует ключ в MessagePack. Поскольку этот упакованный ключ будет требоваться всем функциям, которые с ним работают, мы будем возвращать его из get_task, чтобы ack и release могли им пользоваться и вычищать его из сессий.

function queue.take(timeout)
    if not timeout then timeout = 0 end
    local now = fiber.time()
    local found
    while not found do
        found = box.space.queue.index.status
            :pairs({STATUS.READY},{ iterator = 'EQ' }):nth(1)
        if not found then
            local left = (now + timeout) - fiber.time()
            if left <= 0 then return end
            queue._wait:get(left)
        end
    end

    local sid = box.session.id()
    log.info("Register %s by %s", found.id, sid)
    local key = keypack( found.id )
    queue.taken[ key ] = sid
    queue.bysid[ sid ] = queue.bysid[ sid ] or {}
    queue.bysid[ sid ][ key ] = true

    return box.space.queue
        :update( {found.id}, {{'=', F.status, STATUS.TAKEN }})
        :tomap{ names_only = true }
end

local function get_task( id )
    if not id then error("Task id required", 2) end
    id = tonumber64(id)
    local key = keypack(id)
    local t = box.space.queue:get{id}
    if not t then
        error(string.format( "Task {%s} was not found", id ), 2)
    end
    if not queue.taken[key] then
        error(string.format( "Task %s not taken by anybody", id ), 2)
    end
    if queue.taken[key] ~= box.session.id() then
        error(string.format( "Task %s taken by %d. Not you (%d)",
            id, queue.taken[key], box.session.id() ), 2)
    end
    return t, key
end

function queue.ack(id)
    local t, key = get_task(id)
    queue.taken[ key ] = nil
    queue.bysid[ box.session.id() ][ key ] = nil
    return box.space.queue:delete{t.id}:tomap{ names_only = true }
end

function queue.release(id)
    local t, key = get_task(id)
    queue.taken[ key ] = nil
    queue.bysid[ box.session.id() ][ key ] = nil
    if queue._wait:has_readers() then queue._wait:put(true,0) end
    return box.space.queue
        :update({t.id},{{'=', F.status, STATUS.READY }})
        :tomap{ names_only = true }
end

Поскольку у нас есть есть триггер на отключение, мы теперь знаем, что отключилась конкретная сессия, которая владеет какими-то ключами. Можно взять все ключи этой сессии и автоматически вернуть их в исходное состояние — ready. Также, внутри этой сессии могут висеть ожидающие take. Оставим для них маркер в session.storage, что задачи брать не нужно.

box.session.on_disconnect(function()
    log.info( "disconnected %s from %s", box.session.id(), box.session.storage.peer )
    box.session.storage.destroyed = true

    local sid = box.session.id()
    local bysid = queue.bysid[ sid ]
    if bysid then
        while next(bysid) do
            for key, id in pairs(bysid) do
                log.info("Autorelease %s by disconnect", id);
                queue.taken[key] = nil
                bysid[key] = nil
                local t = box.space.queue:get(id)
                if t then
                    if queue._wait:has_readers() then queue._wait:put(true,0) end
                    box.space.queue:update({t.id},{{'=', F.status, STATUS.READY }})
                end
            end
        end
        queue.bysid[ sid ] = nil
    end
end)

function queue.take(timeout)
    if not timeout then timeout = 0 end
    local now = fiber.time()
    local found
    while not found do
        found = box.space.queue.index.status
            :pairs({STATUS.READY},{ iterator = 'EQ' }):nth(1)
        if not found then
            local left = (now + timeout) - fiber.time()
            if left <= 0 then return end
            queue._wait:get(left)
        end
    end

    if box.session.storage.destroyed then return end

    local sid = box.session.id()
    log.info("Register %s by %s", found.id, sid)
    local key = keypack( found.id )
    queue.taken[ key ] = sid
    queue.bysid[ sid ] = queue.bysid[ sid ] or {}
    queue.bysid[ sid ][ key ] = found.id

    return box.space.queue
        :update( {found.id}, {{'=', F.status, STATUS.TAKEN }})
        :tomap{ names_only = true }
end

Для теста можно брать задачи командой:

tarantoolctl connect 127.0.0.1:3301 <<< 'queue.take()'

Пока это всё отлаживалось, можно было столкнуться с тем, что вы взяли задачи, потушили очередь, запустили заново — задачи никому не принадлежат (потому что соединения порвались при выключении), но при этом они в статусе taken. Поэтому добавим в код модификацию статусов при старте: база запускается и освобождает все взятые задачи.

while true do
    local t = box.space.queue.index.status:pairs({STATUS.TAKEN}):nth(1)
    if not t then break end
    box.space.queue:update({ t.id }, {{'=', F.status, STATUS.READY }})
    log.info("Autoreleased %s at start", t.id)
end

Получилась очередь, готовая к эксплуатации.

Добавим отложенную обработку

Осталось добавить отложенные задачи. Для этого добавим новое поле и индекс по нему. В этом поле мы будем хранить время, когда определённую задачу нужно перевести в другое состояние. Модифицируем функцию put и добавим новый статус: W=WAITING.

box.space.queue:format( {
    { name = 'id';     type = 'number' },
    { name = 'status'; type = 'string' },
    { name = 'runat';  type = 'number' },
    { name = 'data';   type = '*'      },
} )

box.space.queue:create_index('runat', {
    parts = { F.runat, 'number', F.id, 'number' };
    if_not_exists = true;
})

STATUS.WAITING = 'W'

Поскольку мы кардинально меняем схему и это режим разработки, очистим предыдущую схему (выполняем в консоли):

box.space.queue.drop()
box.snapshot()

Перезапустим очередь.

В put и release добавим поддержку delay. Если delay передан, то присваиваем задаче состояние WAITING и определяем, в какой момент времени она должна быть обработана. Также нам понадобится обработчик. Для этого мы можем воспользоваться фоновыми файберами. В любой момент можно создать файбер, не ассоциированный ни с каким соединением и который будет работать в фоне. Создадим файбер, который будет крутиться бесконечно и ждать ближайшей задачи.

function queue.put(data, opts)
    local id = gen_id()

    local runat = 0
    local status = STATUS.READY

    if opts and opts.delay then
        runat = clock.realtime() + tonumber(opts.delay)
        status = STATUS.WAITING
    else
        if queue._wait:has_readers() then
            queue._wait:put(true,0)
        end
    end

    return box.space.queue
        :insert{ id, status, runat, data }
        :tomap{ names_only=true }
end

function queue.release(id, opts)
    local t, key = get_task(id)
    queue.taken[ key ] = nil
    queue.bysid[ box.session.id() ][ key ] = nil

    local runat = 0
    local status = STATUS.READY

    if opts and opts.delay then
        runat = clock.realtime() + tonumber(opts.delay)
        status = STATUS.WAITING
    else
        if queue._wait:has_readers() then queue._wait:put(true,0) end
    end

    return box.space.queue
        :update({t.id},{{ '=', F.status, status },{ '=', F.runat, runat }})
        :tomap{ names_only = true }
end

Если приходит время какой-то задачи, мы её модифицируем. Переводим из статуса ожидания в статус готовности, также нотифицируя тех клиентов, которые могут ждать задачу.

Теперь кладём задачу с задержкой. Вызываем take, готовой задачи нет. Вызываем повторно, уже с таймаутом, который укладывается в появление задачи. Как только она появляется, мы видим, что это заслуга файбера queue.runat.

queue._runat = fiber.create(function()
    fiber.name('queue.runat')
    while true do
        local remaining

        local now = clock.realtime()
        for _,t in box.space.queue.index.runat
            :pairs( { 0 }, { iterator = 'GT' })
        do
            if t.runat > now then
                remaining = t.runat - now
                break
            else
                if t.status == STATUS.WAITING then
                    log.info("Runat: W->R %s",t.id)
                    if queue._wait:has_readers() then queue._wait:put(true,0) end
                    box.space.queue:update({ t.id }, {
                        {'=', F.status, STATUS.READY },
                        {'=', F.runat, 0 },
                    })
                else
                    log.error("Runat: bad status %s for %s", t.status, t.id)
                    box.space.queue:update({ t.id },{{ '=', F.runat, 0 }})
                end
            end
        end

        if not remaining or remaining > 1 then remaining = 1 end
        fiber.sleep(remaining)
    end
end)

Мониторинг

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

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

function queue.stats()
    return {
        total   = box.space.queue:len(),
        ready   = box.space.queue.index.status:count({STATUS.READY}),
        waiting = box.space.queue.index.status:count({STATUS.WAITING}),
        taken   = box.space.queue.index.status:count({STATUS.TAKEN}),
    }    
end

tarantool> queue.stats()
---
- ready: 10
  taken: 2
  waiting: 5
  total: 17
...

tarantool> local clock = require 'clock' local s = clock.time() local r = queue.stats() return r, clock.time() - s
---
- ready: 10
  taken: 2
  waiting: 5
  total: 17
- 0.00057339668273926
...

Такой мониторинг будет работать довольно быстро. До того момента, пока задач не станет очень много. Нормальное состояние очереди — пустое. Но предположим, что-то случается и прилетает, например, миллион задач. Наша функция stats продолжает показывать корректное значение. Правда, она начинает работать довольно медленно. Проблема в вызове index:count — это всегда full-scan по индексу. Давайте закэшируем значения счетчиков.

queue._stats = {}
for k,v in pairs(STATUS) do
    queue._stats[v] = 0LL
end

for _,t in box.space.queue:pairs() do
    queue._stats[ t[F.status] ] = (queue._stats[ t[F.status] ] or 0LL)+1
end

function queue.stats()
    return {
        total   = box.space.queue:len(),
        ready   = queue._stats[ STATUS.READY ],
        waiting = queue._stats[ STATUS.WAITING ],
        taken   = queue._stats[ STATUS.TAKEN ],
    }
end

Теперь эта функция начнет работать очень быстро, независимо от количества записей. Осталось обновлять счетчики при любых операциях. При каждой операции мы должны одно значение уменьшить, другое увеличить. Можно, конечно, вручную расставить апдейты по функциям, но это чревато ошибками и расхождениями. К счастью в Tarantool есть триггеры на спейсах. Триггер видит любое изменение в спейсе. Можно даже вручную выполнить space:update или space:delete, триггер это учтет и посчитает. Триггер будет учитывать все статусы именно по значению,

© Habrahabr.ru