Результаты поиска
Как вы держите две взаимосвязанные, но отдельные системы в синхронизации друг с другом?
Мой нынешний проект развития имеет два аспекта. Во-первых, существует общедоступный веб-сайт, на котором внешние пользователи могут представлять и обновлять информацию для различных целей. Эта информация затем сохраняется на локальном сервере SQL на объекте colo.
Второй аспект - это внутреннее приложение, которое сотрудники используют для управления теми же записями (концептуально)и предоставления обновлений статуса, утверждений и т. д. Это приложение размещается в корпоративном брандмауэре с собственной локальной базой данных сервера SQL.
Эти две сети соединены аппаратным решением VPN, которое является приличным,но явно не самым быстрым в мире.
Эти две базы данных похожи и имеют много общих таблиц, но они не являются 100% одинаковыми. Многие таблицы с обеих сторон очень специфичны для внутреннего или внешнего применения.
Таким образом, возникает вопрос: когда пользователь обновляет свою информацию или представляет запись на общедоступном веб-сайте, Как вы передаете эти данные в базу данных внутреннего приложения, чтобы она могла управляться внутренним персоналом? И наоборот... как ВЫ продвигаете обновления, сделанные сотрудниками, обратно на веб-сайт?
Стоит отметить, что чем больше "real time" таких обновлений происходит, тем лучше. Не то чтобы это было мгновенно, просто достаточно быстро.
До сих пор я думал об использовании следующих типов подходов:
- Двунаправленная репликация
- Веб-сервис взаимодействует с обеих сторон с кодом для синхронизации изменений по мере их внесения (в режиме реального времени).
- Веб-службы взаимодействуют с обеих сторон с кодом для асинхронной синхронизации изменений (с помощью механизма массового обслуживания).
Какой-нибудь совет? Кто-нибудь сталкивался с этой проблемой раньше? Вы придумали решение, которое хорошо сработало для вас?
Опыт работы с Hadoop?
Кто-нибудь из вас пробовал Hadoop? Может ли он использоваться без распределенной файловой системы, которая идет с ним, в архитектуре общего доступа? Есть ли в этом смысл?
Я также заинтересован в любых результатах работы, которые у вас есть...
Проект Darkstar Реалистичен?
Проект Darkstar был темой ежемесячной встречи JavaSIG в офисах Google в NYC прошлой ночью. Для тех, кто не знает (вероятно, все), Project Darkstar-это платформа для многопользовательских онлайн-игр, которая пытается позаботиться обо всех "hard stuff." основная идея заключается в том, что вы пишете логику своего игрового сервера таким образом, что все операции разбиваются на крошечные задачи. Вы передаете эти задачи в Project Darkstar framework, который обрабатывает их распределение на определенный узел в кластере, любые проблемы параллелизма и, наконец, сохранение данных.
По-видимому, делать такие вещи-это совсем другая проблема для видеоигр, чем для корпоративных приложений. Джим Уолдо, который читал лекцию, утверждает, что MMO игры имеют отношение DB чтения/записи 50/50,, тогда как корпоративные приложения больше похожи на 90% чтения, 10% записи. Он также утверждает, что большинство существующих MMOs хранят все в памяти exlcusively, и только сбрасывают в DB каждые 6 часов so. Это означает, что если сервер выходит из строя, вы потеряете всю работу с момента последнего дампа DB.
Теперь, сам проект звучит действительно круто,но я не думаю, что индустрия примет его. Во-первых, вы должны написать свой код сервера в Java. Клиентский код может быть написан на чем угодно (Джим утверждает, что ActionScript 3 является самым популярным, а затем C++), но серверный материал должен быть Java. Звучит хорошо для меня, но у меня действительно создается впечатление, что все в игровой индустрии ненавидят Java.
Во-вторых, в отличие от других отраслей, где разработчики предпочитают использовать существующие фреймворки и библиотеки, ребята в игровой индустрии, похоже, любят писать все сами. Мало того, они любят переписывать все для каждой новой игры, которую они производят. Все начинает меняться, когда разработчики используют Havok для физики, Unreal Engine 3 в качестве своей платформы и т. д. но по большей части это выглядит так, как будто все еще является собственностью.
Итак, ребята из проекта Darkstar просто теряют свое время? Может ли общая структура, подобная этой, действительно работать для сложных игр с требуемой производительностью? Даже если это действительно работает, готовы ли игровые компании использовать его?
Что было бы хорошо, windows и iis (http) на основе распределенной системы управления версиями
На моей работе мы делаем & продаем сайты. Обычно мы устанавливаем наши .NET C# базирует сайт на сервере заказчика и поддерживает его удаленно. Тем не менее, каждый раз в то время, для большего развития работает и просто сделать вещи проще (и быстрее!), мы скопируем сайт на локальный сервер.
Это здорово, но есть одна боль - перемещение сайта обратно к клиенту. Теперь, если ничего не было изменено на копии клиента-нет проблем. Тем не менее, это печальная правда, что когда-то (читайте чаще, чем хотелось бы) некоторые исправления были необходимы для применения на рабочем сервере. Либо потому, что клиент нуждался в нем NOW, либо просто потому, что это была серьезная ошибка.
Я знаю, что вы можете легко применить эти исправления ошибок к локальной копии, но это процесс, подверженный ошибкам. Поэтому я возлагаю свои надежды на распределенный контроль версий, чтобы помочь синхронизировать две копии.
Вот что мне нужно:
- Простота установки-больше ничего не нужно, кроме установщика и прав администратора.
- Может быть интегрирован в существующий веб-сайт в качестве виртуального каталога и работает на порту 80 - нет хлопот с новым DNS требуется.
- Отличное программное обеспечение
Вот и все. Есть идеи?
Некоторые комментарии к ответам
Во-первых, спасибо! очень признателен.
Я посмотрел на Mercurial и базар, и оба выглядят очень хорошо. Единственным нюансом является установка в качестве виртуального каталога на IIS. Mercurial, насколько я понимаю, используют специальный протокол (wire) и Базар нуждается и в добавлении расширений python. Есть ли другая система, которую легче интегрировать с IIS? Я готов принять удар производительности для этого.