游戏公会工作总结

54 阅读 0 评论 36 点赞

我是靠谱客的博主幸福背包，最近开发中收集的这篇文章主要介绍游戏公会工作总结，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1. 前言... 2

2. 公司后台架构... 2

2.1 架构图... 2

2.2 基础功能... 2

2.3 基础服务... 3

3. 公会业务后台分析... 4

4. 业务架构... 5

4.1 首先看一下异步模式的基本模型... 6

4.1.1 基本结构... 6

4.1.2 异步解决方案... 6

4.1.3 如何使用... 7

4.1.4 异步模式编程优缺点... 7

4.2 状态机... 8

4.2.1 什么是状态机... 8

4.2.2 TCP有限状态机... 8

4.3 项目中使用... 10

4.3.1 定义一个基类... 10

4.3.2 定义多种状态... 10

4.3.3 具体子类实现... 11

4.3.4 实际场景... 11

4.3.5 异步状态机总结... 12

5. 工作中常见问题... 12

5.1 网络问题... 12

5.2 线程间通信... 13

6. 项目架构的改进... 13

7. 新工作... 13

1. 前言
想写这篇文章已经脱了很久了。本文主要写一写我在游戏公会组所做事情和成长吧。

在这里，首先要感谢我的前老大，技术组leader，郭文瑞，具有十几年的技术经历。技术广度和深度都是公司首屈一指的。还有他对技术的敏感程度是非常值得敬佩的。项目成立之时，感谢他对我的信任和帮助，才让我能够基本独立的完成游戏公会后台的设计，架构，开发等工作。目前，郭文瑞已经离职，在一家深圳公司做CTO。
以下我们公司的YY后台的一个整体架构以及公会组内部的一些基本关系。
我们项目属于YY频道内的一个服务，YY频道内的所有功能都是通过service端的连接和用户进行交互
整体都是分布式架构。使用大量的开源软件，thrift，redis等优秀开源产品
2. 公司后台架构
2.1 架构图

而我们组内的技术工作，就是使用service C++ SDK来架构我们的业务工作。sdk 给我们提供了一些主要接口，比如接发消息接口，频道广播，进程间广播等等需求。

2.2 基础功能
• 客户端到应用服务端透传通道
• 请求应答模式
• TCP/路由自动切换
• 支持多种转发规则（uid一致哈希、sid一致哈希、频道区间订阅）
• 支持多种部署策略（按机房部署、按ISP部署）
• 小ISP(教育网、移动等)智能路由
• 按业务隔离避免资源竞争
• 应用层组播
• 支持多种组播模式：顶级频道组播、子频道组播、应用自定义组播、uid列表组播...
• 双路可靠
• 按业务隔离避免资源竞争
• 单播/多播
• 定位用户接入点，主动推送数据，支持多个uid推送
• 双路可靠
• Service间发现/通信
• 可靠的节点发现：两个决策节点
2.3 基础服务
• 频道在线用户列表CUL（Channel User List）
• 用户进/退/跳频道事件通知
• 用户所在频道查询
• 在线用户角色查询
• 频道麦序服务
• 上下麦事件通知
• 查询频道麦序列表
• 频道信息服务/公告服务
• 频道信息缓存，提供读取/更新频道属性接口
• 用户信息/扩展信息服务
• 提供全网用户昵称/签名等信息的缓存
• 用户频道尾灯信息统一缓存，提供业务同步用户尾灯信息的接口
• Service业务接入代理层（SAL）
• 对于一些不使用Service C++ SDK的业务，提供协议接入层搭建Service后台
• Service业务统一多协议接入代理（SAA）
• 支持Thrift、HTTP和YY协议访问Service平台的服

以上的所有个功能与服务是公司各个组分工合作的结果。当然YY的更重要的语音视频传输是公司更重要的，更核心的东西。

当然YY很多在线的实时信息，比如，麦序，名字等服务都是基于redis的集群。然后在同步更新到mysql数据库中。

3. 公会业务后台分析

1、我们后端涉及到很多服务，比如麦序，任务系统，个人信息，存储等等各方面的数据
2、当一个用户请求上来，如何能够简单，高效，完整的把所有涉及到的系统有机结合起来，获得我们想要的数据呢？
3、我们进程尽量少的做业务处理

4. 业务架构

状态机，异步。redis介绍等。

