Как сделать чат без БД?

Question

[My1Name]

Как написать чат не используя базу данных? Хотелось бы посмотреть алгоритм с использованием JAVA коллекций или ConcurrentHashMap<?,?> Ссылки на литературу к данному вопросу, тоже будут не лишними.

Comments

[mayton2019]

Непонятно что ты ишешь. Если ты уже реализовывал чяты с БД то тогда написать их без БД будет не сложно.
И между ConcurrentMap и БД есть бесконечное число уровней серого. Есть всякие БД на файлах. LevelDb, BerlkeleyDb,
Tarantool e.t.c. И есть просто сериализация структур в файлы.

Если ты не писал их вообще - то тогда вопрос не об этом и надо спрашивать другое.

[My1Name]

mayton2019,

Непонятно что ты ишешь. Если ты уже реализовывал чяты с БД то тогда написать их без БД будет не сложно.

- Нужно создать хэш сообщений. То есть, если оба пользователя в данный момент времени общаются, то передавать сообщения не читая с БД или с файла, используя js EventSource.

[mayton2019]

My1Name, я читаю некую терминологическую путаницу. Хеш или кеш?

[My1Name]

mayton2019,

Хеш или кеш?

Как вам больше нравится... Думаю вы меня правильно поняли :)

[mayton2019]

My1Name, у тебя цель - академическая? Или практическая? Потому что с практической точки зрения БД удобнее.
Переживает перезагрузку с сохранением данных. А если просто изучаешь - как работает Java и чяты то бери
ConcurrentHashMap или BlockingQueue и пиши туда все что надо. Этих структур достаточно чтобы решить
задачи чята. И не надо искать специальную литературу. Ее скорее всего не будет потому что никто таким
обычно не занимается.

[My1Name]

mayton2019,

с практической точки зрения БД удобнее

с практической точки зрения, у пользователей могут быть уведомления о новых сообщениях. И если они в данный момент общаются друг с другом, то уведомления о новых сообщениях от собеседника - как минимум глупо. Кроме того, история чата пишется в файл/ы, а не в БД.

[mayton2019]

My1Name, да все верно. Но мы зашли куда-то в сторону. Ты раньше делал чяты?

[My1Name]

mayton2019,

Ты раньше делал чяты?

Только в учебных целях, на базе tcp/ip и сокетов.
p.s. учебная программа java программистов server/client

[My1Name]

mayton2019,

мы зашли куда-то в сторону

Так у тебя есть идеи по поводу Кеша? :) Желательно алгоритм на пальцах...

[Dmtm]

ну вот, началось

js EventSource.

а так хорошо начиналось
зачем тут js? ConcurrentHashMap тоже ни к чему - это map а чату нужен порядок следования
лучше выбрать сокеты (для начала можно взять блокирующие) и Flow для очереди и событий

[mayton2019]

My1Name, если тебе надо посылать сообщения точка-точка - то используй BlockingQueue,
как я уже писал. Две сессии.

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

[My1Name]

Dmtm,

зачем тут js?

EventSource - слушатель сервера, реализуемый на уровне HTTP и не требующий сокет соединения. Можно сказать - облегченный вариант server/client

[My1Name]

В общем, используя js EventSource на базе Spring-а можно написать (приватный) чат и, всё в общем-то работает, но у меня с таким вот "костылём":

while (principal!=null && text!=null && text.isEmpty()) {
				Thread.sleep(100);
				text = chatMessenger.get(id);
			}

Я пока что не знаю как устранить это недоразумение, и как оно скажется на производительности - тоже не знаю... Для написания чата, я использовал 3 потокобезопасные карты и воображение :)

**principal нужен на тот случай, если пользователь не вышел и не закрыл чат, а тупо закрыл браузер или у него свет пропал... В таком случае со временем происходит session.invalidate() и обрабатывается Exception.

[Odissey Nemo]

My1Name, ваши слова "... HTTP ... не требующий сокет..." смущают.
Может быть, стоило написать, что "использование HTTP скрывает все операции с сокетами за более высоким интерфейсом работы с HTTP?

[My1Name]

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

[Odissey Nemo]

My1Name, резонно. Но не современно))) Я сам, как бы это сказать... не современный. Начинал в середине 80-х. Тогда был стиль "code bum", когда боролись за каждый байт и за каждый такт.
Сегодня ты пристёгиваешь библиотеку с нужной тебе функцией, а она подтягивает мегабайт 50 своего кода)))
И это оправдано тем, что живём мы только сегодняшним днём. Ибо рыночек
Но ваш подход сегодня... я могу только одобрить! Он правильный и полезный, особенно для саморазвития!

[My1Name]

Odissey Nemo,

правильный и полезный, особенно для саморазвития

Хабр - моя шпаргалка! :) В том смысле, что я в последнее время отвечаю сам на свои вопросы... А ответы и комментарии под другими вопросами, действительно для саморазвития.

резонно. Но не современно))

Ну, это смотря как посмотреть... Я вообще писал чат как "фишку" для "малой соц.сети" (pet-project), а теперь думаю, что нужно делать отдельным проектом. Думаю он соответствует времени:

Сегодня ты пристёгиваешь библиотеку с нужной тебе функцией

и занимаешься тем, что умеешь :)

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

Никогда не разворачивал проекты подобного рода. Это безусловно интересный опыт. Было бы здорово развернуть такой сервис под эгидой Yandex или Google.


Screenshot уже немного не актуальный, но в целом, внешний вид особо не менялся... Проект на трёх языках (ru, en, he) поэтому отображается три кнопки переводчика. Но по факту - одна, в зависимости от языковых настроек пользователя. Бесплатный онлайн-чат для сайта