Java游戏服务网站高并发后端架构：Spring Boot与Redis实践

简介：这是一份基于Spring Boot的游戏服务网站Java源码包，专为计算机、电子信息等专业的学生打造，适用于毕业设计、课程设计或期末大作业。项目采用B/S架构与MVC分层，整合SpringBoot、Mybatis、Ajax、Vue等技术栈，前端与后端代码分离，结构清晰。包内共646个文件，涵盖163个Java核心源码、117个Vue前端组件、41个JS脚本、45张JPG图片及34个PNG图标，另有CSS/XML/yml等配置与资源文件，压缩包整体仅22.18MB，轻量易部署。项目还附带了build/run脚本和关键备份文件（.bak），方便在IDEA或Eclipse中快速构建运行，也能对照Vue组件与Java后端理解前后端交互逻辑。目前已有593人浏览学习，源码经过严格测试，适合直接用于项目参考或二次开发，遇到环境配置问题可参考博主答疑。

1. 游戏服务网站代码，Java后端工程师该怎么拆

游戏服务网站看起来是一个网站，实际上背后要扛住登录、充值、实时消息、排行榜和运营后台几类完全不同的请求。很多刚接手这类代码的人会先去搜“游戏服务网站代码”的某个完整仓库，但真实项目里，它通常被拆成玩家端API、游戏逻辑服、管理后台和面向玩家的静态门户四块。Java在这条链路里的位置，主要是写有状态、要高并发的那几个后端服务，而不是只做页面渲染。下面按我自己做游戏后端时的套路拆解：先搭可跑通的Spring Boot骨架，再补会话、推送和排行榜，最后落到部署和上线稳定性。适合已经能写一点Java基础、准备做游戏后端或运营平台的人参考，也适合面试前快速理清游戏服务网站代码中必然要回答的会话、并发和部署问题。

2. 用Spring Boot搭游戏服务网站的最小可运行骨架

2.1 为什么选Spring Boot而不是Servlet/JSP

游戏服务网站如果早几年做，常见答案会是Servlet加JSP，现在再这么选，等于把不上线的时间浪费在重复搭建上。Java后端现在的事实标准是Spring Boot，它内置Tomcat，自动配置数据源、Redis和WebSocket，写业务的人只需要关注Controller和Service。游戏服务网站的特殊点在长连接、排行榜和高并发扣费，Spring Boot的spring-boot-starter-websocket、spring-boot-starter-data-redis正好覆盖这些点，不需要自己管理NIO线程。

另一个原因是招聘和排查成本低。Java面试题和Java面试八股文里，Spring Boot、Redis、并发几乎是必考项，新同事接手时能很快看懂。相比直接拿Netty写游戏网关，Spring Boot更适合做玩家查询接口、运营后台、公告下发这类IO密集型业务。但要注意：游戏逻辑服如果每秒要处理几万条玩家移动消息，不要把这些实时消息全塞进Tomcat的HTTP线程里。常见做法是网关服务负责长连接，Spring Boot管网站和运营接口，两者通过消息队列或Redis解耦。

2.2 项目结构和Maven依赖

先给一个可以照着建的多模块目录，能避免以后把网站代码和游戏逻辑混在一个包里：

game-service-site/ ├── game-common/ # 工具、实体、常量 ├── game-api/ # 玩家端HTTP接口 ├── game-admin/ # 运营后台接口 ├── game-gateway/ # WebSocket和TCP网关 └── game-web/ # 官网和静态资源

多模块不是必须的，但游戏服务网站通常有“给玩家看的接口”和“给运营看的接口”两种权限边界，分开后能直接用Spring Security拦截路径，比写一堆if判断干净。如果不是大型团队，也可以只有一个Spring Boot工程，用目录名区分api、admin、gateway。

最小可用依赖pom.xml片段是这样：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency>

spring-boot-starter-web负责提供Tomcat和Spring MVC，处理HTTP请求；spring-boot-starter-websocket为后面的实时推送做准备；spring-boot-starter-data-redis用来做在线状态和排行榜；spring-boot-starter-security统一做登录鉴权。这四个starter是游戏服务网站代码里的常见基础组合，实际版本跟Spring Boot版本走即可，不需要手动指定额外版本号。

2.3 核心接口：玩家状态查询与公告下发

游戏服务网站的第一个能跑接口，建议做“玩家在线状态查询”，因为它能同时验证Redis和MyBatis的链路。

