丨worker间通信法宝最重要数据结构之shared dict

OpenResty基于shareddict，你可以实现多个worker之间的缓存和通信，以及限流限速流量统计等功能。你可以把shareddictRedisshareddict在编写OpenRestyLua代码的过程中，你不可避免地会遇到，在一个请求的不同阶段、不同worker之间共享数据的情况，还可能需要在Lua和C代码之间共享数据。所以，在正式介绍shareddict的API之前，先让我们了解一下，OpenResty第一种是Nginx中的变量。它可以在NginxC模块之间共享数据，自然的，也可以在C模块和OpenResty提供的lua-nginx-module之间共享数据，比如下面这段代码：location/fooset$myvar'';#thislineisrequiredtocontentbyluablockngx.var.my_var= 不过，使用Nginx变量这种方式来共享数据是比较慢的，因为它涉及到hash查找和内存分配。同时，这种方法有其局限性，只能用来字符串，不能支持复杂的Lua类型。 个普通的Lua的table，所以速度很快，还可以各种Lua的对象。它的生命周期是请求级别的，当一个请求结束的时候，ngx.ctx也会跟着被销毁 个典型的使用场景，我们用ngx.ctx来缓存Nginx变量这种昂贵的调用，并在不同阶段都可以使用到它location/testrewrite_by_lua_blockngx.ctx.host=4}5accessbyluablock6if 7ngx.ctx.host= 89}{}}这时，如果你使用curl的话curl-i127.0.0.1:8080/test-H ，可以表明ngx.ctx的确是在不同子，保存table等更复杂的对象，而非简单的字符串，看看不过，这里需要特别注意的是，正因为ngx.ctx的生命周如，我在foo.lualocalngx_ctx=2localfunctionngx_ctx.host= localngx=2localfunctionngx_ctx.host= 接着往下看，第三种方法是使用模块级别的变量，在同一个worker内的所有请求之间共享数据。跟前面的Nginx变量和ngx.ctx不一样，这种方法有些不太好理解。不过别着么是模块级别的变量：--local_M=3localdata=dog=cat=pig= 9functionreturn return在nginx.conflocation/luacontent_by_lua_blocklocalmydata=require 在这个示例中，mydata就是一个模块，它只会被worker进程加载一次，之后，这个worker处理的所有请求，都会共享mydata模块的代码和数据。变量，它位于模块的toplevel，也就是模块最开始的位所以，你可以把需要在请求间共享的数据，放在模块的toplevel心了，因为可能会有racecondition，这是非常难以定位的bug。--local_M=3localdata=dog=cat=pig= 9functiondata[name]=data[name]+return return在模块中，我们增加了incrage这个函数， ngx.sleep(5)，这个sleep是一个yield操作：location/luacontent_by_lua_blocklocalmydata=requirengx.say(mydata.ngx.sleep(5)--yieldngx.say(mydata. 如果没有这行sleep代码（也可以是其他的非阻塞IO操作，比如Redis等），就不有yield操作，也就不sleep5也很可能就有其他请求调用了mydataincr_age函数，道，在实际的代码中，逻辑不会这么简单，bug所以，除非你很确定这中间没有yield操作，不会把控制权交给Nginx循环，否则，我建议你还是保持对模块级第四种，也是最后法，用shareddict来共享数据，这些数据可以在多个worker之间共享。这种方法是基于树实现的，性能很好，但也有自己的局限性——你必须事先在Nginx的配置文件中，共享内lua_shared_dictdogsshareddictLua数据类型。这也就意味着，当我需要存放table等复杂的数据类型时，我将不得不使用json或者其他的方法，来序能纳闷儿：它们看上去和shareddict没有直接关系，是不事实并非如此，你可以自己想一下，为什么OpenResty中要有shareddict的存在呢？在请求级别，或者单个worker级别。所以，在当前的OpenRestyshareddictworkerworker技术之间的差异和优势，远比你只会熟练调用它提供的API回到共享字典本身，它对外提供了20多个LuaAPI，不过所有的这些API都是原子操作，你不用担心多个worker和这些API都有详细的文档，我就不再一一赘述了。这里再强调一下，任何技术课程的学习，都不能代替对继续看shareddict的API，这些API可以分为下面三个大首先来看字典读写类。在最初的版本中，只有字典读写类的API，它们也是共享字典最常用的功能。下面是一个最简单的示例：$resty--shdict='dogs1m'-e'localdict=dict:set("Tom",除了set外，OpenResty还提供了safe_set、add、safe_add、rece这四种写入的方法。这里safe前缀的含义是，在内存占满的情况下，不根据LRU淘汰旧的数据，而是写入失败并返回nomemory的错误信息。除了get外，OpenResty还提供了get_stale的数据的方法，相比get方法，它多了一个过期数据的返回value,flags,stale=deletekeyset(key,nil)是等价的。了和Redistypedefstructngx_queue_tuint32_tuint8_tu_char}APIPR5API，在文档中并没有对应的代码示145-shdict-list.t这个文件1===TEST1:lpush&lua_shared_dictdogslocation=/testcontent_by_lua_blocklocaldogs=8locallen,err=dogs:lpush("foo",iflenngx.say("pushngx.say("pusherr:",localval,err=ngx.say(val,"",localval,err=ngx.say(val,"",localval,err=ngx.say(val,"",localval,err=ngx.say(val,"", GETpush1bar0nil最后要说的管理类API也是后续新增的，属于社区呼声比较比如，用户申请了100M的空间作为shareddict，那么这100M是否够用呢？里面存放了多少key？具体是哪些key对于这类问题，OpenResty的态度，是希望用户使用火是提供侵入式的API来直接返回结果。但站在使用者友好角度来考虑，这些管理类API还是非常有首先是get_keys(max_count?)，它默认也只返回前1024keymax_count0，那就返回所有key。 _space，这两个API都属lua-resty-corerequirerequire2localcats=localcapacity_bytes=local_page_bytes=cats:它们分别返回的，是共享内存的大小（也就是lua_shared_dict中配置的大小）和空闲页的字节数。因为shareddict是按照页来分配的，即使_space返回为0，在的项目中也有对缓存的封装。你能找出来是哪几个项吗？或者你知道一些其他缓存封装的lua-resty库吗？ 售卖。页面已增加防盗追踪，上一 17|为什么能成为更好的Web服务器？动态处理请求下一 19|OpenResty的和精髓localngx=localfunctionbar()ngx_ctx.host