[lua]如何设计个完全内置的简单数据管理

zoom.quiet · 2012-03-15T10:11:43+00:00

On Tue, Mar 13, 2012 at 11:31 PM, Zoom.Quiet <zoom...@gmail.com> wrote: 在 2012年3月13日下午11:15，smallfish...

[lua]如何设计个完全内置的简单数据管理

zoom.quiet

需求:
- 仅仅使用 openresty + lua 脚本,完成简单的 RESTful 接口服务
- 涉及用户简单的值对型文本数据的服务端存储
  - 不想引入其它 db 产品
  - 使用纯文本也可以
问题:
- 如何解决好阻塞 I/O 和 openresty 的非阻塞运行形式?

思考:
- ngx.shared.DICT 已经足够
  - 而且跨进程共享
  - 是否可以拿来使用运行期数据字典
  - 定期,或是异步每次有修改后, dump 到服务端?
    - 启动时,自动加载一次就好?
...

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

agentzh

On Thu, Mar 15, 2012 at 10:11 AM, Zoom.Quiet <zoom...@gmail.com> wrote:

需求:
- 仅仅使用 openresty + lua 脚本,完成简单的 RESTful 接口服务
- 涉及用户简单的值对型文本数据的服务端存储
- 不想引入其它 db 产品
- 使用纯文本也可以
问题:
- 如何解决好阻塞 I/O 和 openresty 的非阻塞运行形式?

一般来说，对于 ngx_lua，文件 I/O 多是阻塞的（除非启用 aio），而网络 I/O 只要是走 nginx upstream 模块 + nginx 子请求，或者走 ngx_lua cosocket API，则都是非阻塞的。

思考:
- ngx.shared.DICT 已经足够
- 而且跨进程共享
- 是否可以拿来使用运行期数据字典
- 定期,或是异步每次有修改后, dump 到服务端?
- 启动时,自动加载一次就好?

ngx_lua 的共享内存字典本身没有提供持久化支持。你需要自己在 Lua 层面去设计和实现持久化策略了，可选择的策略有很多。

Regards,
-agentzh

lhmwzy

这样说了，用lua-resty-upload上传文件，写到本地文件中，那么写文件的过程也是阻塞的了？

agentzh

On Thu, Mar 15, 2012 at 2:28 PM, lhmwzy <lh...@gmail.com> wrote:

这样说了，用lua-resty-upload上传文件，写到本地文件中，那么写文件的过程也是阻塞的了？

是的，包括第三方的 ngx_upload 模块还有 nginx 请求头的自动磁盘缓存，还有 Nginx 的各种日志服务无一例外都会阻塞。所以这里重要的是让磁盘 I/O 与网络 I/O 尽可能地交叠起来，比如从网络上读一块数据，就向磁盘写一块数据，把对 nginx 的阻塞效率降到最低。

磁盘 I/O 相比网络 I/O 总是比较让人头疼的，至少对于 Linux 系统而言 :)

Regards,
-agentzh

zoom.quiet

在 2012年3月15日 下午2:23，agentzh <age...@gmail.com> 写道：
> On Thu, Mar 15, 2012 at 10:11 AM, Zoom.Quiet <zoom...@gmail.com> wrote:
>>
>> 需求:
>> - 仅仅使用 openresty + lua 脚本,完成简单的 RESTful 接口服务
>> - 涉及用户简单的值对型文本数据的服务端存储
>>  - 不想引入其它 db 产品
>>  - 使用纯文本也可以
>> 问题:
>> - 如何解决好阻塞 I/O 和 openresty 的非阻塞运行形式?
>>
>
> 一般来说，对于 ngx_lua，文件 I/O 多是阻塞的（除非启用 aio），而网络 I/O 只要是走 nginx upstream 模块 +
> nginx 子请求，或者走 ngx_lua cosocket API，则都是非阻塞的。
>
>>
>> 思考:
>> - ngx.shared.DICT 已经足够
>>  - 而且跨进程共享
>>  - 是否可以拿来使用运行期数据字典
>>  - 定期,或是异步每次有修改后, dump 到服务端?
>>    - 启动时,自动加载一次就好?
>
>
> ngx_lua 的共享内存字典本身没有提供持久化支持。你需要自己在 Lua 层面去设计和实现持久化策略了，可选择的策略有很多。
>

