Дорогие разработчики, при разработке более или менее крупных проектов, у многих скорее всего возникала потребность в передаче данных между скриптами, у меня есть свое решение с разделяемой памятью и тут есть свои недостатки, но хотелось бы узнать, какими методами и почему пользуетесь вы?
Все очень просто - используй не свое, а готовое, существующее, проверенное решение с разделяемой памятью, и не будет проблем и недостатков.
Передача информации между скриптами. Хочу услышать ваши предложения по этому поводу, какие готовые решения могли бы предложить вы и почему?
Предлагаю: memcache, XCache. Причины: они работают и используются на крупных проектах, и уже пережили все детские болезни.
Это типа "какие ботинки вы носите". Не, есть те, кто зимой и летом одним цветом, но все же обычно по погоде. В чем недостаток шареной памяти для вас?
а можно поинтересоваться как это работает (мне это не нужно на данный момент, по этому рыть документацию как то совсем не хочется, не рационально, но просто интересно) как я понимаю это расширение для РНР, оно держит скрипты в ОП, а оно держит их в какой виде уже в интерпретируемом? ну т.е. бери и выполняй, проверять уже ни чего не надо. Надеюсь понимание о чем я.
Нет, не то. То, что ты описал - это аккселераторы. Меморишардеры это другое. Это когда ты можешь записать в оперативку любое значение а, потом, прочитать его. З.Ы. Да, xCache - это еще и аккселератор, может он тебя смутил. Но я привел его в пример из-за его меморишардовой функциональности, а не из-за этого.
Есть данные которые одни для всех, а есть те которые разные и для каждого, так вот отличать кому и какие данные принадлежат становится затруднительно при потоке пользователей, но основное преимущество это скорость работы.
Разработайте нормальную номенклатуру для ключей, и проблем не будет никаких. Решение ваших архитектурных проблем не входит в список задач инструмента.
Можно еще Redis использовать, но опять же, задача абстрактная. Есть же базы данных в оперативной памяти для ACID (Atomicity, Consistency, Isolation, Durability) и други разные комбинации. Очереди сообщений AMQP (Advanced Message Queuing Protocol), rabbitmq и т.д. Ну и как выше уже было сказано просто In-memory key-value store, тот же memcached.
А еще можно использовать БД или файлики Если цель - просто обеспечить шардинг данных между процессами, то и так сойдет. Вообще, классика жанра это: Скрипт<->RAM-кэш любого сорта<->БД; Добавлено спустя 54 секунды: Ох, вангую, что у него стадо сферических коней в стойло не заходит.
Спасибо за предложения! А как обстоять если чрезвычайно важна скорость получения и записи данных? Да, над номенклатурой я поработаю, а про коней верно подмечено!)
Видишь цепочку? В ней три узла. Промежуточный узел как таковой не нужен, он включается в нее именно тогда, когда становится чрезвычайно важна скорость. Потому как, если не важна, хватает связки скрипт<->БД. Скрипту нужны данные, как можно быстрее, он стучится в RAM-хранилище, если там нет, он стучится в БД, получает данные, после чего записывает их в RAM-хранилище. Если данные в RAM-хранилище уже есть, берет их оттуда.
Спасибо за схему, я сейчас немного не об этом, если например данные требуется в определенный момент передавать только между скриптами или другими процессами, без применения баз данных, то какие варианты тут, если крайне важна скорость? Получается по скорости на первом месте стоит разделяемая память
Если внимательно и вдумчиво перечитаешь то, что я написал выше, увидишь, что твой вопрос - частный случай того, что я описал. Всего лишь частный случай. Да, быстрее шардинга оперативки ты ничего не найдешь.