月份：2021年12月

Go游戏服务器热更新 1.为什么需要做代码热更新? 什么是代码热更新 所谓代码热更一般是指服务程序在不停止服务运行的情况下动态替换其中部分代码对原有逻辑进行修正或者新增功能代码。 为什么需要代码热更新 服务程序一般需要为应用程序提供长时间724小时不间断的服务。 不停止服务程序的运行的情况下动态修改程序的行为逻辑。 游戏服务器频繁停服维护非常不友好。* 2.游戏服务器热更主流解决方案? 代码热更的基本原理 我们可以用一个公式来简单概括服务程序。服务程序=数据结构(数据管理)+算法(这里说的算法指代程序中对于数据的计算处理相关的部分)。大部分时候代码热更新只能热更算法的部分,数据部分是非常难热更的或者说不建议热更的。举个例子: [crayon-6745dfc56bd1b042255183/] 上述代码可以进行热更的部分是ChangeGameData方法。试想一下如果修改了GameData数据结构,删除了D字段新增了E字段,那么此时数据结构与程序内存中的GameData对象的内存结构是不匹配的,那么对于字段的操作也不能达到预想的效果。到这里我们热更的目标很明确了，就是如何能够动态的替换掉ChangeGameData这类的对于数据的计算的函数？ 代码热更方案: 基本原理 动态库替换 编译型语言+(运行时编译器(luajit/cpython)+动态解析内嵌脚本) 实践方案 c/c++动态库(.so或者.dll)替换 c/c++内嵌lua c/c++内嵌python node.js golang+plugin 3.Go游戏服务器如何做热更新 前面实践方案中已经剧透了Go语言中实现代码热更新的方式是采用plugin包加载动态库的方式。go编译器支持将一个go程序编译成一个插件(plugin)。plugin的基本原理类似于c/c++加载动态库的方式。 插件程序构建 程序目录结构 [crayon-6745dfc56bd20845239001/] 代码解析-插件代码(plugintest/plugin/main.go) [crayon-6745dfc56bd23080871209/] 代码解析-宿主程序代码(plugintest/main.go) [crayon-6745dfc56bd24275145546/] 编译-plugin编译 ...

游戏中需要使用唯一ID的场景 游戏场景唯一id 场景中的实体的唯一id(NPC、Monster、Building、Resource...) 业务系统中的唯一实体的id 唯一ID的实现方式 字符串唯一ID 数字唯一ID 如何设计一个全局唯一的数字id 使用数字做全局唯一id面临的问题 最大使用uint64位整数做唯一id 如何是分布式系统中各个服务(程序)创建全局唯一id 如何尽可能的使唯一id生成器使用足够长的时间 uint64位整数如何做到全局唯一？ 要想在分布式系统做做到唯一id，那么意味着这个唯一id中已经包含/表达了足够区分各个系统(服务)的信息，那么如何在一个只有64bits的数字中包含这些信息呢？ 第一步考虑就是需要在id中包含一个机器码(服务的唯一id)以此来区分不同的服务实例. 如何保证高并发环境下各个服务实例同时创建的id的唯一性. 如何保证同一个实例高并发环境下唯一id的生成. 基于Sonyflake改造后的idgenerator 想要了解如何使用一个数字去做到全局唯一首先需要了解一些雪花算法Snowflake，这是Twitter公司提出来的算法。因为Snowflake的灵活性和缺点，比如索尼的Sonyflake等等。我们这里也是基于这个算法进行改造。 我们先看下原生的Snowflake算法，原生Snowflake算法使用一个64 bit的整型数据，根据当前的时间来生成ID。 原生Snowflake结构如下： 因为最高位是标识位，为1表示为负数，所以最高位不使用。 41bit 保存时间戳，精确到毫秒。也就是说最大可使用的年限是69年。 10bit 的机器位，能部属在1024台机器节点来生成ID。 12bit 的序列号，一毫秒最大生成唯一ID的数量为4096个。 Sonyflake是基于上面的snowflake改造的，变更了时间、机器码、序列号的位数，snoyflake的结构图如下: 下面来看看我们基于Sonyflake改造后设计实现的idgenerator的基本结构说明: 36bit 保存以10ms为时间单位的时间戳，最大可使用的年限是21年。 13bit 的机器位，能部属8192个节点来生成ID。 14bit 的序列号，10毫秒最大生成唯一ID的数量为16384个。 根据上面的结构我们可以看出来我们调整了时间、机器码、序列号的位数,下面我们来分析一下这么调整的原因。 时间位36bit 首先我们看下36bit能够表达的数最大值是1...