是也乎,是也乎,这两周发觉俺平时对一些基础概念并没有精确把握住,
所以,面对问题时,经常想差,
建议 agentzh 在系列教程中也增补类似参考吼,
现在感觉到容易纠结在一起的概念(先尝试白话一下):
- 阻塞式 I/O
  - 凡是对当前进程/线程之外的资源进行沟通,都是 I/O 不论网络/硬盘/内存,,,
  - 栈式逐一等待完成的 I/O
- 非阻塞式 I/O
  - 协程或是其它技术进行 非等待的 I/O 并行处理
- 请求的同步响应
  - 应用对请求引发的所有行动,进行排队,逐一完成
- 请求的异步响应
  - 应用能随时完好的挂起请求,进行并发处理
- 过程式同步代码
  - 代码形式上,是顺序描述所有行动的
- 回调式异步代码
  - 代码形式上,对行动可以进行条件回調
  - 执行結果不一定各形式上的顺序

目前 openresty 的亮点,针对以上概念是:
- 内置多种非阻塞式网络I/O 模型
- 通过 Lua 进行业务描述时,形式是同步的,但是通过 Nginx 的内置机制配合
  - 实际可以是异步的

以上!?


> Regards,
> -agentzh


--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

zoom.quiet

在 2012年3月15日 下午2:39，agentzh <age...@gmail.com> 写道：
> On Thu, Mar 15, 2012 at 2:28 PM, lhmwzy <lh...@gmail.com> wrote:
>>
>> 这样说了，用lua-resty-upload上传文件，写到本地文件中，那么写文件的过程也是阻塞的了？
> 是的，包括第三方的 ngx_upload 模块还有 nginx 请求头的自动磁盘缓存，还有 Nginx
> 的各种日志服务无一例外都会阻塞。所以这里重要的是让磁盘 I/O 与网络 I/O 尽可能地交叠起来，比如从网络上读一块数据，就向磁盘写一块数据，把对
> nginx 的阻塞效率降到最低。
>
> 磁盘 I/O 相比网络 I/O 总是比较让人头疼的，至少对于 Linux 系统而言 :)
>
- 这样的话,使用 redis 作为中间缓存?
- 对硬盘的 I/O 由 redis 的策略进行自动化控制
- 而 nginx 对网络和本地的 I/O 就全部在内存中了
  - 虽然比 CPU 缓存的速度慢太多
  - 但是,这么来,比硬盘寻道速度要高太多了,,,
- 这里就有个 Lua 数据类型怎么透明的到 redis 的问题了,,
  - 而且得是双向的
  - 以便重启也能良好恢复所有热数据


> Regards,
> -agentzh

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/

agentzh

On Thu, Mar 15, 2012 at 2:44 PM, Zoom.Quiet <zoom...@gmail.com> wrote:

是也乎,是也乎,这两周发觉俺平时对一些基础概念并没有精确把握住,
所以,面对问题时,经常想差,
建议 agentzh 在系列教程中也增补类似参考吼,
现在感觉到容易纠结在一起的概念(先尝试白话一下):
- 阻塞式 I/O
- 凡是对当前进程/线程之外的资源进行沟通,都是 I/O 不论网络/硬盘/内存,,,
- 栈式逐一等待完成的 I/O

一个简单的判断标准是 I/O 操作是否会阻塞任何一个 OS 线程。如果是，便是阻塞式 I/O，否则则不是。

- 非阻塞式 I/O
- 协程或是其它技术进行非等待的 I/O 并行处理

见上面。这与协程啥的没关系。

- 请求的同步响应
- 应用对请求引发的所有行动,进行排队,逐一完成

同步操作是一种编程方式，举例来说，

local result = do_something()

do_something 函数全部完成工作之后再返回，便是同步操作。