@RestController @RequestMapping("/api/player") public class PlayerController { private final RedisTemplate<String, String> redisTemplate; public PlayerController(RedisTemplate<String, String> redisTemplate) { this.redisTemplate = redisTemplate; } @GetMapping("/online") public Result<PlayerStatus> checkOnline(@RequestParam Long playerId) { String key = "player:online:" + playerId; Boolean online = redisTemplate.hasKey(key); PlayerStatus status = new PlayerStatus(); status.setPlayerId(playerId); status.setOnline(Boolean.TRUE.equals(online)); if (Boolean.TRUE.equals(online)) { String lastBeat = redisTemplate.opsForValue().get(key); status.setLastHeartbeat(Long.parseLong(lastBeat)); } return Result.ok(status); } }

这里的key是“player:online:”加玩家ID，用Redis的hasKey判断在线，比查数据库快得多。lastHeartbeat使用登录或心跳时写入的时间戳，注意处理空指针，因为hasKey之后key可能被清理。调用方需要先登录，这个接口的playerId建议从token里取，而不是完全信任前端传参，避免越权查别人。

公告下发是运营后台的典型动作，重点是权限控制和广播：

@PostMapping("/announce/send") @PreAuthorize("hasRole('ADMIN')") public Result<Void> sendAnnounce(@RequestBody AnnounceRequest request) { announceService.save(request); stringRedisTemplate.convertAndSend("channel:announce", request.getContent()); return Result.ok(); }

@PreAuthorize保证只有管理员能调，Redis的convertAndSend会把公告消息发送到订阅频道，游戏客户端或网关收到后再推给在线玩家。这里把MySQL和Redis解耦了，公告先落库再广播，玩家离线后重新登录也能拉到历史公告。

2.4 配置说明和启动参数

application.yml里的几个参数要提前调好，不然上线第一周就会出问题：

server: port: 8080 tomcat: max-threads: 200 accept-count: 1000 max-connections: 10000 spring: datasource: url: jdbc:mysql://localhost:3306/game_site?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai hikari: maximum-pool-size: 50 redis: timeout: 2s

max-threads是Tomcat处理请求的线程数，Java安装后默认值比较保守，游戏服务网站通常调到200左右。accept-count是等待队列长度，排队比直接拒绝体验好，但队列过长会导致用户看到白屏很久才报错。Hikari连接池maximum-pool-size不要盲目调大，一次并发扣费场景下，50个连接已经够用，连接池过大会增加MySQL压力。

下面这几个参数是Java基础面试常被问到的点，施工时可以按表设置：

lazy-initialization建议只在本地调试时开，生产环境还是默认true或按需设置，因为游戏服务网站启动后如果所有Bean都懒加载，第一次请求会特别慢。

启动时用以下命令指定生产配置：

mvn clean package -DskipTests java -Xms2g -Xmx2g -jar game-api/target/game-api.jar --spring.profiles.active=prod

-DskipTests跳过单测加速打包，--spring.profiles.active=prod加载application-prod.yml里的环境变量和连接串。注意打包前准备好生产配置，不要把数据库密码写到仓库里。

3. 游戏业务核心：在线会话、实时推送与排行榜的Java实现

3.1 WebSocket实现在线通知

玩家上线、被踢下线、活动奖励到账，这些消息用HTTP轮询体验差，游戏服务网站代码里一般用WebSocket推送。Spring Boot接入WebSocket很简单，先声明一个处理器：

