Лента тем форума «Infonesy — распределённая социальная система и прочее, связанное с p2p.» и его подфорумов за год

 

Balancer

администратор
★★★★★

В Татарстане запускают первую российскую криптовалюту, которая обеспечена мясом племенных бычков. Новая криптовалюта получила название «ИТкоин»

в России всегда валютой было 0,5 литра водки. Вот к поллитру и надо привязываться, это по нашему! Назвать можно pollitracoin.

водкой и так можно пользоватся для обмена и можно ее майнить самому на несложном оборудовании

// Блокчейн в России...

 

tarasv

опытный

Сообщение было перенесено из темы Про облака....
Balancer> Считай криптовалюты аналогом, ну, скажем, золота. Бумажки ты можешь нарисовать в любом количестве. Но золота не можешь создать сколько угодно, оно лимтировано. Также лимитированы и криптовалюты.
Разве что законодательно будет запрещено создавать новые криптовалюты, количество которых в принципе ничем кроме спроса не ограничено. Так что они не аналог золота, а аналог бумажных денег с привязанным к ним полезным сервисами отсутсвующими у традиционной денежно-банковской системы - защищенными контрактами в Etherium или анонимностью в биткоинах и т.д. Ценность их определяется полезностью сервиса и способностью разработчиков криптовалюты убедить достаточное количество пользователей в полезности именно их реализации.
 

Balancer

администратор
★★★★★
И в рамках Infonesy в целом, и в рамках реплицирования форумов нужно думать о механизме удалённой поисковой индексации.
Пока думаю сделать таким образом. Дёргать чужие сервера по HTTP не лучшая идея в рамках постоянства доступности ресурсов и т.п. Но на помощь может прийти уже активно практикующийся обмен по btsync и/или IPFS. Скажем, при полной индексации сбрасывается дамп БД в унифицированном формате (целиком, или разбитый на файлы по годам/месяцам) в нашу систему обмена. Нода с поисковиком обнаруживает обновление, индексирует его тем же Sphinx с запоминанием ноды и категории. Voilà!
Также и с обновлениями. При чём обновления поисковая нода может брать прямо в обычном Infonesy-потоке.
Скорее всего воспользуюсь Sphinx с XMLPIPE. Основной индекс статический + rt для оперативных обновлений.
 

Balancer

администратор
★★★★★
Не то, чтобы это P2P. И даже не Infonesy. Но всё равно где-то в этот форум...
Для повышения отказоустойчивости и сохранности данных как форумов Авиабазы, так и прочих проектов (включая, кстати, и АвиаПорт) в очередной раз прихожу к мысли, что нужно иметь вторичные резервные полностью рабочие копии сайтов. Речь не о бэкапах, а именно о полной системе, готовой к работе в любой момент.
Раньше я думал много о полной копии (например, rsync для полностью автономного LXC-контейнера), но с этим вариантом всё так и не срослось. Он плохо работает, когда объём БД измеряется десятками гигабайт, а объём файлов — сотнями.
Сложно также поддерживать живую консистентность БД. Да, в том же MySQL отлично работает master-master репликация баз и я даже этим активно пользовался, но... Как только начинаются проблемы с репликацией, потом замучаешься это всё восстанавливать. Время от времени дело доходит до очередного mysqdump/mysql, что выливается, порой, в часы восстановления... Печально. Ещё хуже дело обстоит с разнородными БД на одном сервере.
Проще с файлами. Их можно гонять с машины на машину по rsync. Можно синхронизировать изменения через lsync или btsync/syncthing. Есть небольшие задержки, но чаще это не критично. Проблема тут в том, что p2p-синхронизация тяжело работает на сотнях гигабайт. А централизованная требует каждый раз ручного конфигурирования и жёстко привязывается к структуре проектов.
Интересно тут попробовать IPFS, но руки пока не дошли до массовой практики. Хотя у IPFS есть серьёзный недостаток — невозможность работать с её файлами локально. Они хранятся в собственном формате. В качестве же бонуса — прозрачная работа при смене реплики или при удалённом добавлении файла на другом сервере. Локально он будет гарантированно доступен при обращении, хотя и с задержкой.
С базами же данных я до конца вопрос не решил. Хочу попробовать идею, реализованную в Infonesy. При появлении новых данных или обновлении старых на одном сервере, он сбрасывает JSON-объект в файл в каталог синхронизации. Реплицирующие машины забирают файл и загружают в свои БД. Автоматически решается вопрос структуры сети, так как работа идёт через честный p2p. Проблема конфликта идентификаторов (которой нет в Infonesy — там другой принцип) не возникает при использовании mysql autoincrement offset, как при master-master. Практику тормозит мелочь — надо дорабатывать свои сайтовые движки. Но тут относительно просто — BORS© имеет централизованную точку сохранения объектов, туда и можно встраиваться.
Т.е. система вырисовывается такая. Например, при появлении ответа на форуме, файлы/аттачи сразу кидаются в IPFS. Объекты постинга, обновлённого топика, форума и всего, что обновилось, кидаются в виде JSON в btsync. На удалённом сервере демон, следящий за btsync-каталогом видит прибытие JSON. Считывает данные и грузит их в БД. Файлы, на которые может ссылаться запись, уже сразу доступны в IPFS. Тонкое место тут только в ссылочной целостности базы. Скажем, в случае нового топика постинг может прийти раньше топика. И тогда в БД не получится topic_id сделать внешним ключём для поста... Придётся не пользоваться ссылочной целостностью :-/
Ну и ещё один момент — развёртывание проектов. Недавно переносил АвиаТоп (для разгрузки, а то он процентов 15 нагрузки давал :D) с сервера Авиабазы на отдельный сервер в DigitalOcean. Теперь думаю переносить на другой сервер, у Scaleway. Постое копирование — это лишняя работа. А я очень ленив :) Поэтому уже при недавнем переносе я постарался максимально пакетизировать проект. Чтобы можно было развернуть по простому composer require .... Но БД пока переносится ещё вручную. Надо и этот вопрос тоже решить. Миграции и утягивание данных по запросу через p2p-репликацию. Вот это было бы отлично. Но это ещё предстоит делать :)
 

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru