Cashed true system

[n3k0nation]

Один большой и толстый минус: валится кешед - валится все без возможности восстановления. С какой периодичностью будет в этом "сферическом кешеде" происходить сохранение в базу, чтобы оправдать свое существование и не стать причиной возможной потери данных? 5-10 минут? Стоит заморачиваться? Я думаю нет.

Возьмем к примеру тот же л2 сервер: ну сколько там тех запросов выполняться-то будет, пускай с 5-ю тысячами игроков, в единицу времени? Мизер, на который даже современное железо ухом не поведет. О таких мероприятиях стоит беспокоится, когда вы будете иметь дело с Highload-проектами от 100 тысяч одновременных активных пользователей, где каждая наносекунда важна как воздух - и то всегда есть шанс, что даже "охренеть-какой-энтерпрайзный бекэнд" на@#$тся из-за мелкой невзрачной ошибки, потянув за собой все.

А вы ппишите клиент-серверные приложения специально с падениями? Если уж так говорить, то есть облачные системы виртуалок джавы, через которые можно застраховаться от падений почти на 100%. В крайнем случае к этому, существует еще и зеркалирование с разными маршрутами входов и выходов.
Бест оф зе бест, как говорится.

Если же реально смотреть на проблему, то кешед будет очень даже полезен, хоть и по сети, а не памяти, т.к. когда я последний раз видел джава эмуль л2 с бд там был полный пипец, это было года 2 назад, мне кажется, что с тех пор мало что изменилось Овер9000 запросов на игрока, при каждом изменении данных заливка в бд, куча незакрытых коннектов, которые утекли и т.п. радости.

[Gattsu]

Вы понимаете, что активные сессии у вас с постоянным трафиком, тут считать не надо, возьмем даже ходьбу
персонаж перемещается на 1000 единиц его скорость 5 единиц в секунду и теперь посчитаем сколько запросов Вы совершите.Заточка,подъем предмета с земли, торговля, любое изменение как так а...
А как-же монополия владения подключение с СУБД, с подключением нельзя будет работать пока его не освободят пассивный деадлок , принципы работы СУБД знакомы?


Ну зачем смотреть в стену...

На PTS кэш сервер завязан вокруг npc и l2server, почему?
Ну блин... Вы когда нибудь сталкивались с проблемой "достоверность информации"?
Оперативное обновление счетов и т.п.

Если Вы не можете понять как написать свой кэш, более устойчивый, я Вам помогу

БАЗА <-> КЭШ-сервер < сеть > (КЭШ-клиент <> СЕРВЕР)

Потеря соединения с базой
ФАЙЛ <канал> (КЭШ-клиент <> СЕРВЕР)

В момент восстановления подключения
КЭШ-клиент передает snapshot-ы с файла, и восстанавливается работа в штатном режиме.


Я понимаю, что все могут купить себе bugatti veyron 16.4 super sport,и забыть о быстродействии, но кто-то довольствуется ограниченными ресурсами.

[rage]

Вы понимаете, что активные сессии у вас с постоянным трафиком, тут считать не надо, возьмем даже ходьбу
персонаж перемещается на 1000 единиц его скорость 5 единиц в секунду и теперь посчитаем сколько запросов Вы совершите.

Не одного. Так как координаты персонажа сохраняются раз в n сек, и при выходе/обрыве связи с клиентом.

Заточка,подъем предмета с земли, торговля, любое изменение как так а...
А как-же монополия владения подключение с СУБД, с подключением нельзя будет работать пока его не освободят пассивный деадлок , принципы работы СУБД знакомы?

Мы то знакомы, вы похоже не очень. Про не блокирующиеся таблицы слышали? Про встроенные кеши в бд? Которые вы пытаетесь эмулировать своим кешем

Ну зачем смотреть в стену...

На PTS кэш сервер завязан вокруг npc и l2server, почему?
Ну блин... Вы когда нибудь сталкивались с проблемой "достоверность информации"?
Оперативное обновление счетов и т.п.

Если Вы не можете понять как написать свой кэш, более устойчивый, я Вам помогу

БАЗА <-> КЭШ-сервер < сеть > (КЭШ-клиент <> СЕРВЕР)

Потеря соединения с базой
ФАЙЛ <канал> (КЭШ-клиент <> СЕРВЕР)

В момент восстановления подключения
КЭШ-клиент передает snapshot-ы с файла, и восстанавливается работа в штатном режиме.


Я понимаю, что все могут купить себе bugatti veyron 16.4 super sport,и забыть о быстродействии, но кто-то довольствуется ограниченными ресурсами.

В случае с l2 сервером кеш нафиг не нужен, ANZO правильно подметил, если бы были сотни тысяч коннектов... А так, оптимизация запросов, оптимизация структуры БД и никаких проблем.

[Gattsu]

Может вы про асинхронные запросы говорите или запросы без ответа?
Что-то я не наблюдал данной реализации на серверах(la2). В такой реализации у вас может получится, что-то вроде провал памяти.

Блокировка вообще-то делается по ключам, блокируется отдельная запись на тот или иной запрос.

