rPman

Если у вас один бакэнд на сервере для обоих доменов, вы можете сами начать управлять куками (т.е. не запускать сессию а рулить заголовками Set-Cookie: сами, тогда сервер, в зависимости от того, какое доменное имя обрабатывается, будет выдавать те куки, которые вам надо.

Проверьте что у вас действительно google chrome а не левые с рекламой, проверьте работу без плагинов, возможно какой то из них косячит

sun/oracle, adobe и позднее microsoft уже попытались втиснуть соответственно java applet, shockwave flash и silverlight, во что это вылилось посмотрите, до сих пор страдаем от остатков тормозного и гглавное дырявого флеша

Позднее, кажется в google, предложили способ компиляции в нативный код NaCl и PNaCl (кажется на базе llvm) но все заглохло

Сейчас весь мир смотрит на webassembly на базе ускоренного javascript. Взлетит - будем писать на любом языке програмирования, который будем компилировать еще на этапе разворачивания приложения, а исполняться оно будет уже в браузере,... все равно это будет виртуальная машина, правда технологии сейчас на столько крутые, что даже виртуальная машина работает на скорости сравнимой с нативным кодом (10%-30% потерь) и львиные потери производительности обычно не из-за кода а из-за кучи прослоек до периферии. Один HTML DOM чего стоит.

Оба направления верные,.. смешно.

Первое, если ваш проект большой или будет большим, чтобы с ним работало несколько человек, плюс это следование главному принципу - разделяй и властвуй, то максимально разделяйте бакэнд и фронтэнд, через определенную и стандартизированную api прослойку. Весь смысл - сделать разработку этих частей проекта максимально независимыми. Вас не должно волновать, на каком языке сделан бакэнд, какой фреймворк или стандарт использован, где лежат файлы и как они называются и т.п., главное - следование стандарту api их взаимодействия. Т.е. размещайте файлы в отдельных каталогах.
Главный недостаток - удобно такое делать, когда проект уже готов и в нем появляются только редкие допиливания, т.е. стандарт api уже завершен и серьезно (в структурном плане а не конечные его функциональные листья) изменяться уже не будет.
Главное достоинство - вы можете переписывать свой проект (например как один из способов избавиться от технического долга) независимо, т.е отдельно бакэнд, отдельно фронтэнд и в идеале отдельно верстка.

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

Нестабильный интернет бывает разным, но в общем случае решается прослойкой между клиентами и базой данных (обычное дело, да и ради повышения безопасности, в мир базу данных не открывают), время сейчас такое что наилучшее решение - http/https. В этом случае база данных может быть абсолютно любой, хоть текстовый лог хоть oracle.

При этом, если используется прослойка, вы можете организовывать репликацию и синхранизацию с несколькими вашими серверами самостоятельно, иногда это даже удобнее и проще чем городить штатную репликацию баз данных, особенно если интернет нестабильный. Т.е. при получении данных от устройств вы отправляете два/много запросов на ваши сервера (асинхронно само собой) и ждете отведенный таймаут (по которому отключаете сбойный сервер из списка и выдаете алерт) после чего отвечаете ок. При возврате в строй сервера, на него заливаются данные с рабочих (лог или поле со временем, если данные не удаляются).

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

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

FAQ там пишет что можно отправить запрос на загрузку item (страницы, файлы, и прочее) заполнив форму или же воспользовавшись batch-утилитой https://github.com/jjjake/internetarchive

не уверен как это работает, но если у вас получится, отпишитесь пожалуйста

Я так понимаю вы хотите защитить свои пароли от просмотра их администратором хостинга?
В общем случае никак!

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

Например самое простое, передавайте все необходимые пароли при запуске бота через пайп, бот должен при старте тупо ждать, когда ему через пайп отправят пароль и только после этого работать, можно реализовать аларм если пароль долго не поступает (например выслать вам смс), ваш же локальный надежный сервер может тупо по ssh подключаться к серверу и отправлять пароль через stdin:
echo пароль | ssh ... cat > пайп.
Единственный способ админу хостинга вытащить этот пароль - это копаться в дампах памяти сервера или очень хитро модифицировать код используемых интерпретаторов, ssh или ядра linux (а это вы можете сами проконтролировать, установив свои версии всего используемого окружения вплоть до полноценной виртуалки, запуская ее каскадно). В общем стоимость атаки взлетает на порядки.

p.s. код вашего бота так же можно не хранить на сервере а передавать через пайпы

Добавьте в таблицу баннеров пользователям поле - время показа, при показе обновлять это поле на текущее время.

Запрос на случайный баннер - условие фильтрации дата показа меньше начала сегодняшнего дня.

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

Это серьезно? Обязательно с android?

Это веб-сайт, пишите примитивное приложение на базе web компоненты, инжектируете на страницу свой javascript код и кликаете куда хотите им.

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

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

Во вторых, разделяйте оперативную и архивную информацию, для чатов это окно сообщений, видимое пользователям по умолчанию при открытии чата (не все же вы загружаете, всегда это происходит порциями), но не делайте правило переноса между этими группами как аксиому, пусть это будет некий системный процесс, который на основе нагрузки и статистики перемещает данные. Если ограничить пользователей по редактированию и удалению старых сообщений, то возможно использовать разные подходы по хранению оперативной и архивной информации, разные технологии индексации или даже самого хранения, в т.ч. оптимизации по буферизации... грубо говоря хранить readonly архивные данные можно где угодно, ведь для доступа к ним не требуется синхронизация и блокировки.

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

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

p.s. массовые рассылки от проекта или партнеров (не кривитесь, все это хотят делать) не делайте обычными чатами, а то будут получаться странные выверты с мегадублированием информации и огромной нагрузкой в момент их проведения, пусть это будет отдельная сущность (остальное разрулите в интерфейсе). С другой стороны, если вам нужна обратная связь, в тот момент, когда пользователь вдруг решает ответить в такой недочат - конвертировать его в обычный.

ключевые слова:
javascript
ajax
websocket

p.s. ладно вы и сами это поняли. Вы должны формировать страницу не на серверной стороне в php, а на клиентской, в javascript на onload (фреймворков шаблонизаторов пруд пруди, но никто не мешает вам делать все самим), и опрашивая либо по таймеру сервер (плохая практика) либо используя вебсокеты, ожидать от сервера данных.

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

По факту, другого способа добыть ссылки на контент сайта у вас нет.

https://geektimes.ru/post/267546/

Заведите на сервере понятие update log (машиночитаемый), в который помещайте все события изменения базы данных, это может быть таблица

id (каждое изменение - увеличивается на 1), имя таблица, id в таблице, имя поля, тип (новый, изменен, удален), новое значение, старое значение (опционально)

и заполняйте ее тригерами автоматически

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

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

Настоятельно рекомендую ВСЕ операции с кошельком, которые должны быть неделимыми (атомарные) реализовать в виде сторонних методов и работать только с ними, самый простой пример - хранимые процедуры в базе данных.

В этом случае у вас в принципе не будут возникать глюки с итоговым балансом (который должен быть нулевым в идеале, а сторонние поступления заводить через специальные аккаунты с отрицательным депозитом, либо вводить понятие кредита, т.е. два баланса - баланс по депозиту и размер кредита и оба числа только положительные).

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