Для конкретного проекта мне нужно реализовать сервер временных файлов:
Я рассматриваю два решения: - экземпляр REDIS (без виртуальной машины, без сохранения) - сервер NGINX с модулем DAV (команда PUT для загрузки)
Но я открыт для других решений ;-)
Если вы можете использовать решение FreeBSD, а не Linux, FreeNAS - это отличный вариант NAS, который легко установить и настроить, а также имеет огромный набор возможностей для подключения и управления доступом. Также есть Linux-версия проекта в процессе, но я не уверен, насколько он полнофункциональный.
Есть также OpenFiler со стороны Linux, но мы обнаружили, что FreeNAS лучше подходит для наших разнообразных нужд (которые, по общему признанию, звучат несколько иначе, чем ваши).
Изменить: Похоже, вам нужно что-то для работы на существующем сервере Linux, а не на собственном оборудовании. Если это необходимо, я бы подумал о запуске одного из этих вариантов в качестве виртуальной машины под KVM или Xen.
Просто запустите NFS на нестандартном порту, сделайте свой диск для этого tmpfs, насколько я понимаю, общий размер невелик? Это должно работать близко к скорости проводной сети (обычно nfs требует синхронной записи, но с tmpfs это не будет проблемой.
tmpfs - это файловая система, которая в основном представляет собой фрагмент вашего файла подкачки / памяти. Таким образом, никакой настойчивости через перезагрузку любого рода, но так же быстро, как запись в память.
ты можешь испытать удачу с memcached или coauchdb. оба являются хранилищами значений ключей, первое - типа «в памяти». можно использовать? я не знаю - это зависит от того, может ли ваш потребитель «угадать» ключ, под которым данные хранились произведенным.
может быть модуль memcached для nginx это именно то, что вам нужно? вместе с ним вы получаете HTTP-интерфейс RESTful для вашей базы данных в памяти.
вы также можете рассмотреть некоторый механизм очереди - начиная от простого FIFO, реализованного вами в MySQL, до таких вещей, как кролик или activemq.
Ваши требования предполагают, что помимо «сервера» вам необходимо предоставить:
1) какое-то клиентское программное обеспечение для размещения файлов на сервере
2) клиентское ПО для скачивания с сервера
3) канал уведомлений между загрузчиком и загрузчиком
4) некоторые умения на сервере для устаревшего контента больше не требуются
Хотя HTTP - очевидный выбор (1 и 2 хорошо описаны, а 3 и 4 потребуют всего нескольких строк кода, легко реализуемых на perl / php / что угодно), это звучит как асинхронная система очередей сообщений. Вы не говорите, насколько важна целостность транзакций, но 2 и 12 предполагают, что это не имеет большого значения. Поэтому я бы предложил использовать электронную почту - уведомление является неявным, оно переживет временные отключения, вы можете легко настроить второй SMTP-сервер в системе, работающей на непривилегированном порту, и большинство из них позволит вам указать интервалы повтора, таймауты и т. Д. добавления кода триггера на принимающей стороне - это тривиально при использовании procmail.
HTH
С.