Как стать автором
Обновить
19
0
Дынников Ярослав @Rosik

Разработчик

Отправить сообщение

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

Как насчёт такого варианта? Шар и парашют закреплены на противоположных концах одной веревки. Оборудование крепится посередине и свободно скользит от шара к парашюту. Шар лопается — парашют перетягивает канат на свою сторону.

Отлаживать неотлаженные скрипты на проде - не лучшая затея.

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

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

- Например, таска из очереди может выполниться с отставанием (возможно никогда), и новые данные данные никто не найдёт.

- Или наоборот, таска отработает как надо, а запрос "add user data by id" - нет. Теперь старые данные никто не сможет найти, а новых не появиось.

- И, наконец, индексный слой может обновиться неконсистентно на разных стораджах (параллельные стрелочки "update search index" на картинке).

Нормальная запись в WAL будет только если указать специальный флаг в конфиге tarantool. Если его указать, то вся производительность на запись улетучится. Напомню, что без O_SYNC запись почти всегда будет в кеш ОС, а не на диск.

Что такое "нормальная запись в WAL" и зачем так нужна запись на диск? Если ваш ответ — чтобы данные не пропали случайно при блекауте, то фсинк тут мало на что влияет — сервер ведь и вместе с диском сгореть может. И тогда мы перейдем к разговору о репликации, желательно синхронной, но это будет уже совсем другая история.

Кажется вы ищите что-то типа web framework. Попробуйте почитать тут или тут, возможно это подойдёт.

Все эти рассуждения о быстроте имеет смысл вести только проведя перф тесты на системе, максимально приближенной к реальным условиям эксплуатации. На мой взгляд проблема undefined behavior куда серьёзнее.


table + 1 как раз указывает на дырку, в которую я могу добавить объект.

Это утверждение не верно. Ни в LuaJIT, ни в PUC-Rio Lua


$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> t = {1, 2, 3, 4}
> t[3] = nil
> print(#t)
4
>

table[index] = nil приводит к образованию дырок в массиве, и #table в этом случае — UB, о чём собственно рассказывает статья. Если у числовых индексов нет какого-то другого прикладного значения, то я бы советовал присмотреться к паттерну t[obj] = true (https://www.lua.org/pil/11.5.html).

Что вы подразумаваете по "сайтом, написанном на луа"?

mikeus дело говорит. Идентичность таблиц проверяется по указателю — это те самые table: 0x4082dfa8 в статье. Иными словами


t1 = {}
t2 = t1
t1 == t2 -- true
t1 == {} -- false

И при поиске ключа поведение будет то же самое.

Userdata в LuaJIT никуда не делась, это часть спецификации языка.
Cdata — явление исключительно LuaJIT. В ванильном Lua его аналогов нет.

А получается, что все три случая дают разный результат.


t1 = { "foo" }
tostring(t1)
-- table: 0x4082db70
--  a[2]: nil, foo
--  h[1]: nil=nil

t2 = { [1] = "foo" }
tostring(t2)
-- table: 0x4082dfa8
--  a[0]: 
--  h[2]: nil=nil, 1=foo

t3 = {};  t3[1] = "foo"
tostring(t3)
-- table: 0x4082e410
--  a[3]: nil, foo, nil
--  h[1]: nil=nil

Не обязательно. В статье речь шла про "нормальную" жизнь кластера. При обновлении могут быть разные случаи, все зависит от характера обновлений. В благоприятной ситуации можно обновить реплики, переключить лидеров и потом обновлять вторую половину

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность