#php #mysql #query-optimization #messaging
#php #mysql #оптимизация запросов #обмен сообщениями
Вопрос:
Я рвал на себе волосы, пытаясь выяснить, как закодировать систему обмена сообщениями, способную к следующему:
- Несколько получателей, где получатели не могут видеть других получателей, а только отправителя. В отправленных сообщениях отправитель видит сообщения, отправленные нескольким получателям в одном потоке, а не в миллиарде отдельных потоков.
- Относительно легкие запросы (у нас около 20 000 пользователей — около 10% из которых регулярно отправляют сообщения 200-300 людям одновременно).
Наша текущая система невероятно неэффективна, и запросы убивают наши серверы чрезмерными объединениями. Я ищу концептуальный совет по созданию масштабируемой многопоточной системы обмена сообщениями на PHP и MySQL — какая структура базы данных лучше, как хранить получателей, лучшие практики для запросов. Кто-нибудь может помочь?!
Спасибо!
Комментарии:
1. Я говорю, что спиральные желоба или воздушные трубки сильно недооценены. 😀
2. Зачем вы вообще создаете свою собственную очередь сообщений? blog.fedecarg.com/2008/11/03 /…
3. вы говорите не о системе очередей сообщений system, не так ли? Я интерпретирую требование как создание системы для поддержки отправки сообщений от одного пользователя, возможно, нескольким пользователям, включая возможность поддержки многопоточных сообщений, где сообщения являются ответом на другие сообщения. По сути, он создает больше систему электронной почты, чем традиционную очередь сообщений, или, по крайней мере, такова была моя интерпретация…
Ответ №1:
Это звучит как задание для настоящей системы очередей сообщений, такой как RabbitMQ или любого количества других очередей сообщений, которые существуют. Существуют большие и сложные проблемы, которые необходимо полностью понять и обработать при попытке написать свой собственный код, и эти проблемы не являются тривиальными. Как минимум, стоит потрудиться над одним или двумя, чтобы ощутить всю мощь и предлагаемые возможности.
Как только вы пройдете по маршруту очереди сообщений, вам захочется изучить концепцию, известную как публикация / подписка, которая позволит отделить каждого подписчика (или получателя) друг от друга. Следуя этому, таблица базы данных (или даже полностью отдельная база данных) может быть создана для каждого подписчика, если это необходимо.
Комментарии:
1. Я не думаю, что он собирается использовать чистый fifo или подобную систему для организации очередей, поэтому традиционный MQ был бы неуместен, если это так. Я надеюсь, что @walker сможет прояснить это.
2. Не сразу было ясно, хочет ли он еще чего-то вроде внутренних сообщений электронной почты или чего-то другого.
3. Я согласен. Надеюсь, @walker прояснит свой вопрос, если это то, чего он хочет.
Ответ №2:
Похоже, что местом для начала было бы просто три таблицы: таблица получателей, таблица сообщений и таблица сопоставления message_recipient многие ко многим. Что-то вроде этого:
получатель
- recipient_id
- Имя
- Адрес электронной почты
Сообщение
- message_id
- message_text
message_recipient
- message_id
- recipient_id
Обязательно создайте индекс для обоих полей таблицы message_recipient, и тогда он станет координационным центром для всех запросов к сообщениям.
Вы пробовали что-нибудь подобное этому подходу? Это самый простой и понятный. Если это не сработает, вероятно, это можно настроить.