C和lua互操作实践

Tue, 22 Aug 2023 10:51:43 +0800

相信了解 redis 和 openresty 的小伙伴们都知道 lua 代码可以嵌入这两种程序中运行，极大的提高了软件的扩展性；尤其是 openresty 中，通过使用 lua 我们可以很快速（相比c）的定制web服务器，或者增强 nginx 的功能。那么 lua 是如何嵌入到这些程序中的呢？lua 和 c 是如何互操作的呢？

下文的相关环境和工具版本为：Lua 5.4.6; Mac OS 13.4.1 (Darwin Kernel Version 22.5.0) arm64 M2 pro; Apple clang version 14.0.3 (clang-1403.0.22.14.1)

redis 中的 lua#

下面展示了一段 redis 中操作 lua API 的代码：

这里出现了很多 lua_ 开头的函数，这些函数都是 lua 库中的函数，redis 通过这些函数来操作 lua 环境，这里先不展开讲，后面会详细介绍。

更多的代码，如 luaRegisterRedisAPI 就不展示了，有兴趣的可以去看源码。

// redis-v7.2/src/eval.c#183

/* 初始化 lua 环境
 *
 * redis 首次启动时调用，此时 setup 为 1,
 * 这个函数也会在 redis 的其他生命周期中被调用，此时 setup 为 0，但是被简化为 scriptingReset 调用。
 */ 
void scriptingInit(int setup) {
    lua_State *lua = lua_open();

    if (setup) {
        // 首次启动时，初始化 lua 环境 和 ldb (Lua debugger) 的一些数据结构
        lctx.lua_client = NULL;
        server.script_disable_deny_script = 0;
        ldbInit();
    }

    /* 初始化 lua 脚本字典，用于存储 sha1 -> lua 脚本的映射
     * 用户使用 EVALSHA 命令时，从这个字典中查找对应的 lua 脚本。
     */
    lctx.lua_scripts = dictCreate(&shaScriptObjectDictType);
    lctx.lua_scripts_mem = 0;

    /* 注册 redis 的一些 api 到 lua 环境中 */
    luaRegisterRedisAPI(lua);

    /* 注册调试命令 */
    lua_getglobal(lua,"redis");

    /* redis.breakpoint */
    lua_pushstring(lua,"breakpoint");
    lua_pushcfunction(lua,luaRedisBreakpointCommand);
    lua_settable(lua, -3);
    /* redis.debug */
    lua_pushstring(lua,"debug");
    lua_pushcfunction(lua,luaRedisDebugCommand);
    lua_settable(lua,-3);
    /* redis.replicate_commands */
    lua_pushstring(lua, "replicate_commands");
    lua_pushcfunction(lua, luaRedisReplicateCommandsCommand);
    lua_settable(lua, -3);

    lua_setglobal(lua,"redis");

    /* 注册一个错误处理函数，用于在 lua 脚本执行出错时，打印出错信息。
     * 需要注意的是，当错误发生在 C 函数中时，我们需要打印出错的 lua 脚本的信息，
     * 这样才能帮助用户调试 lua 脚本。
     */
    {
        char *errh_func =       "local dbg = debug\n"
                                "debug = nil\n"
                                "function __redis__err__handler(err)\n"
                                "  local i = dbg.getinfo(2,'nSl')\n"
                                "  if i and i.what == 'C' then\n"
                                "    i = dbg.getinfo(3,'nSl')\n"
                                "  end\n"
                                "  if type(err) ~= 'table' then\n"
                                "    err = {err='ERR ' .. tostring(err)}"
                                "  end"
                                "  if i then\n"
                                "    err['source'] = i.source\n"
                                "    err['line'] = i.currentline\n"
                                "  end"
                                "  return err\n"
                                "end\n";
        luaL_loadbuffer(lua,errh_func,strlen(errh_func),"@err_handler_def");
        lua_pcall(lua,0,0,0);
    }

    /* 创建一个 lua client (没有网络连接)，用于在 lua 环境中执行 redis 命令。
     * 这个客户端没必要在 scriptingReset() 调用时重新创建。
     */
    if (lctx.lua_client == NULL) {
        lctx.lua_client = createClient(NULL);
        lctx.lua_client->flags |= CLIENT_SCRIPT;

        /* We do not want to allow blocking commands inside Lua */
        lctx.lua_client->flags |= CLIENT_DENY_BLOCKING;
    }

    /* Lock the global table from any changes */
    lua_pushvalue(lua, LUA_GLOBALSINDEX);
    luaSetErrorMetatable(lua);
    /* Recursively lock all tables that can be reached from the global table */
    luaSetTableProtectionRecursively(lua);
    lua_pop(lua, 1);

    lctx.lua = lua;
}

