Transactional messaging. Какие существуют реализации транзакционных очередей сообщений?

ksimmi, я имел ввиду, что мне не очень понятна несогласованность сервисов на этапе завершения транзакции. Да, можно чтото пускать асинхронно, если это допустимо, но основные сервисы должны быть согласованы в момент завершения транзакции, несогласованы могут быть только второстепенные сервисы. Иначе мы теряем часть данных, или нет? Для меня это звучит, как, мы подтвердили клиенту что отправили деньги, а в это время все еще идет проверка возможно ли это.

Если 1 транзакция будет 5 раз прогонят чтото через polling publisher - это будет гарантировано медленно. Но зачем? У вас же есть (или будет) Kafka/Rabbit/Nats?
По поводу OUTBOX в Transaction log tailing, согласен, это лучшее решение. Но остаются те же вопросы, не смотрели, как данные забирают из журнала? По gtid? Как воркер определит откуда продожать чтение после рестарта? И самое интересное, как это читать многопоточно?
Если OUTBOX неизменен, то как вы определяете, какая строка обработана, а какая еще нет, какие записи можно чистить? Тоже по gtid?

Функции по "Чистому коду" - нужно ли это?

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

Функции по "Чистому коду" - нужно ли это?

sve-kai-itmo, да, перебарщивает. Всегда нужно подходить критически к таким вещам, если непонятно зачем это вообще нужно, то не стоит этому слепо следовать.
Как уже написали, "Совершенный код" гораздо более адекватный, с объяснениями почему и зачем так, лучше взять его.

Нужно ли закрывать соединение, созданное повторно через другую переменную?

Igorek98, если, конечно, в коде на каждый запрос не открывается новое соединение. Соединение, как правило, должно быть одно на все запросы.

Как проверить существование поля в таблице?

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

Как проверить существование поля в таблице?

SHOW COLUMNS - именно такой вариант ты написал как ответ. Хотя, бредово проверять во время работы существование полей в таблице.

Существует таблица test_category, как проверить в ней существование категории, чтобы не пытаться по новой добавить уже существующую?

Далее там делается select с alt_name='test' и вопрос как "Как выполнить проверку, чтобы вновь не добавить категорию test?"
Собственно все здесь отвечали именно на этот, второй вопрос.

Как проверить существование поля в таблице?

Видно, навыки телепатии не сильно помогают, раз автор как решение выбрал:
SHOW COLUMNS
, а все предложенные решения совсем про другое.

Бизнес и продажа фичей важнее качества кодовой базы?

Рональд Макдональд, потрясающий диалог, "вы все неправильно поняли, но хрен вы вытяните из меня, что я имел ввиду на самом деле". Отсюда и ваши "специально обученные мартышки", которые ни за что не отвечают, и "злой бизнес", который во всем виноват.

Недостатки PostgreSQL?

Ерлан Ибраев, а, вы про это, да, каждое поле может иметь свою кодировку - это нормально, и вероятно даже где-то удобно, мне тоже это никогда не было нужно, но кому-то может понадобится.

Бизнес и продажа фичей важнее качества кодовой базы?

Рональд Макдональд,

Ну уж извините, дальше не читал. Я такого не утверждал.

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

Недостатки PostgreSQL?

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

Недостатки PostgreSQL?

Ерлан Ибраев,
1) кодировки - это структурные изменения, а это всегда и везде боль, если мы говорим о нагруженной системе.
2) не понимаю, зачем держать открытым соединение и не использовать его? Наоборот, всегда закрываешь соединение, если оно не исопльзуется, если бережешь ресурсы.
3) Есть такое, некая динамическая типизация. Согласен, польза очень сомнительная, а проблем от нее огребаешь много, пока не привыкнешь всегда о ней помнить.
И это не все проблемы, но проблем хватает и в других СУБД, по-сути всегда приходится мириться с чем-то, ради чего-то. MySQL очень быстрая СУБД, это отличный выбор для нагруженных систем (если говорить о Percona), с оговоркой, что вы используете СУБД как базу данных, если нужно чтобы СУБД варила кофе, это точно не про MySQL.

Бизнес и продажа фичей важнее качества кодовой базы?

