棋牌游戏服务端是否适合使用分布式架构

    之前开发了将近两年的棋牌游戏，都是在创业公司上班，不论前端后端都自己一个人做，怎能一个累字了的。最重要的是钱不到位^_^。

    先来说说我自己理解的分布式，我们的游戏是玩虚拟币的，分了好几种类型的玩法合在了同一个游戏。每个玩法都是在单独的一个进程中，进程之间可以通过网管或者redis的订阅、发布模式相互通讯，网关维护所有的客户端链接。多个进程玩法结合起来一起运行就构成了所谓的分布式架构。开发了一段时间也对这种模式有一定的发言权。首先说说优点。

   1）每个进程模块之负责一个玩法的实现，所以开发起来耦合低，易于维护。

    2）由于模块之间不相互依赖，所以当一个玩法出现问题的时候在没有热更新的情况下只需要关闭一个进程而不影响其他玩法的进程。

   3）如果出现某个玩法人多的情况下可以将该玩法的进程单独跑在一个服务器上，容易横向扩展。

这是我目前对分布式运用优点的理解，现在说说缺点。

    1）小型游戏，特别是这种棋牌游戏有写需求很不适合使用分布式，不是说用不了，而是开发难度大，成本高，不值得使用。

就说说我在开发中遇到的问题吧

因为是分布式架构，每个玩法一个进程，但是就有那么几个令人头疼的需求，发红包和类似彩票的需求

先说说红包功能，就是你发了一个红包，其他所有玩家不论在那个进程都能参与过来一起抢，这就有了需要进程之间同步金币的的问题，还有一个类似的问题就是彩票，它是挂在另外一些场景中作为二次玩法的。如果说红包同步量小那没什么，但是这个的同步两就有点大，比如我这某个场玩，然后又在彩票场下注，那彩票每一个玩家每下一次注都需要将金币同步到当前所在的场，这同步量就有点大了，而且分布式同步在开发中工作量大不说而且开发难度也随着增加。我在这给出的方案是用redis上的玩家数据为准，每次修改金币都先修改redis上的数据再同步到当前进程内存当中，当在彩票场下完注就用redis自带的订阅、发布方式通知其他进程将redis上的数据更新到本地。但redis并不应该存储这类经常变动的数据，而且这下注操作没一次都需要先更新redis再同步，再通知这样一来说实话最后发现性能还不如不做分布式的性能高，以为对redis操作实在是太频繁了，当然，这只是我这小菜鸡的方案，如果有大神有更好的方案还是非常愿意试试的。

    好了，就这么一个缺点就使我放弃了在那个游戏上继续使用分布式的原因，当然如果游戏没有类似红包和彩票这样的需求，用分布式还是很好的。所以最后想说的是如果游戏一开始就知道并不大或者是有类似我上面的红包、彩票功能，设计前期先别考虑什么分布式。大不了人多了之后分区分服就可以。谢谢板砖。