本文主要参考&转载：skynet源码赏析
本文旨在记录我对skynet重新学习和理解的过程，也便于以后回顾（本文纯手打，输出的过程也是记忆的过程）。
1. skynet初衷
希望游戏服务器能充分利用多核优势，将不同的业务放在独立的环境中执行处理，协同工作。这个执行环境通过lua的虚拟机实现，能有效隔离不同的执行环境。而多线程模式使得状态共享，数据交换更加高效。
2. 概述
作为核心功能，skynet仅解决一个问题：
把一个符合规范的c模块，从动态库（so文件）中启动起来，绑定一个永不重复的数字id作为其handle。模块被称为服务，服务间可以自由的发送消息，每个模块可以向skynet框架注册一个callback函数，用来接收发给它的消息。
每个服务都是被一个个消息包驱动的，当没有包到来的时候，它们就会处于挂起状态。对CPU的资源零消耗。如果需要自主逻辑，则利用skynet系统提供的timeout消息，定期触发。
具体地，skynet为我们提供了这样的环境：
-
将符合规范的c文件模块编译成so库后，在某个时机调用so库的api的句柄，将其加载到modules列表中，一般这样的模块被要求定义4种接口：create、init、signal、release。
-
当我们要创建一个新的、运行某个业务逻辑的上下文时，从modules列表中找到对应so库的句柄，并且调用create接口，创建一个该业务模块的数据实例，并且创建一个上下文环境（context），引用该类业务的接口和数据实例，该context会被放在一个统一存放context的列表中，这种context被称为服务。
-
一个服务，默认不会执行任何逻辑，只有别人向它发出请求时，才会执行对应的逻辑，并在需要时返回结果给请求者。服务间的请求、响应和推送通过消息队列转发到另一个服务中。skynet的消息队列，分为两级，一个全局消息队列，他包含一个头尾指针，分别指向两个隶属于指定服务的次级消息队列。skynet中的每一个服务，都有一个唯一的、专属的次级消息队列。
-
skynet一共有4种线程，monitor线程用于检测节点内的消息是否堵住，timer线程运行定时器，socket线程用于进行网络数据的收发，worker线程负责对消息队列进行调度（worker线程的数量可以通过配置表进行指定）。
-
消息调度的规则是：每条worker线程，每次从全局消息队列中pop出一个次级消息队列，再从次级消息队列中pop出一条消息，并找到该次级消息队列的所属服务，将消息传递给该服务的callback函数，执行指定业务，当逻辑执行完毕时，再将次级消息队列push回全局消息队列中。因为每个服务只有一个次级消息队列，每当一条worker线程，从全局消息队列中pop出一个次级消息队列时，其他线程是拿不到同一个服务，并调用callback函数的，因此不用担心一个服务同时在多条线程内消费不同的消息，一个服务执行，不存在并发，线程是安全的。
-
socket线程、time线程以及worker线程都可能往指定服务的次级消息队列push消息，push函数有一个自旋锁，避免同时多条线程同时向一个次级消息队列push消息的情况出现。
skynet的机制可以用一张表来概括：
注意：服务模块要将数据，通过socket发送给客户端时，并不是将数据写入消息队列，而是通过管道从work线程发送给socket线程，交由socket转发。此外，设置定时器也不走消息队列，而是直接在定时器模块，加入一个time_node。因为time和socket线程内运行的模块并不是这里的context，因此消息队列它们无法消费。
上面的论述只涉及到c服务模块，并未讨论lua服务的内容，我们所有的 lua服务均是依附于一个叫snlua的c模块来运行的，lua服务每次收到一个消息就会产生一个协程（事实上，skynet每个服务均有一个协程池，lua服务收到消息时，会优先去池子里取出一个协程，为了理解方便，就视为收到一个消息就创建一个协程）
3. 目录结构
- 3rd：存放第三方代码，提供lua语言支持、jemalloc内存管理、md5加密等
- skynet-src：包括skynet最核心机制的模块，包括逻辑入口、加载c服务代码的skynet_module模块、运行和管理服务实例的skynet_context模块、skynet消息队列、定时器和socket模块等。
- service-src：依附于skynet核心模块的c服务，如用于日志输出的logger服务，用于运行lua脚本的snlua服务。
- lualib-src：提供c层级的api调用，如调用socket模块的api，调用skynet消息发送，注册回调函数的api，甚至是对c服务的调用等，并导出lua接口，供lua层使用。可以视为lua调c的媒介。
- service：lua服务，依附于snlua这个c服务，这个目录包含skynet lua层级的一些基本服务，比如启动lua层级服务的bootstrap服务，gate服务，供lua层创建新服务的launcher服务deng。
- lualib：包含对一些c模块或lua模块调用的辅助函数，总之，这些lualib方便应用层调用skynet提供的基本服务和其他库。
上面的服务基本遵循一个原则，就是上层允许调用下层，而下层不能直接调用上层的api，这样做层次清晰，不会出现你中有我，我中有你的高度耦合的情况存在。c层和lua层的耦合模块则是包含在lualib-src中，这种模块划分更利于我们快速寻找对应模块。
4. 基本数据结构
- modules管理模块
c服务在编译成so库以后，会在某个时机被加载到modules列表中，当要创建该服务的实例时，从modules列表中取出该服务的函数句柄，调用create函数创建服务实例，并且init之后，将实例值赋给一个新的context对象，注册到skynet_context
///skynet-src/skynet_module.h
typedef void * (*skynet_dl_create)(void);
typedef int (*skynet_dl_init)(void * inst, struct skynet_context *, const char * parm);
typedef void (*skynet_dl_release)(void * inst);
typedef void (*skynet_dl_signal)(void * inst, int signal);
struct skynet_module {
const char * name; //c服务名称，一般是c服务的文件名
void * module; //访问该so库的dl(Dynamic Linking)句柄，该句柄通过dlopen函数获得
skynet_dl_create create; //绑定so库中的xxx_create函数，通过dlsy函数实现绑定，调用该create即是调用xxx_create
skynet_dl_init init; //绑定so库中的xxx_init函数，调用该init即是调用xxx_init
skynet_dl_release release; //绑定so库中的xxx_release函数，调用该release即是调用xxx_release
skynet_dl_signal signal; //绑定so库中的xxx_signal函数，调用该signal即是调用xxx_signal
};
//skynet-src/skynet_module.c
#define MAX_MODULE_TYPE 32
struct modules {
int count; //modules的数量
struct spinlock lock; //自旋锁，避免多个线程同时向skynet_module写入数据，保证线程安全
const char * path; //由skynet配置表中的cpath指定，一般包含./cservice/?.so
struct skynet_module m[MAX_MODULE_TYPE];
};
static struct modules * M = NULL; //存放服务模块的数组，最多32类
从上面的数据可以看出，一个符合规范的c服务，应当包括create、init、release、signal四个接口，在该c服务被编译成so库以后，在程序中动态加载到skynet_module列表，这里通过dlopen函数来获取so库的访问句柄，并通过dlsym将so库中对应的函数绑定到函数指针中。
这里举一个例子方便理解dlopen函数和dlsym函数:
#include <stdio.h>
#include <dlfcn.h>
int main() {
void* handle;
handle = dlopen("./libexample.so", RTLD_LAZY); // 将so文件加载到内存，返回dl句柄
if (handle == NULL) {
fprintf(stderr, "Unable to open library: %s\n", dlerror());
return 1;
}
// 使用dlsym函数。指定句柄和函数名，获取so库中的函数指针
void (*hello)() = dlsym(handle, "hello");
if (hello == NULL) {
fprintf(stderr, "Unable to load symbol: %s\n", dlerror());
dlclose(handle);
return 1;
}
// 调用so库中的函数
hello();
// 关闭dl句柄
dlclose(handle);
return 0;
}
当要创建module的实例时，从modules的skynet_module数组中取出模块，调用create函数创建实例，然后将实例指针传入init函数完成初始化，赋值给context。
- skynet_context管理模块
创建一个新的服务，首先要找到服务对应的module，在创建完module实例并完成初始化以后，还需要创建一个skynet_context上下文，并将module实例和这个context关联起来，最后放置于skynet_context 列表中，一个个独立的沙盒环境就这样被创建出来了，下面来看看主要的数据结构：
// skynet-src/skynet_server.c
struct skynet_context {
void * instance; // 由指定module的create函数，创建的数据实例指针，同一类服务可能有多个实例，因此每个服务都应该有自己的数据
struct skynet_module * mod; // 引用服务module的指针，方便后面对create、init、release和signal函数进行调用
void * cb_ud; // 调用callback函数时，回传给callback的userdata，一般是instance指针
skynet_cb cb; // 服务的消息回调函数，一般在skynet_module的init函数里指定
struct message_queue *queue; // 服务专属的次级消息队列指针
ATOM_POINTER logfile; // 日志句柄
uint64_t cpu_cost; // in microsec
uint64_t cpu_start; // in microsec
char result[32]; // 操作skynet_context的返回值，会写到这里
uint32_t handle; // 标识唯一context的服务id
int session_id; // 发出请求后，收到对方返回的消息时，通过session_id来匹配一个返回，对应哪个请求
ATOM_INT ref; // 引用计数变量，当为0时，表示内存可以释放
int message_count;
bool init; // 是否完成初始化
bool endless; // 是否堵住
bool profile;
CHECKCALLING_DECL
};
// skynet-src/skynet_handle.c
// 这个结构用于记录服务对应的别名，当应用层为某个服务命名时，会写到这里来
struct handle_name {
char * name; // 服务别名
uint32_t handle; // 服务id
};
struct handle_storage {
struct rwlock lock; // 读写锁
uint32_t harbor; // harbor id
uint32_t handle_index; // 创建下一个服务时，该服务的slot idx，一般会先判断该slot是否被占用
int slot_size;
struct skynet_context ** slot; // skynet_context list
int name_cap; // 别名列表大小，大小为2^n
int name_count; // 别名数量
struct handle_name *name; // 别名列表
};
static struct handle_storage *H = NULL;创建一个新的skynet_context时，会往slot列表中放，当一个消息送达context时，其callback函数就会被调用，callback函数一般在module的init函数里指定，调用callback函数时，会传入userdata（一般是instance指针）、source（发送方的服务id）、type（消息类型）、msg和sz（数据及其大小），每个服务的callback处理各自的逻辑。这里其实可以将modules视为工厂，而skynet_context则是该工厂创建出来的实例，而这些实例则是通过handle_storage来进行管理。
- 消息与消息队列
服务通过消息来驱动，服务的消息从消息队列取出。skynet包含两级消息队列，一个globa_mq，他包含一个head和tail指针，分别指向队列头部和尾部；还有次级消息队列，是单向链表的形式。消息的派发机制是，工作线程从gloab_mq里pop出一个次级消息队列，再从次级消息队列中pop出一个消息，并传给context的callback函数，在完成驱动以后，再将次级消息队列push回global_mq中，数据结构如下所示：
// skynet_mq.h
struct skynet_message {
uint32_t source; //消息发送方的服务地址
// 如果这是一个回应消息，那么要通过session找回对应的一次请求，在lua层，我们每次调用call的时候
// 都会往对方的消息队列中，铺设一个消息，并且生成一个session，然后将本地的协程挂起，挂起时，会
// 以session为可以，协程的句柄为值，放入一个table中，当回应消息送达时，通过session找到对应的协程，并将其唤醒
int session;
void * data; // 消息地址
size_t sz; // 消息大小
};
// skynet_mq.c
#define DEFAULT_QUEUE_SIZE 64
#define MAX_GLOBAL_MQ 0x10000
// 0 means mq is not in global mq.
// 1 means mq is in global mq , or the message is dispatching.
#define MQ_IN_GLOBAL 1
#define MQ_OVERLOAD 1024
struct message_queue {
struct spinlock lock; // 自旋锁，可能存在多个线程向同一个队列写入的情况，加上自旋锁避免
uint32_t handle; // 拥有此消息队列的服务的id
int cap; // 消息大小
int head; // 头部index
int tail; // 尾部index
int release; // 是否能释放消息
int in_global; // 是否在全局消息队列中，0表示不是，1表示是
int overload; // 是否过载
int overload_threshold;
struct skynet_message *queue; // 消息队列
struct message_queue *next; // 下一个消息队列的指针
};
struct global_queue {
struct message_queue *head;
struct message_queue *tail;
struct spinlock lock;
};
static struct global_queue *Q = NULL;如何传递消息呢？我们要向一个服务发送消息，最终是通过调用skynet.send接口，将消息插入到该服务专属的次级消息队列，次级消息队列的内容并不是context结构的一部分（context只是引用了他的指针），因此，在一个服务执行callback的同时，其他服务可以向它的消息队列里面push消息，而mq的push操作是加了一个自旋锁的，避免多个线程同时操作一个消息队列。lua层的skynet.send接口，最终会调到c层的skynet_context_push。这个接口实质上是通过handle将context指针取出，然后再往消息队列里push消息。
// skynet_server.c
int
skynet_context_push(uint32_t handle, struct skynet_message *message) {
struct skynet_context * ctx = skynet_handle_grab(handle);
if (ctx == NULL) {
return -1;
}
skynet_mq_push(ctx->queue, message);
skynet_context_release(ctx);
return 0;
}
// skynet_handle.c
struct skynet_context *
skynet_handle_grab(uint32_t handle) {
struct handle_storage *s = H;
struct skynet_context * result = NULL;
rwlock_rlock(&s->lock);
uint32_t hash = handle & (s->slot_size-1);
struct skynet_context * ctx = s->slot[hash];
if (ctx && skynet_context_handle(ctx) == handle) {
result = ctx;
skynet_context_grab(result);
}
rwlock_runlock(&s->lock);
return result;
}在通过handle获取context指针时，加入了一个读锁，这样当在读取的过程中，如果有新服务创建，就存在要扩充skynet_context list的风险，因此不论如何，它都应当被阻塞住，直到所有的读锁都被释放掉。
次级消息队列实际上是一个数组，并且用两个int型数据，分别指向它的头部和尾部，当这两个值>=数组尺寸时，都会进行回绕（即从下标为0开始，比如值为数组的size时，会被重新赋值为0），在push操作后，head等于tail意味着队列已满（此时，队列会扩充两倍，并从头到尾重新赋值，此时head指向0，而tail为扩充前，数组的大小），在pop操作后，head等于tail意味着队列已经空了（后面他会从skynet全局消息队列中，被剔除掉）。
1766
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
