进程退出信号监听通用程序
用于服务程序监听退出信号,进行优雅的退出,在退出时进行退出处理。 func WaitClose(handler func()) { defer handler() c := make(chan os.Signal, 1) signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT, syscall.SIGTERM, syscall.SIGINT)...
用于服务程序监听退出信号,进行优雅的退出,在退出时进行退出处理。 func WaitClose(handler func()) { defer handler() c := make(chan os.Signal, 1) signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT, syscall.SIGTERM, syscall.SIGINT)...
解签后需要把时间和服务器当前时间进行比较,慢与1分钟的舍弃。
描述 简单描述下问题发生的技术背景,这个问题的产生是状态同步的弊端。客户端A再马上需要同步位置信息时掉线,待客户端A重连后,服务端的位置信息已经更新了,此时客户端A在进行位置信息同步。服务端没有校验是否过期,直接同步位置信息,导致客户端表现回溯的问题。 解决方案
前言 ActorSystem属于分布式系统,分布式节点众多,如果每个节点都使用本地的配置文件,后期维护起来非常麻烦。所以希望有个统一的地点做配置中心,所有节点的配置文件都放在一起,在节点启动时访问获取。所以节点只需要配置配置中心的地址的信息即可。 节点仍然需要配置极小部分的静态信息。 节点需最小静态配置信息 [Basic] PhysicalAddress = "127.0.0.1:888...
游戏逻辑设计节点是开放给用户自己实现游戏的逻辑,而不用考虑上层房间操作以及通用的游戏逻辑操作。框架不希望限制游戏逻辑的实现思路,希望给予用户以最大的自由度。所以,游戏逻辑只会接受到来自房间的消息,怎么处理消息进行由用户自己实现,同时房间主动通知的消息都是必要消息。同时房间开发接口供游戏逻辑节点调用获取房间内信息以及用户信息。 房间会通知一下消息: 房间创建 房间销毁 用户加...
框架中的房间节点的设计的宗旨是全,做所有功能的全量,让用户自行选择使用什么功能,从而提高框架的可适配性,不会出现独特的必要的房间功能导致房间节点不可用。 首先设计的对象是通用房间接口,由通用房间结构实现这个接口。 type IGameRoom interface { Init() GetId() string GetAllUsers() []string GetAllPla...
Actor Name 地狱 为什么会有ActorName地狱呢,因为在Actor System中,万物皆为Actor,都有自己的Name。这样导致Actor Ref的发现变得非常困难。加上Actor灵活的生成销毁,Actor Name集合是不断处于变化的状态的。 一个简单粗暴的解决方案,就是把主要节点的Name写死在配置文件中。不同的ActorSystem内的节点只能通过配置文件访问到其...
消息协议设计 服务端引擎的消息协议一律使用proto协议规范设计、全部的消息可以被划分为两种类型:系统内部消息和系统外部消息。系统内部消息就是在服务端引擎内部流通的消息,系统外部消息就是客户端向网关发送的消息,网关会转发到内部服务端引擎的某个节点。总的来说,就是消息的产生方不同,系统内部消息产生与系统内部、系统外部消息产生于系统外部。 这样区分的好处:第一个是客户端能够无感的迁移到新的服务...
go的并发理念是所有共享内存的访问修改的任务都推送到通道中串行修改,而不是使用锁去保护共享资源。这样的设计理念,使得在并发运算的过程中保证资源的无锁串行访问,提高程序效率。 但是无锁意味着不存在死锁情况吗?我以前是这么认为的,知道在最近的工作上,才遇见这样的问题。我们知道就算是chan,当其中的消息满的时候,此时再往chan中推送消息,推送消息方协程会被阻塞。 假设这样的场景:现在有多个...
思想 负载均衡的算法有很多,比如轮询、随机、时间片轮转等等。这里我想介绍一个负载均衡的思想,叫哈希一致性负载均衡。哈希一致性负载均衡的决策重点在于输入的哈希值,输入会被哈希到某个服务节点上。哈希一致性的特点是下一次相同的输入到来时,仍然会被hash到同一个服务节点上,这样的好处是对于同一个用户,始终访问一个服务,该服务上的redis缓存命中的概率大大提高。 进阶用法 为什么选用哈希一致性算...