Вакансия требует любви, так что девушка волне вероятна. Кто же не мечтает о большой светлой любви?

Арина развейте сомнения всего чата!

Мб это спамбот?)

Мб это спамбот?)

Чего сразу спамбот? Может красивая и молодая программистка на го?

Чего сразу спамбот? Может красивая и молодая программистка на го?

ты сам то в это веришь?

ты сам то в это веришь?

надеюсь

надеюсь

одной надежды мало

одной надежды мало

Ну так потому и попинговал.

Ну так потому и попинговал.

Ну ты это, если что возвращайся)

https://github.com/golang/go/issues/20126

https://www.thepolyglotdeveloper.com/2017/04/using-sqlite-database-golang-application/

Ну ты это, если что возвращайся)

Откудова?

Откудова?

Оттудова куда ты попинговал пару секунд назад)

ты сам то в это веришь?

Я такую видел на записи women techmakers meetup

Вечер добрый. Запилил модуль, реализующий mutex по сети. Что-то вроде мемкешеда, но с командами Lock(key) и Unlock(key). Требуется критика: https://godoc.org/github.com/MichaelMonashev/sync/netmutex . Заранее благодарен.

воу, но зачем?

типо, свой зукипер? https://zookeeper.apache.org/doc/r3.3.6/recipes.html

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

Вечер добрый. Запилил модуль, реализующий mutex по сети. Что-то вроде мемкешеда, но с командами Lock(key) и Unlock(key). Требуется критика: https://godoc.org/github.com/MichaelMonashev/sync/netmutex . Заранее благодарен.

Лучше убрать русский язык из документации, имхо

есть несколько серверов, которые позволяют делать локи по сети. Можно ещё оборачивать критическую секцию в транзакцию БД. Но я не знаю ниодного, который бы гарантировал, что критическая секция будет выполнена монопольно. Обычно дальше установки ttl на лок не идут. А это не правильно, ибо после того , как лок проэкспарится, по-хорошему, клиента, поставившего его, надо гарантированно кильнуть.

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

а кстати, кто-то работал с Зукипером под нагрузкой? Какую нагрузку он выдерживает?

Вечер добрый. Запилил модуль, реализующий mutex по сети. Что-то вроде мемкешеда, но с командами Lock(key) и Unlock(key). Требуется критика: https://godoc.org/github.com/MichaelMonashev/sync/netmutex . Заранее благодарен.

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

Точнее, зачем нужная taooka, а не библиотека к ней, конечно

Очень уж узкоспециализированная балалайка

А у меня на сайте описаны несколько примеров, где она имеет смысл.

Самый простой - это выборка элементов из очереди. а сама очередьв обычной табличке в БД. Задача выбрать элемент только один раз.

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

табличка в любимом mysql или PG. ничего дополнительно городить не нужно.

тот же краулер вебсайтов с очередью из урлов так быстро пишется

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

фактически все SQL базы данных спрятали внутри себя проблему с консистентностью. Но когда появились NoSQL базы и одной SQL-БД перестало хватать, то проблема согласованности данных в разных хранилищах стала ИМХО снова актуальной.

Вечер добрый. Запилил модуль, реализующий mutex по сети. Что-то вроде мемкешеда, но с командами Lock(key) и Unlock(key). Требуется критика: https://godoc.org/github.com/MichaelMonashev/sync/netmutex . Заранее благодарен.

Нужная либа, буду смотреть подробно, спасибо

Вам спасибо на добром слове.

Делал подобный сервис. Клиенты цепляются по вебсокетам (WAMP). Локи ставятся с первой попытки :) Если клиент, взявший мутекс "отваливается", мутекс освобождается.

Задача была в распределенной системе, работающей с БД. Т.к. СУБД была Монга, то никаких транзакций там, конечно, нет...