О каком кэше Вы говорите? Уточните.

Ну если вы сделаете качественный AI то тут можно подумать, о сотнях тысяч...

кэш дает возможность подняться по уровню памяти.

[ANZO]

Если Вы не можете понять как написать свой кэш, более устойчивый, я Вам помогу

БАЗА <-> КЭШ-сервер < сеть > (КЭШ-клиент <> СЕРВЕР)

Потеря соединения с базой
ФАЙЛ <канал> (КЭШ-клиент <> СЕРВЕР)

Во-первых то, о чем Вы ведете речь баянистый баян и не представляет вообще сложности в реализации. Во-вторых исходит из первого моего ответа: зачем усложнять простую подсистему (query-пул) и зачем это вообще надо в текущем сабже (л2 сервак)?

В момент восстановления подключения
КЭШ-клиент передает snapshot-ы с файла, и восстанавливается работа в штатном режиме.

И Вы всерьез считаете что постоянная запись снепшотов состояния на винт быстрее и менее ресурсоемкая отложенной записи в БД? :eek:

Блокировка вообще-то делается по ключам, блокируется отдельная запись на тот или иной запрос.

Тот же MySQL использует по-умолчанию MyISAM, который лочит всю таблицу (так же как и MEMORY с MERGE). Построчная блокировка осуществляется в механизме InnoDB.

Добавлено через 10 минут

А вы ппишите клиент-серверные приложения специально с падениями? Если уж так говорить, то есть облачные системы виртуалок джавы, через которые можно застраховаться от падений почти на 100%. В крайнем случае к этому, существует еще и зеркалирование с разными маршрутами входов и выходов.
Бест оф зе бест, как говорится.

Не существует полностью отказоустойчивого ПО и не может существовать впринципе из-за человеческого фактора.

Если же реально смотреть на проблему, то кешед будет очень даже полезен, хоть и по сети, а не памяти, т.к. когда я последний раз видел джава эмуль л2 с бд там был полный пипец, это было года 2 назад, мне кажется, что с тех пор мало что изменилось Овер9000 запросов на игрока, при каждом изменении данных заливка в бд, куча незакрытых коннектов, которые утекли и т.п. радости.

Так а что мешает то не сохранять сразу в базу при любом тыке персонажа? Да сколько угодно можно все держать чисто в памяти и сохранять итерационно очередями по мере работы сервера.

[G1ta0]

Прочитал тему, думал тут тру система подъема бабла. А тут, пфф... программирование какое-то.

[izen]

Ура, я откопал свой пароль.

Вставлю свои 5 копеек:
Что вы в "кешеде" кешировать собрались? Кеширование - не более чем способ отложить дорогостоящие io, в l2j это и так реализовано.

Добавлено через 3 минуты

...
Кто начинал впиливать на яве/шарпе сие независимое хранилище?!!!
...

Я, Я, Я :redlol:
Пробовал STOW к l2p прикрутить. пользы 0. Самая большая проблема - предсказание, какую запись можно вытеснить с СУБД. В ладве, при разумном потреблении памяти, это сделать невозможно. Дешевле на БД сервер больше рамы подкинуть.

PS: Во многих write-back алгоритмах есть проблемы с конкаренси

[Gattsu]

Во-первых то, о чем Вы ведете речь баянистый баян и не представляет вообще сложности в реализации. Во-вторых исходит из первого моего ответа: зачем усложнять простую подсистему (query-пул) и зачем это вообще надо в текущем сабже (л2 сервак)?

Я думаю Вы не понимаете о чем я говорю. У нас расходятся мнения и мы говорим о разном.

И Вы всерьез считаете что постоянная запись снепшотов состояния на винт быстрее и менее ресурсоемкая отложенной записи в БД?

Не поверите, но файловые каналы быстрее, чем сетевые. Отложенная запись - отложенная.И Вы не поняли, что я имел ввиду.

Тот же MySQL использует по-умолчанию MyISAM, который лочит всю таблицу (так же как и MEMORY с MERGE). Построчная блокировка осуществляется в механизме InnoDB.

Если в контексте одной СУБД говорить, я посмотрю на Вашу производительность, когда Вы всю базу данных в оперативную память "затолкнете" на MySQL, есть по убедительней базы данных PostgreSQL,MSSQL. И опять блокировка - это нюанс на который оперяться не стоит.

Вас должна интересовать сохранность информации. Исключить потери к минимуму, решить проблему достоверности информации.

Вообще составляются математические модели, которая явно показывает пользу и проблемы тех или иных систем.

Добавлено через 3 минуты

Что вы в "кешеде" кешировать собрались?

Весь сервер.

Кеширование - не более чем способ отложить дорогостоящие io, в l2j это и так реализовано.

Я думаю этих оснований предостаточно

[izen]

Я думаю этих оснований предостаточно

Если это УЖЕ сделано, что вы делать собираетесь.

[Gattsu]

Если это УЖЕ сделано, что вы делать собираетесь.

Ну конечно все реализовали Вы