И как итог, ты получишь тоже самое, только не как 2 сервиса, а как 1. Еще и потеряешь в архитектурном решении в виде того, что бд с кешедом можно держать отдельно от гейм сервера, тем самым снижая нагрузкув теории cached можно вообще выкинуть, а работу с БД перенести в l2server.правда придется свой пул потоков для этого дела городить + кучу функций переписывать(но там функции небольшие и однотипные).
А потом у тебя зависает поток \ дедлок \ вырубается электричество, и предметы игроков улетучиваются вникуда. Да и ради чего это? На современных nvme дисках и ddr5 памятью как будто проблем с бд особо и нету. mssql на диске только журналирует операцию, но не выгружает ее сразу же на диск, а хранит в памяти какое-то время. Ну и кешед сам по себе хранит данные в оперативке, что позволяет ему работать с уже известными данными очень и очень быстроесли сделать все правильно (например инвентарь сохранять только тогда когда перс выходит из игры /или с фиксированным интервалом), то нагрузка на БД даже снизится, ибо кешед прилично долбит базу постоянно сохраняя итемы. а если еще трейд сделать как на яве(чтобы итемы не копировались) то за одно еще кучка дюпов пофиксится![]()
Прикреплю пост 7 летней давности:
Для этого NCSoft спрятал прямое обращение сервера к базе, и все идет через отдельный компонент CacheD.exe (который согласно архитектуре должен быть на отдельной ноде). У него большие IO буферы, L2Server все шлет прямо в CacheD, и если база залагает, то на L2Server это почти не отобразится, так как запрос будет обработан CacheD, ответ выслан, а запись в базу отложена в очередь.на ПТС, я так думаю (поправьте), как и для 1с сервера - на mssql идет хорошая нагрузка, в итоге если нет хороших винтов, база начнет через некоторое время лагать.

