skynet 游戏服务器框架分享

百万游戏案例演示游戏服务器开发 框架——skynet
skynet实现万人同时在线游戏

分享下我之前做的服务器框架; 游戏在线最高3万; 物理机I7的3台阿里云分服;性能及其强劲;

框架:底层基于比较流行的 skynet ,基础采用c语言,脚本lua,部分服务golang;

Skynet:是一个基于C跟 lua 的开源服务端并发框架,这个框架是单进程多线程 Actor 模型。所以他对于机器的性能压榨是很高的。

  • skynet 为游戏主逻辑服务;
  • go 微服务作为辅助服务;
  • ​redis 作为直连主数据层;
  • mysql 作为冷备+关系查询;
  • proxy 支持 tcp,udp,websocket (支持 http 和 https )
  • 通信协议 Protobuf

特点:

1. 性能:底层采用了多线程+多luastate+协程, 性能优秀

2. 简单: 采用了actor模型,并发无锁,上层coding无感知

3. 沙盒: 利用多线程中 lua coroutine 的应付 IO 密集型的优秀能力; 也用 lua 沙盒做到了环境的软隔离;

缺点:

未引入分布式的 zookeeper 协调控制,采用了 world 的单点模型,容灾性较差,服务发现也比较原始;

前端:

proxy:

代理层; 独立进程部署, 主要由原生的go编写;

用来兼容接收多种socket 以便支持 tcp,udp, websocket;

负责桥梁搭建:

第一条: client->proxy->gate;

第二条: client->proxy->ms service

gate:

网关层; 独立服务, 支持横向扩展,主要是进行 client-proxy-gate 之间的

连接管理; 与所有 game 进程直连; 也与 ms service 的网关相连

逻辑层:

game service:

游戏逻辑服务, 支持横向扩展; 主要是处理基于有状态的相关模块:如战斗,技能,副本等;

ms service:

微服务模块; 抽象出 微服务gate,接收其他服务直连,转发相关消息至微服务集群;

主要分担gate的连接压力,并且分担逻辑方面game service的相关压力

处理模块: 客户端配置获取, 签到, 活动, 小红点, 邮件, 聊天, 工会, 开关等等此类 无状态的逻辑;

world service:

顶层世界服务模块; 与几乎所有的service进行连接;

主要是管理所有的服务,玩家状态等等; 以及做一些广播,组播; 也提供热更的对外接口; 也提供一些简单的业务逻辑: 诸如全服boss等; 会有slave保证高可用;

数据层:

DB service:

数据层; 主要负责与redis进行直连; 也与mysql进行直连;

每个game service会定时将data的更新发送到DB service; ms service 则会根据业务情况决定是否直接找DB service进行数据交换还是 找game service进行数据交换;

redis:

采用了哨兵集群模式,开启 AOF

mysql:

作用有二:

1: 冷备, 回档

2: 提供一些简单的关系型查询;一般是对实时性不敏感的需求;

append data service:

数据记录; 主要是追加模式写数据更新到db的记录; 便于查档,归档;

DB daemon service:

独立进程,进行redis的"脏数据"写入到mysql中,并且写入成功后追加到append data中; 可以配置 以事务和批量的模式进行写入;

辅助层:

rabbit mq:

  1. 作为集群的全局队列用;
  2. 集群所有service(包括slave)都要定时发送心跳/负载等信息到mq
  3. 微服务会定时消费以上的心跳/负载, 进行负载和进程挂掉的判定, 异常时进行广播;
  4. 所有服务会订阅几个关键信息: 择主, 重连, 主备切换, 负载上限

third sdk service:

第三方sdk服务; 如神策等等:

skynet服务器 --> third sdk service --> 按照json格式写入log文件 --> 提交给神策后台

底层核心:

  • skynet是基于事件的高并发消息处理框架。
  • 事件主要来源: 网络,定时器和信号通知等
  • 当事件触发时,skynet将这些事件统一编码成消息结构,派发给感兴趣的服务处理;如果当前无事件,可以做到该服务0的CPU消耗
  • 核心数据结构是 skynet_context :
  • 并发解决方案: 消息队列:每个服务都有一个消息队列,当队列中有消息时,会主动挂到全局链表。skynet启动了一定数量的工作线程,不断从全局链表取出消息队列,派发消息给服务的回调函数去处理。(在 callback 函数调用回工作线程时,消息队列没有被放回全局队列,其它工作线程没有可能获得这个 callback 函数所属服务的消息队列,所以该服务也就不可能存在并发风险了)
转载于:cnblogs.com/left69/p/14


C++Linux服务器开发/架构师 面试题、学习资料、教学视频和学习路线图(资料包括C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg等),免费分享有需要的可以自行添加学习交流群 973961276

发布于 2021-11-15 15:54