所有 HTTP 请求都是本质上都是同步响应的（或许 HTTP 1.1 pipelining 是仅有的例外，但处理仍然是同步的）。HTTP server 一般不会还没干完活儿就直接发 HTTP 响应。

- 请求的异步响应
- 应用能随时完好的挂起请求,进行并发处理

do_something(function (result) ... end)

这里，do_something 调用是异步的，因为它不等它自己的活儿全部干完，就立即返回。这种调式一般会带一个回调函数作为参数，以便在活儿真正干完后让用户接着处理结果。目前 openresty 的亮点,针对以上概念是:

- 内置多种非阻塞式网络I/O 模型
- 通过 Lua 进行业务描述时,形式是同步的,但是通过 Nginx 的内置机制配合
- 实际可以是异步的

决定性能的不是同步还是异步。无论同步也好，异步也罢，和并发能力一点儿关系都没有。重要的是 I/O 操作尽量不要阻塞任何 OS 线程，否则单机 1 万并发的梦就成泡影了。

关于“异步 I/O”是一个专门的术语，常缩写为 AIO，见 http://lse.sourceforge.net/io/aio.html

Regards,
-agentzh

zoom.quiet

在 2012年3月15日 下午3:03，agentzh <age...@gmail.com> 写道：
> On Thu, Mar 15, 2012 at 2:44 PM, Zoom.Quiet <zoom...@gmail.com> wrote:
>>
>> 是也乎,是也乎,这两周发觉俺平时对一些基础概念并没有精确把握住,
>> 所以,面对问题时,经常想差,
>> 建议 agentzh 在系列教程中也增补类似参考吼,
>> 现在感觉到容易纠结在一起的概念(先尝试白话一下):
>> - 阻塞式 I/O
>>  - 凡是对当前进程/线程之外的资源进行沟通,都是 I/O 不论网络/硬盘/内存,,,
>>  - 栈式逐一等待完成的 I/O
>
>
> 一个简单的判断标准是 I/O 操作是否会阻塞任何一个 OS 线程。如果是，便是阻塞式 I/O，否则则不是。
>
>>
>> - 非阻塞式 I/O
>>  - 协程或是其它技术进行 非等待的 I/O 并行处理
>
>
> 见上面。这与协程啥的没关系。
>
>>
>> - 请求的同步响应
>>  - 应用对请求引发的所有行动,进行排队,逐一完成
>
>
> 同步操作是一种编程方式，举例来说，
>
>     local result = do_something()
>
> do_something 函数全部完成工作之后再返回，便是同步操作。
>
> 所有 HTTP 请求都是本质上都是同步响应的（或许 HTTP 1.1 pipelining 是仅有的例外，但处理仍然是同步的）。HTTP server
> 一般不会还没干完活儿就直接发 HTTP 响应。
>
>>
>> - 请求的异步响应
>>  - 应用能随时完好的挂起请求,进行并发处理
>
>
>     do_something(function (result) ... end)
>
> 这里，do_something
> 调用是异步的，因为它不等它自己的活儿全部干完，就立即返回。这种调式一般会带一个回调函数作为参数，以便在活儿真正干完后让用户接着处理结果。目前
> openresty 的亮点,针对以上概念是:
>>
>> - 内置多种非阻塞式网络I/O 模型
>> - 通过 Lua 进行业务描述时,形式是同步的,但是通过 Nginx 的内置机制配合
>>  - 实际可以是异步的
>>
>
> 决定性能的不是同步还是异步。无论同步也好，异步也罢，和并发能力一点儿关系都没有。重要的是 I/O 操作尽量不要阻塞任何 OS 线程，否则单机 1
> 万并发的梦就成泡影了。
>
> 关于“异步 I/O”是一个专门的术语，常缩写为 AIO，见 http://lse.sourceforge.net/io/aio.html
>

- 一切都是 CPU 的顺序指令决定了
- 总算明白为毛那么多人期待 LispMachine 了,,,



--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
文字协议: http://creativecommons.org/licenses/by-sa/2.5/cn/