由于我们的service依赖于很多外部服务当一个请求过来需要各方数据，比如，我们需要当前在线的麦序主播，以及他的相关马甲信息等，这些数据都是通过api接口提供给我们，而且也是通过网络服务，因此，我们们不能等待对方完成才做下一件事情，会严重拖慢我们每个消息包处理的效率，如果某个节点的网络服务突然中止，而我们还在不停等待，用户也在不停的等待，使得用户体验很不好。
因此我们选择全部使用异步状态机的模式。
4.1 首先看一下异步模式的基本模型
4.1.1 基本结构

• 当异步请求过来的时候，Async引擎会针对每个请求建立上下文
• Async引擎将请求放入请求列表进行请求
• Async返回，处理第一步
• 处理端进行数据处理，将数据写到fd中
• async引擎根据回来的数据包和对应的上下文，处理下边的事情

因此，async异步处理引擎不会因为各种事情阻塞，接受请求，发出请求，都是立即返回，直接往下执行。因此，我们会根据每个请求进行建立上下文，要么保存在本地，要么随着数据包进行下发。
优缺点
4.1.2 异步解决方案
 Redis-----使用Hiredis实现异步方案
 任务中心-----使用thrift异步解决方案
 角色服务中心----Service的回调函数绑定（RedisClient）

4.1.3 如何使用
Redis使用

Thrift使用

4.1.4 异步模式编程优缺点

 优点：高效，不需要额外的线程负担
 缺点：编程复杂，处理失败复杂

4.2 状态机

4.2.1 什么是状态机
就是在需要多个异步系统的里，为维护同一个异步上下文，根据上一个异步状态执行结果，来决定下一步如何执行。

简而言之：不同的状态,不同的行为;或者说,每个状态有着相应的行为.

4.2.2 TCP有限状态机
经典的状态机模型是在tcp路由中现实出来的。如下图

异步方案中，有很多步骤，因此，我们把每一步都设置为一个状态。
1、要创建带有状态的上下文内存
2、设置相应的状态
3、根据每一步的状态执行相应代码

4.3 项目中使用
4.3.1 定义一个基类
我们将会定义一个基类Task，通过继承，创建不同子类对象，然后使用该对象的地址作为上下文，在各个系统中轮转，达到系统的松散耦合。

4.3.2 定义多种状态
定义多种适合我们系统的状态。
比如：初始状态，写redis状态，读redis状态，任务中心状态，各种错误状态等

4.3.3 具体子类实现

4.3.4 实际场景
比如，客户端请求，我们首先要去角色服务中心确定权限，然后再去任务中心获取相应数据，最后在把相应数据存储到自己的redis服务里，最后再把处理数据返回给客户端

4.3.5 异步状态机总结
 状态总数（state）是有限的
 任一时刻，只处在一种状态之中
 某种条件下，会从一种状态转变（transition）到另一种状态

5. 工作中常见问题
5.1 网络问题
在工作中，我们经常遇到网络问题，尤其在我们公司，各种运营商的机房，跨网，是否单双线机房，等问题，数据包不对，没有回报。
这个时候，就要用到我们的利器，tcpdump和wireshark分析包工具了

如下例子，我们可清晰看懂，比如，我们现在想抓具体主机和端口号下的数据包是否有问题

tcpdump -XXnnS -i any host 183.61.143.107 and port 6349 -w /home/wangchenglin/redis.pcap

生成的redis.prcap文件，down到windows下观察，

就会看到有包重传现象。还可以看到ack发出一个包后，回报的时间等。非常清晰，

5.2 线程间通信
线程间通信，我们通常使用队列，当两个线程同时对队列进行操作的时候，必然使用锁的机制。频繁的加解锁会导致效率低下。
因此，我们使用了事件通知机制和时间机制。
#include <sys/eventfd.h>
int eventfd(unsigned int initval, int flags);
将其注册到ae事件库中。
当消息队列达到一定条件，触发线程读或者写等

6. 项目架构的改进
鉴于公司在推动新的sdk工作内容，提供了全新的API，都是那种C风格的接口，这样一来对我们工作就十分好开展了。
最开始使用该新的api接口还是在公司的网络框架上，公司的网络框架式很笨重的，c++实现的一些很让人难以理解的网络接口。
而新sdk的接口就只是给我们提供了一个操作符给我们，这个我们的框架重构带来了很大的便利。
说多无益，直接上代码，后续开通一个git，来更新代码吧！

7. 新工作

目前就职于YY娱乐部门的后台相关的开发。

更多文章，欢迎查看 :http://blog.csdn.net/wallwind 转载请注明出处