共计 4399 个字符，预计需要花费 11 分钟才能阅读完成。
早早就想写这篇文章，但这段时间忙于工作的事件，就不盲目地给了本人各种懈怠的理由。当初回头看下这个问题，总结下 erlang 游戏开发教训。就当是，为我过来一段时间的 erlang 开发经验，画上一个小句号。
1. 架构设计
很多人都说 Erlang 天生分布式，归纳起因是 erlang 分布式这块实现比较完善。节点间的通信是通明的，无论是节点内的过程，还是不同节点的过程，都能够应用 erlang:send/2 发送音讯，而且数据不须要做任何转换。
所以，很多我的项目会选用多节点架构，能够通过横向拓展（减少机器数量）来撑持更多负载，把性能压力大的子系统调配到不同的节点，这样，就能够 反对更多的在线玩家。
这样做的出发点是好的，但会引起一系列的问题：
1、业务逻辑的问题：
跨节点逻辑变得复杂，玩家数据同步、一致性问题，节点断开及重连的解决等
2、语言局限性问题：
节点间音讯通信要序列化和反序列化，原子 传输要转成字符串，二进制复制 等
那架构抉择单节点，还是多节点？
没有相对，这要看游戏而定。如果你的游戏像页游那样，分服而且各个服之间交互较少，单节点会比拟适宜。但如果像 lol 那种对战玩法的游戏，多节点会比拟适合，登录和玩法在不同的节点，玩家对战时抉择集群内压力较小的节点做战斗计算。
单节点，益处是玩家数据容易保障统一，运维不便。以常见的 MMORPG 游戏，单节点在 16G 内存，8 外围 CPU，能够撑持 2k 人稳固在线，思考非沉闷玩家，达到 5000 也是可能的。当然，游戏的框架要正当设计，做一些斗争，比方玩家寻路不能在服务端做，地图 九宫格的设计，排行榜不实时刷新，管制同屏玩家数量等 等。当初，单节点做游戏服，还有一个重要起因是，当初的机器性能相较以前高很多了，加上 erlang 无锁的 Actor 设计在并发场合下解放了 cpu，从某种程度上讲进步了 cpu 的运算能力。
单节点的设计：
多节点的设计：
!
erlang 节点留神一个问题，默认 erlang 节点是全联通的，也就是当一个节点退出集群时，集群其余所有节点会和新退出的节点建立联系。全联通带来的问题，集群节点间两两连贯，随着节点减少，连贯数量呈 N *(N-1)/ 2 增长，越发恐怖，连贯自身占用了端口资源。更坏的是，为了检测节点的存活，erlang 会定期发心跳包查看，即便一分钟一个 tick，节点多的话也会造成大量的网络风暴。
解决办法就是在集群中暗藏节点，就能够防止全联通，只有 erlang 启动加个参数即可 -hidden
- 数据库
数据库 io 向来都是游戏的次要性能瓶颈，解决不好容易导致 游戏卡顿，甚至解体。而通用的长久化策略就是，内存读写 + 定时长久化。玩家上线时，加载玩家频繁用到的数据到内存，玩家大多时候就是在读写这些数据。而后定时把这些数据从内存刷到磁盘，在玩家下线时也做一次长久化。
说下 erlang 自带数据库 – mnesia
实际上，erlang 已实现了这样一套长久化机制，也就是 mnesia 数据库。
mnesia 数据存储是基于 ets 和 dets 实现，对于 ram_copies 表应用 ets；disc_copies 表同时应用 ets 和 dets，数据读写应用 ets，dets 做长久化；而 disc_only_copies 表应用的是 dets
这里先探讨 disc_copies 的状况，mnesia 启动时，会将 disc_copies 表所有数据加载到 ets 表中，每次读数据都是读 ets，写数据则会先写到 ets，而后再写一份到日志文件中，期待定时（或定量）长久化刷到 dets。
通常 disc_copies 表能够满足咱们的业务需要，但应用 mnesia 要留神一个问题。后面也提到了，mnesia 启动会将表中的数据加载到 ets，如果你的表过大，就会导致内存被急剧消耗掉。（特色就是，ets 所占的内存比率过大）
所以，应用 mnesia 表时，常常都是要 disc_copies 表和 disc_only_copies 表配合应用。那问题来了，什么时候应用 disc_copies 表，什么时候 disc_only_copies 表。
最简略的就是，对玩家数据动刀。玩家数据默认用 disc_copies 表，如果长时间没登录后将这个玩家的数据移到 disc_only_copies 表，等到他下次登录时再将数据移到 disc_copies 表。
之所以能够这么做，理由有两个：
- 游戏中玩家数据所占的比例较大，调整玩家数据能够取得显著收益。
- 玩家散失后回到游戏的可能性很小，就算有的话比例也不大。
这么做的弊病就是玩家散失后从新登录的工夫较长，但通过这种形式缩小的内存很可观。
mnesia 的应用，还要留神 3 个问题：
- mnesia 单个表 2G 文件大小限度，所以要本人分表，或者应用表分片
- mnesia 集群性能，过多的人说有坑，但我没有这方面的教训，就不做探讨
- mnesia 事务并发性太差，尽可能不必 mnesia 事务，多脏写；事务可利用过程实现，保障数据安全
- 过程
每个玩家一个过程的设计曾经成为了 erlang 游戏开发的潜规则了。这个没什么好讲，玩家过程批改本人的数据，过程音讯同步解决机制保证数据一致性。可能有些游戏还会将玩家过程和 scoket 过程独立开，负责连贯的建设和保护，协定封包解包，甚至做攻打的防备等。但如果玩家过程和 socket 过程同在一个节点内，显然整合在一个过程较好，erlang 音讯基于复制，两头多了一个过程，一次前后端交互要多了 2 次内存复制。
那么，除玩家外，其余过程怎么确定？
- 地图过程
每个玩家都是独立的过程，玩家 pk 要替换两个过程的公有数据，就要发消息给另一个过程解决。如果是强 pk 的游戏，同时有 N 个玩家一起打斗，音讯就会繁多。因为数据一致性问题，过程间的并发机制就会弱化成同步机制，减少了战斗时延。
所以，这里会引入地图过程，通常以一个地图一个过程。玩家进入地图时，会同步战斗相干数据到地图过程，玩家来到地图时，再将战斗数据同步回玩家过程。而在玩家进入地图到来到前的这段时间，所有的战斗计算都由地图过程实现。
或者有人会有纳闷，就算有了地图过程，还是有同步问题，地图过程还是要同步解决 pk 申请，无奈并发解决，玩家过程还是要期待地图过程操作实现。
其实，对于玩家的 pk 申请，解决至多有两个过程，第一个过程是验证攻打的合法性，如是否有这个技能，技能 cd，等等。第二个过程才是战斗计算，玩家过程查看合法性，再由地图过程做外围的战斗计算。另外一个，玩家 过程除了战斗申请外，还有其余业务逻辑上的音讯，容易呈现过程挂起的状况，这时候，玩家过程不可能解决到战斗计算，就会导致战斗卡顿。
2. 公共过程
公共过程指的是那些提供公共服务的过程，比方：
- 社交类，有好友、帮派、组队等，这些服务治理着少数玩家的数据，都须要一个过程来治理。
- 计算类，这类有肯定的计算量，比如说排行榜，要有一个过程来承当计算。
- 播送类，有聊天室、世界聊天、帮派聊天、地图播送等
- 开关类，有 流动零碎，较量零碎等等，管制游戏流动的开启和敞开
erlang 过程尽管便宜，然而不要太过随便创立过程，比方创立一个长期过程异步传输数据等等。尽管这在某种程度上进步了并发性，但过程的创立和销毁须要肯定的零碎耗费，而且会导致我的项目中过程数量不可控，可能零碎莫名其妙多了很多过程，这些保护起来也麻烦。再说，erlang 同时存在的过程有最大 数量限度
- 过程字典与 ets
过程字典是 erlang 游戏开发中最为罕用的数据记录形式，理由很简略，因为它够快，差不多比 ets 快了一个数量级。然而，过程字典的数据为所在过程公有，无奈跨过程间接 get 到过程字典的数据，而且，在过程被销毁时，过程字典的数据也会被回收。
再说下 ets，比照过程字典，ets 的实用场景是跨过程读写数据。遇到一个数据频繁被多个过程读到，就要思考应用 ets 了。另外，ets 有归属过程，但归属过程销毁时，ets 的数据就会被零碎回收。
比照过程字典和 ets 的实现，区别如下：
- 锁方面，过程字典为无锁操作，ets 是读写锁
- 数据方面，过程字典数据在过程中，查问没有多余的复制操作；而 ets，因为数据不在过程中，查问时会复制一份到过程。
所以，过程字典通常是最优先的抉择。如果玩家的数据是存储在 mnesia，特地是玩家的外围数据，就有必要从 mnesia 读到放在过程字典中。后面讲到了 mnesia 是利用 ets 和 dets 实现的，玩家上线时将外围数据读到过程字典，这样，读写都在过程字典，就能够利用过程字典带来的性能晋升。这个晋升是很可观，毕竟快了一个数量级。
后面提到了 ets 归属过程销毁时，ets 数据也会被回收？
那么如果预防数据失落的问题，ets 也提供了办法，通过设置继承者过程就能够了。
ets:new(person, [named_table, {heir, HeirPid, HeirData}])
当归属过程解体时，继承者过程就会收到信息 {‘ETS-TRANSFER’, Tid, FromPid, HeirData}，并且，ets 的归属权就会转交到继承者过程。
- 音讯播送
音讯播送是游戏中的性能耗费大头，次要包含地图的行走、战斗播送，世界聊天播送。世界聊天播送能够通过管制玩家发送工夫距离来限度，地图中的播送包，比方行走和战斗包的播送实时性高，只需发给视线内的玩家就能够，不必全地图播送。所以常见的解决形式是，玩家的视线通过九宫格划分，玩家的地图播送只发送给九宫格内的玩家。
如何在服务器压力大时，进一步优化播送音讯：
针对时效性高的数据包，不重要的播送包，能够选择性抛弃：
1、挂机玩家不发送战斗包，特地是战斗 buff。
2、每 N 个包抛弃一个
挂机玩家的断定，前端以玩家长时间没动作来断定，或者将游戏切到后盾运行时断定。等玩家在游戏内点击鼠标，或键盘时解除挂机状态。
这里再谈下，音讯播送还可能进一步优化。通常，后端发数据给前端都会对协定数据进行序列化（封包），而后再发给前端反序列化（解包）。而播送数据，对于每个玩家可能都是一样的，没必要每个玩家发给前端时都各自序列化一次，就只有序列化一次，而后每个玩家拿到数据后间接发给前端。
erlang 音讯播送要留神什么问题？
1、reduction 计数
通常会启动一个音讯治理过程，这个过程就负责把播送音讯转发给对应的所有玩家过程。启用治理过程的一个益处是，过程发消息会扣除 reduction，而且这个 reduction 扣除大小还受到接收者过程影响。如果间接在地图过程做音讯播送，就会导致地图过程受到的调度极度缩小，影响战斗计算。
2、音讯复制
erlang 音讯发送基于复制，但对于比拟大的二进制数据，则会优化成二进制援用，缩小二进制复制带来的开销。所以，当一个音讯要发给多个过程，特地是协定数据（发给前端也要先转成二进制），能够先转成二进制再发送。
结束语
文章到这里就完结了，这是我做 Erlang 游戏开发经验总结的一些教训，后续，我还会找工夫总结更多的开发教训。
图片起源：http://www.coubai.com/ 页游