@Component public class GameSocketHandler extends TextWebSocketHandler { private static final Map<Long, WebSocketSession> SESSIONS = new ConcurrentHashMap<>(); @Override public void afterConnectionEstablished(WebSocketSession session) throws Exception { Long playerId = (Long) session.getAttributes().get("playerId"); SESSIONS.put(playerId, session); pushOnlineNotice(playerId); } @Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { // 收到客户端心跳或上行消息，这里省略业务解析 } @Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception { Long playerId = (Long) session.getAttributes().get("playerId"); SESSIONS.remove(playerId); } }

SESSIONS是本地进程内的会话表，key是玩家ID，value是WebSocketSession。afterConnectionEstablished里把playerId从session attributes取出来，这正是为什么在握手阶段要拦截器验证token并写入playerId。如果直接使用session.getId()，之后想按玩家维度推送根本找不到对应连接。handleTextMessage可以处理心跳和客户端发来的移动同步，生产环境这里通常只做转发和逻辑校验。

推送时调用：

public void pushMessage(Long playerId, String payload) { WebSocketSession session = SESSIONS.get(playerId); if (session != null && session.isOpen()) { session.sendMessage(new TextMessage(payload)); } }

这段代码要处理sendMessage抛出的IOException，比如玩家断网但服务端还没触发close事件时，消息会发送失败，常见做法是捕获后从SESSIONS里清理。

3.2 会话存储：本地Map与Redis的取舍

上面用ConcurrentHashMap存储会话，单实例没问题，但游戏服务网站通常有多个后台实例或网关实例，玩家连接在实例A，公告服务在实例B推送时会找不到session。常见方案有三种，简单列在表里：

我一般会这样选：处理玩家实时动作的逻辑服，用本地Map加一致性哈希把玩家固定路由到某个节点，这样访问最快；游戏服务网站的管理端推送，用Redis订阅广播，保证每个实例都能收到。不要迷信“全放Redis就支持水平扩展”，长连接对象本身不适合塞Redis，存NodeId和玩家ID映射，实际推送时再查本地Map就行。

3.3 Redis ZSet实现排行榜

排行榜是游戏服务网站引发高并发的重灾区，排行榜更新频率高、读多写多，用MySQL表排序太慢。Java代码里最常用的方案是Redis的Sorted Set。

public void updateRank(Long playerId, int level, long exp) { double score = level * 100000.0 + exp; stringRedisTemplate.opsForZSet().add( "rank:level", String.valueOf(playerId), score); } public List<String> topN(int n) { Set<String> range = stringRedisTemplate.opsForZSet().reverseRange( "rank:level", 0, n - 1); return new ArrayList<>(range); }

score用“等级*100000+经验”合成，目的是让玩家先按等级降序、再按经验降序。100000这个常数需要根据经验值上限调整，比如单级经验最大99999，就乘100000保证高级别的低经验玩家依然排前面。ZSet的成员是字符串playerId，不要在成员里拼当前排名，否则玩家改名或ID变更会导致数据错乱。每次新增或获得经验时调用add，复杂度是O(logN)，远低于数据库count。

注意ZSet分数是double，如果经验值是long，乘到1e15以上会丢精度，游戏数值很大时要改用分段存储或按（等级，经验）两个key的比较器。这里是个坑，Java用double做超大数值排行榜会有隐蔽错误。

3.4 购买道具的并发控制

游戏服务网站的充值、抽奖、购买都是并发高危点，玩家连点两次“购买”可能扣两次钱、发两个道具。

@Transactional public void buyItem(Long playerId, Long itemId, int count) { Item item = itemMapper.selectByIdForUpdate(itemId); int rows = assetMapper.deductBalance(playerId, item.getPrice() * count); if (rows == 0) { throw new BusinessException("余额不足"); } inventoryMapper.addItem(playerId, itemId, count); }

selectByIdForUpdate会对商品行加悲观锁，防止两个事务同时读到同一份价格。assetMapper.deductBalance使用update语句“balance = balance - ? where player_id = ? and balance >= ?”，返回影响行数，返回0就说明余额不足，抛出业务异常后整个事务回滚。注意这里的事务中不能有耗时过长的外部调用，否则锁持有时间太久，拖慢所有购买请求。

高并发场景下，常见改进是从MySQL转移部分到Redis Lua脚本。用Lua原子执行“扣减余额+发放道具”两步操作，异步落库，能明显降低数据库行锁冲突。下一条会给出一个可用作参考的限流脚本，原理类似。

4. 把游戏服务网站部署到云服务器：打包、调优与排错

4.1 JDK安装与环境变量配置

到这一步，先确认服务器上的Java环境。游戏服务网站推荐JDK 17或21，不要用服务商自带的旧版本。Debian/Ubuntu可以这样安装：

sudo apt update sudo apt install -y openjdk-17-jdk ls /usr/lib/jvm

执行ls /usr/lib/jvm后能看到类似jdk-17的目录，把它写进/etc/profile：

export JAVA_HOME=/usr/lib/jvm/jdk-17 export PATH=$JAVA_HOME/bin:$PATH

执行source /etc/profile并运行java -version，出现版本信息就说明Java环境变量配置成功。如果你用的是CentOS，把apt换成yum install java-17-openjdk-devel即可。注意JAVA_HOME路径不要带子目录的bin，PATH再单独把$JAVA_HOME/bin加进去。现代Java不再需要CLASSPATH，Java基础教程和面试题里那套classpath配置可以省掉，配错反而干扰启动。

4.2 打包jar和Nginx反向代理

游戏服务网站用Maven打包并启动的命令：

cd game-service-site mvn clean package -DskipTests nohup java -Xms2g -Xmx2g -XX:+UseG1GC -jar game-api/target/game-api.jar \ --spring.profiles.active=prod > logs/game-api.log 2>&1 &

nohup和&让进程在退出SSH后不挂掉，stdout和stderr都重定向到日志文件。新手常犯的错误是忘记加--spring.profiles.active=prod，结果连的localhost开发库，所以启动后先看日志第一行加载了哪个配置文件。

Nginx在游戏服务网站前面做域名转发，配置文件片段：

server { listen 80; server_name gamesite.example.com; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

游戏服务网站有两个location，普通API走/api/，WebSocket走/ws/。后者必须加Upgrade头，否则浏览器返回400 Bad Request。proxy_pass不带结尾的/，这样请求路径会原样转发，不会丢段。

4.3 JVM参数和Tomcat线程池调整

虚拟机参数要和游戏服务网站的实际内存匹配，常用设置：

Tomcat的线程数要根据接口RT来估算。假设平均接口响应50ms，那么单线程每秒能处理20个请求，一个Tomcat线程池200线程理论上能支撑4000 QPS，但实际还要考虑数据库连接池和Redis带宽。线程数太大反而增大上下文切换，游戏服务网站这类业务建议200左右起，压测后再调整。

4.4 用Arthas排查CPU飙高

代码上线后CPU飙到100%是Java工程师最常遇到的故障。用Arthas能直接定位到方法：

java -jar arthas-boot.jar # 选择game-api进程 dashboard # 查看CPU占用最高的线程 thread -n 3 -i 1000

dashboard先看线程概况，thread -n 3显示最忙的3条线程，-i 1000表示采样1秒。输出里会包含线程执行栈，找到栈顶自己的业务方法，基本就能定位到死循环或大对象循环遍历。常见原因是JSON库反复解析超大公告内容、Redis连接池耗尽导致阻塞，甚至日志打印过多导致IO线程卡住。如果是GC导致CPU高，用jstat -gcutil查看FGC次数，一般要换成G1并调大年轻代。

5. 让游戏服务网站代码更稳的三件事：幂等、限流与灰度

游戏服务网站上线后，最难的不是功能，而是“玩家多按了一次按钮”“运营发公告瞬间流量暴涨”“新版本逻辑有问题又不能回滚”。这三个场景分别对应幂等、限流和灰度，是Java后端项目里很实用的小技巧，Java面试题也常考。

5.1 接口幂等

购买、抽奖这类写接口，先在Redis里放一个幂等令牌，业务充值单号或客户端生成的请求ID作为key：

boolean lock = stringRedisTemplate.opsForValue() .setIfAbsent("idempotent:buy:" + businessId, "1", 5, TimeUnit.MINUTES); if (!lock) { throw new BusinessException("重复提交"); } try { buyService.buy(playerId, itemId, count); } finally { stringRedisTemplate.delete("idempotent:buy:" + businessId); }

setIfAbsent是原子操作，多个并发请求只有一个能拿到key。注意删除时机：业务完成后要删除key，否则玩家5分钟内不能买第二个同款商品。如果业务又需要防重又要完成前不能重复，就不要在finally里删，让key自然过期，业务表里再做唯一索引。

5.2 用Redis Lua做全局限流

限流常见做法是Google Guava的RateLimiter，但那是本地单机限流，游戏服务网站部署多个实例时会各放各的，总上限变成实例数乘以阈值。推荐用Redis加Lua脚本：

local key = KEYS[1] local limit = tonumber(ARGV[1]) local window = tonumber(ARGV[2]) local current = redis.call('incr', key) if current == 1 then redis.call('expire', key, window) end if current > limit then return 0 end return 1

调用时把key设为“ratelimit:announce:20250101”，limit设为100，window设为60。脚本先自增，若第一次则设置过期时间，若超过限制返回0。Java里用DefaultRedisScript执行这段Lua，执行体在Redis内部原子完成，多实例共享一个Redis就可以做到全局限流。注意窗口期很短时，刚过窗口的流量会瞬间放行，还要配合Nginx的limit_req按IP限流。

5.3 灰度发布

游戏服务网站的新排行榜算法或者新支付渠道，不要直接全量上线。常见做法是从Redis读灰度开关，再按玩家ID取模：

boolean grayOpen = Boolean.TRUE.equals( stringRedisTemplate.hasKey("gray:new-rank-service")); if (grayOpen && playerId % 100 < 10) { return newRankService.query(playerId); } return oldRankService.query(playerId);

玩家ID取模100，小于10表示放量10%。运营和测试可以把指定玩家ID直接加入白名单，验证完再逐步调大比例。灰度开关单独用一个Redis key，不需要重启服务。配合Nginx的upstream权重也能做流量切分，但业务内开关更适合做逻辑切换和控制。

这套“幂等+限流+灰度”的思路能让游戏服务网站代码从“能跑”变成“稳定跑”，也正好是Java后端项目经验里最值得拿出来讲的三个点。上线后写个压测脚本跑一遍，看限流和幂等场景是否符合预期，再决定要不要放量。

本文还有配套的精品资源，点击获取