Чтобы понять, нужны ли локи, достаточно ответить на простой вопрос: а что будет, если тоже самое, что делает мой код, будет ещё кто-то делать. В вебе рассогласованность часто простительная. Если в БД одни данные, а в мемкешеде некоторое время ещё старые, то обычно ничего страшного в этом нет. Юзер переживёт или не заметит. Но когда сам работаешь с данными, то начинаются race conditions . По Go это многим знакомо...

Я знаю, что описанную мной в самом начале задачу с распределённой ФС решают на Касандре, храня там метаданные.

На Хайлоаде был доклад про это пару лет назад.

Для чего указывать число попыток лока?

Если мутекс залочен, то сразу отлуп будет?

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

то есть я вполне могу представить себе такую логику где-нибудь

Ну... может просто таймаут на операцию лока ставить? Дедлок фри, вроде бы, а на самом деле немного не честно получается.

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

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

если мьютекс залочен, то в err придёт об этом ошибка. Если нужно повторить попытку, то это реализуется на клиенткой стороне. Ранее было на стороне сервера, но я пока решил отказаться от этого, ибо сильно усложняется общение между клиентом и сервером. А хочется "Do less? enable more" 😊

Так лок-серверов несколько?

т.е. да, отлуп сразу будет, если коротко. 😊

пока один. а потом сделаю, чтобы было несколько.

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

Я примерил на себя, для своего проекта, такое поведение мне бы не подошло :)

Возможно, для кого-то именно так нужно будет.

дедло фри, да, чреват тем, что надо обрабатывать ситуации, когда не смог лок поставить. Есть мысль прикрутить LockEach(keys), но надо крепко об этом подумать, ибо сие делает невозможным шардинг по ключу. А шардинг по ключу возможно важнее.

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

На самом деле в Go если Issue, где просят сделать TryLock. Он элементарно пишется. В существующем коде Lock() в самоим первом if-е делается return. Т.е. кому-то трай-локи нужны...

убрать дедлок и сделать поведение как Го очень просто: в цикле лочить, пока не залочится.

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

Текущий API либы наверное шестой или пятый. 😊 Изначально хотелось всё сделать максимально простым , где всё само делается внутри, а программист не заморачивается деталями. В итоге оказалось, что правильне было бы написать низкоуровневую либу с максимумом настроек для гибкости , которая по минимому занималась аллокаций памяти и т.п.. А уже поверх неё городить простые и либы.

Зато получается принимать и отправлять 200 000 запросов в секунду. И есть задел для улучшения этой цифры.

Только сейчас до меня долшло, про какое такое вещание Мерль написал. 😊

http://golangshow.com/online/

Друзья , такой вопрос, как лучше защищаться от sql injection??

Использовать prepare statement

А не хардкодить (форматить) параметры в sql-запрос

Использовать prepare statement

Что то наподобие stmt, err := tx.Prepare("INSERT INTO foo VALUES (?)") ?

Угу, тогда параметры безопасно встанут в запрос

Привет я новичок в го хочется поработать в проэкте может кто пригласит?

на гитхабе куча проектов

Да там куча но я не нашел русскоязычную команду.

Они могут притворяться

Друзья , у вас приложение в продакшине крутится на localhost:9090 или туда название домена прописываете?

сокет открывается на интерфейсе, не на домене

Ребят а подскажите какую то экзампловую реализацию restapi к мускулю

Ребят а подскажите какую то экзампловую реализацию restapi к мускулю

https://github.com/motyar/restgomysql Оно?

Immutable vs Mutable Programming Performance in Golang | My Memory Sucks https://mymemorysucks.wordpress.com/2017/04/27/immutable-vs-mutable-programming-performance-in-golang/

https://github.com/motyar/restgomysql Оно?

Не совсем. Интересует авторизация и стратегия как делать больше чем 1 put Просто посмотреть бестпрактис Сложные роуты и все такое

Привет! Можно сюда вакансии скидывать??

Привет! Можно сюда вакансии скидывать??

нужно

только город укажите и вилку