Рональд Макдональд, топ-менджмент не решает вопросы рефакторинга. Как вы себе представляете, сидит коммерческий директор и рассуждает о процедурном подходе и ООП в коде? Ну если только в компании из 2 человек. Разработчики (речь про тимлидов и архитекторов), как и любое другое подразделение, должны уметь разговаривать с людьми и доказывать необходимость вещей, которые считают важными. А заявления "это не мы, это нас злой бизнес заставил" - детский сад. Бизнес не проревьют ваш код и не заявит, что все нужно переписать на говнокод, разработчик это делает сам, сознательно.
Менеджмент от бизнеса всем не заправляет, у него своя зона ответственности, у технарей своя. Сроки и доставка функционала - это ответственность и тех, и других. Другое дело, что менеджеры от бизнеса умеют добиваться своих целей, а технари нет и ноют, что их заставили.
В итоге, если разработчики компетентны, то у них нет оправдания "нас заставили". Если они также умеют разговаривать, то и с бизнесом находят общий язык. Другое дело, что компетентность техническая в IT очень низкая в большинстве случаев, тем более, если работадатель нанимает сотрудников за гроши. А не умеют разговаривать еще большее кол-во.

Бизнес и продажа фичей важнее качества кодовой базы?

Akina,

Менеджмент и продажа приносят прибыль.
От разработки - одни убытки.
Задача бизнеса - увеличение прибыли и снижение расходов-убытков.
Поэтому менеджмент в шоколаде, а программисты ... ну ... в общем, не в фаворе.

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

krakaka,

я не управленец, но возможно в менеджменте есть какие-то практики ведения продукта с учетом именно технической стороны?

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

Как не выводить пустое меню?

gian_tiaga, Дмитрий Зорин, если используете empty, нет смысла писать еще и isset, т.к. empty уже включает в себя isset.

Работает ли logrotate без cron?

JuniorAdmin, Vitaly Karasik в своем ответе описал варианты.

Работает ли logrotate без cron?

JuniorAdmin, если вы не хотите использовать cron, то как вы хотите запускать logrotate?

другие статьи в интернете делают logrotate.d/ в этом каталоге и у них якобы все работает

Что конкретно делают? Быть может вы про запуск вручную? Покажите команды.

Работает ли logrotate без cron?

JuniorAdmin, logrotate это не демон, его что-то должно запускать, если не cron, то "добавьте туда, куда посчитаете нужным", т.е. в другой планировщик.
Напишите, что хотите сделать, а не как хотите, тогда быть может станет проще помочь.

Как сравнить строки?

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

Transactional messaging. Какие существуют реализации транзакционных очередей сообщений?

Почему отложенная согласованность? Вернее, где вы ее применяете? Транзакция выполняется последовательно, синхронно, никакой отложенности здесь не должно быть. Если речь про что-то вроде DWH, тогда понятно.
Polling publisher наиболее распространенное решение, по-моему, надежное, и более простое по сравнению Transaction log tailing (быть может потому, что я видел только реализации по 1 сценарию).
Будет ли медленным Polling publisher? Смотря, что для вас медленно, в принципе стандартные потери на СУБД, пересылку по-сети и прочее.
Насчет публикации прямо из СУБД, не думаю, что это хорошее решение, если у вас нагруженная система, СУБД всегда узкое место, не нужно заставлять ее делать что-то еще, кроме того что она и так делает хорошо.
Насчет удаления из outbox, то мне кажется в варианте, когда вы забираете данные из журнала, нет смысла создавать outbox. Забирайте прямо из основной талицы, ориентирусь на какой-либо параметр: id, время обновления. Но нужно смотреть применимость в конкретной ситуации. Не знаю как работать с журналом, но думаю там есть встроенные идентификаторы транзакций, какой-нибудь GTID, и можно ориентироваться на него.

Почему get_object_vars() возвращает только НЕ типизированные свойства?

Сергей Кореневский, вы экономите не там где нужно. Чистота кода здесь и рядом не лежала, наоборот любые неявные вещи ухудшают код. Дефолтные значения используются в подобных случаях не от того что программистам было лень инициировать переменные, а потому что при статическом типе переменной, которая просто указывает на ячейку памяти не получится иначе, другое дело при более сложной системе типов, что собственно в пыхе и сделали.
Заявить, что здесь в бизнес-логике мусор навален, зато в другом месте триумф лени, не пришлось указывать часть значений - это фиаско.