一种超简洁的分布式无状态的服务器架构（一）

笔者最近在做一款社交类的数值养成游戏，产品的要求是大通服，玩家进游戏时无需选择区服，要求所有玩家在一起游戏，所以需要做分布式的服务器架构，然后分布式的做法有多种：

1种是用hash一致性的actor模式，从网关到游戏服，后面负载均衡的时候，加减节点会导致线程发生切换，但是如何保证在切换路径的同时保证数据的一致性？再者actor模式通讯不够直接，太绕了，后面写交互的时候会有点麻烦。

2种是采用分布式锁的方式来修改数据，如果同时需要修改多个玩家的数据，可以做锁排序，但是这种方式，一定要特别注意，可能会死锁，还要做好死锁检查解锁，如果需要用到数据缓存的话，就更麻烦了，只要数据变了就要做缓存同步，就像CPU的多核多级缓存机制一样，光是做缓存同步就是巨大的工程, 也就是说要做到分布式缓存同步，就需要做一套类似多核多级缓存CPU的机制，目前已有几种开源分布式一致性协议, 比较著名的有Raft，Gossip，如果需要考虑多级缓存同步还需要配合通用缓存一致性协议MESI，github上几年前都有人开始做这种技术了，因为过于复杂，据笔者了解没有项目能真正做到这个技术。

综合比较两种方案，笔者顺其自然地就想到了无状态服务器，就是 服务器不缓存玩家数据，所有的请求都直接操作数据库，笔者分析了一下该游戏的玩法特点，几乎所有的游戏行为都是玩家做一种操作，游戏服务器给以反馈，没有实时性的数据同步，对数据库的压力相对较小，再者现在的数据库得益于硬件和多线程技术的发展在并发性能已经有了很大的的提升，然后跟几个业界大佬朋友交流了，得知有的SLG都用的无状态，所以理论上应该没有什么问题，于是决定把服务器做成无状态的，首要任务是需要选择一个对分布式支持地比较好的数据库，经过对比，最终选择了mongodb 做为数据库，数据库本身自带热点数据缓存，默认好像是总存储量的60%，也就是说无限堆内存就可以解决缓存命中率的问题，对于一个想快速成型的产品无疑是最快的方式，如果后期数据量级起来了，可以无缝做分片集群，然后再选择一个分布式的高速缓存，当然选择了redis，redis有较强的性能，后期也是可以分片，所以应该没有什么问题，于是初步的方案就是这样，如下图所示：