简单介绍汇闲麻将后端的并发架构

写在前面

受到政策因素影响，经历了近三个月封闭开发的汇闲麻将最终还是没能成功上线。当前的感悟，创业的路上有很多槛，技术研发只是其中的一个槛。

这里仅以一名程序员的角色总结一下汇闲麻将的后端架构，也算是给过去三个月的自己一个交代。

汇闲麻将的后端架构

信息收集

就我个人的方法论，拿到一个问题后，① 首先要做的是尽可能多地收集情报，② 然后分析情报，有必要的情况下还要进一步收集情报，③ 接着才是制定方案，④ 最后实施方案。

三个要求

在后端架构初期，负责产品的同事就给后端的架构提了三个老生常谈的要求：

汇闲麻将后台中的核心对象

需要考虑的几个关键问题

  1. 同一个玩家的不同操作需要是保序的，比如用户登录后才可以进行入牌桌的动作；
  2. 同一个牌桌上进行的操作也需要是保序的，比如入桌顺序、出牌顺序等；
  3. 需要控制协程（goroutine）的数量，避免恶性增长资源耗尽；
  4. 需要监控牌桌信息，采样牌桌状态从而便于查错；
  5. 玩家的断线重连，游戏状态的恢复；
  6. 机器人玩家的开发；
  7. 其他。

上面的几个问题并未涉及到麻将游戏的具体逻辑（比如算输赢、算番数等），架构做好后可以填充这些逻辑。

历史经验

  1. 为了避免并发问题，传统的麻将游戏后端，每个房间一个进程；例如菜鸟场、富豪场，每个场都是一个房间，房间里包含许多的牌桌，这些牌桌上的逻辑由一个进程轮转处理。
  2. 每个房间启动一个进程，并暴露对应的端口供客户端连接。
  3. 用户进入游戏的的逻辑步骤是这样的：① 用户首先登陆到登陆服务器进行登陆鉴权；② 用户拿着鉴权得到的秘钥连接到大厅服务器，进行转盘、签到、任务、选择房间入桌等操作；③ 用户选择房间后，连接具体的房间服务器（游戏服务器）进行游戏；④ 用户进行完游戏后，与游戏服务器断开，重新与大厅服务器建立连接，回到步骤②。

信息分析与结论

由于我的技术栈是 Golang，因此选定了 Golang 作为汇闲麻将的后端开发语言，分析问题的时候自然就带入了 Golang 的语言特性。

  1. 受开发资源（时间和人力）的限制，不拆分登录、大厅、游戏等模块，在一个代码库中进行开发，方便把控研发节奏，降低前期的运维难度；
  2. 同样的道理，游戏服暂不按照房间进行进程上的划分，所有的房间都在一个主进程下面（启用 Golang 的多线程特性），对房间里的牌桌进行动态调整（如果某个房间里的牌桌不够用，而其他房间里闲置的牌桌比较多，就临时“借一个”使用）。
  3. 每个牌桌挂一个 goroutine 处理牌桌上的信息（牌桌状态轮转、用户出牌吃牌等）；
  4. 大厅的交互频次较低，只需挂一个 gotoutine 处理所有用户的相关动作；
  5. 玩家断线重连时，通过替代底层的 session 进行恢复；
  6. 数据入库时由专门的 goroutine 池负责写入，从而避免对游戏逻辑的阻塞（为此还专门写了开源项目 gochan）；
  7. 为方便分析各个组件的状态，统一打印日志，并把日志收集到 ELK 中进行分析（为此专门写了开源项目 sugar）；
  8. 其他。

汇闲麻将后端架构里的并发模型

在架构设计初期，我曾经尝试通过 锁 的方式维持玩家、桌子等的信息一致性，后来编写代码的时候发现逻辑非常的啰嗦，很多操作都需要考虑到加锁与解锁，当业务逻辑稍微变得复杂后难以维护，还很容易出现死锁的情况。那几天正好看到一位同事在玩《异星工厂》，受里面的传送带的启发，构思出了最初的“游戏后端线程架构图”原型，如上图所示。

“不要通过共享内存来通信，要通过通信来共享内存”，这句话是 Go 社区中非常经典的一句话。上面的架构图的设计一脉相承了“通过通信维护对象状态”的思路。每个协程（goroutine）搭配一个传送带（buffer-channel），此协程只处理自己传送带上的逻辑（闭包）。上图中每个圆圈都是一个协程，圆圈的周围则是配套的传送带，外界（其他协程）可以把逻辑封装放置在传送带上，然后被当前协程顺序进行处理。

具体的：① 每个用户与游戏服的长连接上面挂两个协程（goroutine），其中读协程（read）负责读取客户端传送过来的数据，写协程（write）负责写服务端返回的数据给客户端。② 读协程对用户数据进行拆包后，把请求打包成为任务放置到主协程（main）的传送带上（信道），主协程依次处理自己传送带上的任务，进行简单的逻辑处理后分发给相应的牌桌（table）（把逻辑打包成为任务放置到牌桌的传送带）；③ 各个牌桌的协程依次处理自己传送带上的任务，并把响应的发送任务给写协程（write）；④ 写协程负责统一把数据返回给用户；⑤ 对于不同房间（room）中桌子的分配、借还等，由一个总的房间协程统筹进行管理。

有了上面的并发模型图，模块的划分就变得有依据也更合理，差不多花了两个月的时间，汇闲麻将就部署到预发布环境进行测试了。最后因为政策限制没有能正式发布，还是非常可惜的。。。

小结

“不要通过共享内存来通信，要通过通信来共享内存”；在设计并开发完汇闲麻将的后端业务逻辑后，感觉对这句话的理解更透彻了。当然，这里并不是强调锁没有使用价值，其实在一些场合下使用锁会更合理，就像《浅谈 Golang 中数据的并发同步问题（三）》中所描述的那样。

参考