站务联系
一、棋牌类服务器的特征
1，棋牌类不分区不分服
一般来说，棋牌游戏都是不分区不分服的。所以棋牌类服务器要满足随着用户量的提高而扩充的还要。
2，房间方式
即在同一局游戏中就是在同一个书房中，同一个书房中的人可以接收至其他人的消息。
3，每个卧室的操作应当是顺/序性
这个特征类似与通常游戏的回合制，每个玩家的操作都是有顺序性的。
二、需要解决的技术点
1，数据共享
因为棋牌类游戏不分区不分服，我们在设计服务器的时侯，是按世界服的思想去设计，即服务器是一个n多台物理机的集群。当用户登录服务器，创建卧室时，可能依据负载均衡算法，它可以在任何一台服务器旁边。所以，不管用户登录至哪一台服务器里面了，都可以获得自己的数据。我们可以使用redis来做数据共享。
游戏服务器是世界服，无分区，所以用户的id应当是全局惟一的。可以借助redis的incr方式，原子的递增，如果不想被他人按照userid的递增估算出有多少注册用户，递增的梯度可以随机，比如每天递增的值从1至1024中随机一个。
1，客户端主动拉取。
客户端定时主动向服务器恳求一个用户的消息队列，当一个玩家有操作须要同步至其他玩家时，在服务器端先把这个消息传到这个用户的消息队列中。等待客户端的拉取操作。这种模式的弊端是，不需要考虑网路闪断或网路不好的状况，信息都是同步获取的。缺点是，定时拉取的时间间隔太短，可能不到1秒都会拉取一次。
2棋牌服务器租用，服务器主动推送
当一个用户出牌的消息还要同步给其他玩家时，服务器会荣获这个玩家与服务器构建的socket连结，然后服务器使用socket主动向客户端发送消息。
这种方法要考虑网路闪断，消息遗失的问题。因为服务器推送的消息，客户端有或许会收不到。所以客户端还要按照脉搏来辨别网路是否有断掉过，如果有断掉，需要再次从服务器拉取整个屋子状态的消息。或者按照服务器发送的消息号，如果客户端发觉接收至的服务器消息号有跳号的，比如应当接收10，却收到了12，说明后边有消息遗失，需要再次拉取整个屋子的状态信息。
这种模式的劣势是，开发复杂，需要考虑一些网路问题。优点是，只有在有消息的时侯就会推送，没有的话不推送，不占用时延等系统资源，可以降低用户同时在线量，也就是提高了服务器的承载量。
5，数据同步跟持久化
1，由于棋牌类的游戏数据少，计算量也小，所以完全可以不使用显存缓存，而直接使用redis共享显存，用户的所有数据都缓存在redis中。更新也同步更新至redis中，这样不管一个用户登录哪一台业务服务器，都能荣获自己的最新数据。
2，更新数据库，由于数据第一缓存是redis，所以活跃的用户数据都是可以从redis中直接荣获的，而不用查询数据库，所以数据库的更新可以采取异步更新，而不会产会数据的推迟。需要留意的一点是，数据的异步更新应当保证是有次序的。那么这都会形成一个问题，怎么保证用户的更新不会乱呢？
3，如何保证更新的顺序性
1，登陆时，客户端首先向登录的web服务器恳求登录信息，登陆成功以后，返回登录的token,为了适应大规模的web恳求跟登录服务的稳定，可以使用nginx做负载均衡。
2，登陆成功以后，请求负载均衡服务器，获取一台连结的业务服务器。这个负载均衡服务器可以跟登录web在一个进程中棋牌服务器租用，也可以独立下来。
3，拿到登录成功的token跟还要连结的业务服务器的ip跟端口以后，再去连结业务服务器。连接成功以后，要使用token至登入服务器去验证，这个用户是否登录了。
4，同一个书房的用户要连结至同一台地理服务器里面。在里面早已说过了。
5，redis拿来做共享缓存。
6，mysql做持久化储存。
7，数据库持久化服务器，统一做数据出库操作。
五、关于网段的问题
1，网关的作用
a，转发消息包
b，业务的负载均衡，比如A业务由服务器a处理，B业务由服务器b处理，由网段进行转发。
c，维护与客户端的连结
d，带宽的整合，一般的云服务都是按订购的服务器估算码率的。通过一台服务器转发消息，可以只订购一个大码率就可以了。以节省费用。
2，棋牌类游戏还要网段吗？
我觉得不太还要，因为棋牌类游戏业务比较单一，做的最多的就是消息同屏转发。最多是再有一些任务或活动，这些由一台服务器直接处理完全可以搞定。而且开发网段只是一个复杂的工作，没必要在这个里面花很多的时间。
