OpenResty 从入门到实战
温铭
OpenResty 软件基金会第一任主席,Apache APISIX 项目 VP
20903 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 52 讲
结束语 (1讲)
OpenResty 从入门到实战
15
15
1.0x
00:00/00:00
登录|注册

25 | 答疑(二):特权进程的权限到底是什么?

ngx_time_update 会在事件循环中被调用
时间缓存下来
只要两个操作之间有 yield 操作,就可能出现竞争
数据可以在 C 模块和 Lua 代码中传递
请求结束后消失
需要有强有力的测试案例和调试日志来作为保证
使用 ngx.say 和 ngx.log 来看输出
不应该把 worker 进程的任务交给特权进程来处理
重启 OpenResty 自身
清理日志
ngx.now() 获取当前时间
共享字典的操作都是原子性的,不需要加锁
变量竞争
ngx.var 变量的作用域
需要自己构建测试案例来验证想法
ngx.exit(ngx.ERROR) 和 ngx.exit(ngx.DECLINED) 的处理
ngx.exit(ngx.OK) 时,请求会退出当前处理阶段,进入下一个阶段
OpenResty 中的代码调试
特权进程的使用场景
特权进程的权限和 master 进程的权限保持一样
OpenResty 中如何更新时间?
共享字典操作是否需要加锁呢?
变量和竞争
ngx.exit 和动手实验
阶段和调试
特权进程的权限到底是什么?

该思维导图由 AI 生成,仅供参考

你好,我是温铭。
专栏更新到现在,OpenResty 第二版块 OpenResty API 篇,我们就已经学完了。恭喜你没有掉队,仍然在积极学习和实践操作,并且热情地留下了你的思考。
很多留言提出的问题很有价值,大部分我都已经在 App 里回复过,一些手机上不方便回复的或者比较典型、有趣的问题,我专门摘了出来,作为今天的答疑内容,集中回复。另一方面,也是为了保证所有人都不漏掉任何一个重点。
下面我们来看今天的这 6 个问题。

第一问,特权进程的权限

Q:我想请问下,特权进程是怎么回事,如果启动 OpenResty 的本身就是普通用户,如何获取 root 权限呢?另外,老师可以介绍下,特权进程的使用场景有哪些吗?
A:其实,特权进程的权限和 master 进程的权限保持一样。如果你用普通用户身份启动 OpenResty,那么 master 就是普通用户的权限,这时候特权进程也就没有什么特权了。
这一点应该还是很好理解的,普通用户启动的进程,无论如何也不会有 root 权限。
至于特权进程的使用场景,我们一般用特权进程来处理的是清理日志、重启 OpenResty 自身等需要高权限的任务。你需要注意的是,不要把 worker 进程的任务交给特权进程来处理。这并非因为特权进程不能做到,而是其存在安全隐患。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文主要围绕OpenResty中特权进程的权限、阶段和调试、ngx.exit的作用、变量和竞争、共享字典操作以及OpenResty中时间更新等问题展开讨论。在特权进程的权限方面,文章指出特权进程的权限和master进程的权限保持一致,用特权进程来处理清理日志、重启OpenResty自身等需要高权限的任务。在阶段和调试方面,文章解释了OpenResty中的代码调试方式,并强调了测试案例和调试日志的重要性。在ngx.exit的作用方面,文章详细解释了ngx.exit的不同状态码对请求处理阶段的影响。在变量和竞争方面,文章阐述了ngx.var变量的作用域和变量竞争的情况。在共享字典操作方面,文章指出共享字典的操作是原子性的,不需要额外加锁。最后,文章解释了OpenResty中时间更新的机制,强调了Nginx以性能优先的设计理念。整体而言,本文涵盖了OpenResty中的一些关键技术问题,为读者提供了深入的技术讨论和解答。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《OpenResty 从入门到实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(4)

  • 最新
  • 精选
  • HelloBug
    老师,你好,关于共享内存加锁及竞争条件有个疑问~ 假设有这样的场景,所有的工作进程都可以执行到如下操作序列,dict.get, dict.set。进程1执行了dict.get之后,进程2这时获得了共享内存锁,这个时候执行了dict.set,然后进程1再次获得了共享内存锁,执行dict.set之前,看到的其实已经是共享内存中比较老的数据了,然后执行了dict.set操作,覆盖了进程2的操作。这里等待获得共享内存锁的操作,应该是个阻塞操作,按照文中的说法,阻塞操作应该不会产生竞争。可是这里应该是产生了竞争了是吧?难道说这里涉及到把主动权交给nginx的事件循环了吗?

    作者回复: 我的理解哈,多个 worker 共享了同一个 shared dict,你这里的描述更像是数据库里面的事务,要达到这个效果有两个方法: 1. 如果用 incr 能够满足你的需求的话,就不要用 set; 2. 否则就需要你自己去手工加锁。 如果是 lrucache 的 get 和 set 操作就不会有这个问题,因为它只存在于一个 worker 内。

    2019-07-22
    2
  • 高远
    断点调试别忘了lua-resty-repl呀~😁

    作者回复: 置顶:)

    2019-07-23
    1
  • HelloTalk
    特权进程的权限和 master 进程的权限保持一样。 这句话的意思是说 特权进程 不是master进程吗? 如在 worker数量为4的情况 nginx nginx: worker process nginx: worker process nginx: worker process nginx: worker process nginx: cache manager process nginx: master process /usr/local/openresty/nginx/sbin/nginx -c 总共就这6个进程,master 就是特权进程吧
    2019-11-02
  • wusiration
    受益良多,谢谢老师的解答
    2019-07-22
收起评论
显示
设置
留言
4
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部