思维整理

目前整体目标还是想做游戏，做游戏服务端开发

概括：

语言： Golang C++ Lua Rust 3days delay

网络传输： UDP/KCP WebSocket TCP

序列化： Protobuf FlatBuffers

缓存： Redis 本地内存

持久化： MySql MongoDB（

RPC： gRPC Thrift

服务发现与配置： Consul Etcd Nacos

MQ： Kafka RocketMQ RabbitMQ

容器化： Docker K8S

整体技术栈思路

核心语言与开发框架：

我觉得技多不压身，而且有那个能力三者混着学

传输层（协议）：
- UDP / KCP：
  
  几乎是现代竞技游戏的标配。纯 UDP 容易丢包，因此业界普遍在 UDP 之上叠加 KCP（一种可靠的 ARQ 协议）或者谷歌的 QUIC，以实现“既有 UDP 的速度，又有 TCP 的可靠”。
- WebSocket：
  
  H5 小游戏、网页游戏以及大厅服的标配。
- TCP：
  
  如今较少用于核心战斗，但依然稳服务于对延迟不敏感的 SLG、回合制或纯大厅聊天系统。
序列化协议（数据结构）：
- Protobuf (Protocol Buffers)：
  
  绝对的行业标准。体积小、解析快、跨语言，几乎所有商业项目都在用。
- FlatBuffers：
  
  在某些追求极端零拷贝（Zero-copy）性能的实时战斗服中，用来替代 Protobuf。

游戏数据的特点是：高频读写，但单次写入的数据量较小。

内存缓存层：
- Redis：游戏行业的“劳模”。用于存储玩家的在线 Session、排行榜、社交关系、即时匹配队列。
- 本地内存缓存：战斗服通常直接将玩家状态维持在内存中，定期或在玩家下线时才“落盘”写入数据库。
持久化数据库：
- MySQL：
  
  用于存储结构化且对数据一致性要求极高的核心资产（如玩家的充值记录、账号数据）。通常搭配分库分表（Sharding）。
- MongoDB (NoSQL)：
  
  在现代游戏中极受欢迎。因为游戏更新频繁，经常会给玩家背包增加新字段，MySQL 改表结构很痛苦，而 MongoDB 的文档型（JSON-like）结构非常契合玩家属性这种多变的数据。

微服务与集群：
- 传统游戏习惯使用“开服分区”的单体或集群架构；而现代大服（如全区全服游戏）普遍采用微服务，将大厅、战斗、匹配、聊天、充值彻底拆分。
- 常用的 RPC 框架包括 gRPC 和 Thrift。
服务发现与配置：
- Consul / Etcd / Nacos：用于服务注册与发现，管理成百上千个游戏节点。
消息队列：
- Kafka / RocketMQ：主要用于异步处理大吞吐量的行为日志收集（为运营和数据分析准备）或离线补偿（如充值回调）。

容器化 (Docker & Kubernetes)：
- 以前游戏服务端很难上 K8s，因为战斗服是“有状态的（Stateful）”，玩家掉线重连必须回到原来的那台服务器。
- 现在，借助于谷歌开源的 Agones（专门基于 K8s 开发的游戏服务器托管框架），各大厂已经普遍实现了核心战斗服的容器化动态扩缩容，极大地节省了服务器成本。