通过这部分代码，应该对于 lua 的嵌入式使用有了一个大概的印象。这里可以回答以下的问题：

Redis主从复制

Sun, 29 Mar 2020 09:45:19 +0800

redis主从复制是高可用方案中的一部分，那主从复制是如何进行的？又是如何实现的？怎么支撑了redis的高可用性？在主从模式下Master和Slave节点分别做了哪些事情？

redis高可用方案是什么？#

我理解的redis高可用的特点有：

高QPS，主从 => 读写分离
高容量，集群分片 => 高容量
故障转移，sentinel => 故障转移
故障恢复，数据持久 => 故障恢复～这里我简单的理解（RDB + AOF）= 故障恢复

主从复制#

redis 主从复制有两个版本：旧版（Ver2.8-），新版（Ver2.8+，增加PSYNC命令来解决旧版中的问题）

讨论复制时都需要考虑两种场景：

场景1：从节点刚刚上线，需要去同步主节点时，这部分可以理解为 全量复制。
场景2：从节点掉线，恢复上线后需要同步数据，使自己和主节点达到一致状态。这部分在旧版复制里等价于全量复制，在新版里可以理解为增量复制。

当然你肯定会想到如果主节点掉线，这时候会怎么样？这个场景当然也在redis高可用方案中，之时不是本文的重点，属于Sentinel机制的内容了。

旧版主从复制#

前文说过了，旧版主从复制只有全量复制用于应付上述两个场景，因此下面的流程也只有一份：

从服务器向主服务器发送sync命令。
主服务器在收到sync命令之后，调用bgsave命令生成最新的rdb文件，将这个文件同步给从服务器，这样从服务器载入这个rdb文件之后，状态就会和主服务器执行bgsave命令时候的一致。
主服务器将保存在命令缓冲区中的写命令同步给从服务器，从服务器执行这些命令，这样从服务器的状态就跟主服务器当前状态一致了。

如果你不知道redis中还有个缓冲区的话，建议系统的了解下redis中缓冲区的设计。这里缓冲区特指命令缓冲区，后面还会讲到复制缓冲区。

但是这样的实现在 场景2 下的缺点很明显：如果说从节点断线后迅速上线，这段时间内的产生的写命令很少，却要全量复制主库的数据，传输了大量重复数据。

SYNC命令产生的消耗：
1. 主节点生成RDB，需要消耗大量的CPU，内存和磁盘IO
2. 网络传输大量字节数据，需要消耗主从服务器的网络资源
3. 从节点需要从RDB文件恢复，会造成阻塞无法接受客户端请求

优点就是：简单暴力。个人看来在redis架构中不合适的用法，不代表说实际场景中也一定不合适，简单暴力也是一个很大的优点。

新版主从复制#

新版的主从复制跟旧版的区别就在于：对场景2的优化。

场景2的缺点上文已经提到过了，那么优化的方向就是**“尽量不使用全量复制；增加增量复制(PSYNC)的功能”**。为此还要解决下列问题：

如果某个从节点断线了，重新上线该从节点如何知道自己是否应该全量还是增量复制呢？
该从节点断线恢复后，又怎么知道自己缺失了哪些数据呢？
主节点又如何补偿该从节点在断线期间丢失的那部分数据呢？旧版的复制除了RDB，还有从命令缓冲区中的写命令来保持数据一致。

为此新版中使用了以下概念：

运行ID - runid#

每个redis服务器都有其runid，runid由服务器在启动时自动生成，主服务器会将自己的runid发送给从服务器，而从服务器会将主服务器的runid保存起来。从服务器redis断线重连之后进行同步时，就是根据runid来判断同步的进度：

如果前后两次主服务器runid一致，则认为这一次断线重连还是之前复制的主服务器，主服务器可以继续尝试部分同步操作。
如果前后两次主服务器runid不相同，则全同步流程。

复制偏移量 - offset#

主从节点，分别会维护一个复制偏移量：主服务器每次向从服务器同步了N字节数据之后，将修改自己的复制偏移量+N。从服务器每次从主服务器同步了N字节数据之后，将修改自己的复制偏移量+N。通过对比主从节点的偏移量很容易就可以发现，主从节点是否处于一致状态。

复制（积压）缓冲区 - copybuffer#

一个固定长度（可配置）的FIFO队列，默认大小 = 1MB；预测值 = second * write_size_per_second。当从节点重新连上主节点时候，从节点会通过PSYNC命令将自己的复制偏移量（offset）发送给主服务器，主节点会根据偏移量会判断该执行何种同步：

Redis on Yeqown