Docker教程

ngx_lua模块的原理： 每个worker（工作进程）创建一个Lua VM，worker内所有协程共享VM； 将Nginx I/O原语封装后注入 Lua VM，允许Lua代码直接访问； 每个外部请求都由一个Lua协程处理，协程之间数据隔离； Lua代码调用I/O操作等异步接口时，会挂起当前协程（并保护上下文数据），而不阻塞worker； I/O等异步操作完成时还原相关协程上下文数据，并继续运行 系列文章： 指令：openResty中ngx_lua模块提供的指令 常量：openResty中ngx_lua模块提供的常量 API：openResty中ngx_lua模块提供的API   要学会openResty必须要熟记的一张图，熟记！熟记！！熟记 ！！！ 一、指令 1.1 lua_capture_error_log  <未知> 语法: lua_capture_error_log size 默认: none 模块: http 1.2 lua_use_default_type 语法: lua_use_default_type on…

ngx_lua模块的原理： 每个worker（工作进程）创建一个Lua VM，worker内所有协程共享VM； 将Nginx I/O原语封装后注入 Lua VM，允许Lua代码直接访问； 每个外部请求都由一个Lua协程处理，协程之间数据隔离； Lua代码调用I/O操作等异步接口时，会挂起当前协程（并保护上下文数据），而不阻塞worker； I/O等异步操作完成时还原相关协程上下文数据，并继续运行 系列文章： 指令：openResty中ngx_lua模块提供的指令 常量：openResty中ngx_lua模块提供的常量 API：openResty中ngx_lua模块提供的API   二、常量 2.1 Core constants 作用域: init_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, *log_by_lua*, ngx.timer.*,…

ngx_lua模块的原理： 每个worker（工作进程）创建一个Lua VM，worker内所有协程共享VM； 将Nginx I/O原语封装后注入 Lua VM，允许Lua代码直接访问； 每个外部请求都由一个Lua协程处理，协程之间数据隔离； Lua代码调用I/O操作等异步接口时，会挂起当前协程（并保护上下文数据），而不阻塞worker； I/O等异步操作完成时还原相关协程上下文数据，并继续运行 系列文章： 指令：openResty中ngx_lua模块提供的指令 常量：openResty中ngx_lua模块提供的常量 API：openResty中ngx_lua模块提供的API   三、API 3.1 print 语法: print(…) 模块: init_by_lua*, init_worker_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*,…

openResty中的ngx.location.capture和ngx.location.capture_multi的使用 在openResty中，ngx.location.capture_multi是一个非常强大的功能。可以应用于并发多个相互之间没有依赖的请求。在现代的应用架构中经常使用微服务，提供低粒度的接口；但在客户端（例如：app、网页服务）经常需要请求多个微服务接口，才能完整显示页面内容。 例如：打开一个商品详情页，需要请求： banner广告接口； 商品详情； 商品评论等。 那么ngx.location.capture_multi就派上大用场了，当然使用ngx.location.capture_multi不是唯一的办法，呵呵～。下面就来看看这个东东的用法；   先介绍一下下面这几个应用之间的差别； ngx.exec：nginx跳转；跳转到其他的location中执行。但仅限nginx内部的location。 ngx.redirect：和nginx.exec相似，但支持外部跳转。 ngx.location.capture_multi：并发请求；但仅限nginx内部的location。 http包中multi方法：概念上与ngx.location.capture_multi相似，但支持外部接口。 一、ngx.location.capture 语法: res = ngx.location.capture(uri, options?) 作用域: rewrite_by_lua*, access_by_lua*, content_by_lua* 1.1 uri 直接看栗子： location ~ /comment/([0-9]+) {…

在 OpenResty 中，同时存在两套正则表达式规范：Lua 语言的规范和 Nginx 的规范；即使您对 Lua 语言中的规范非常熟悉，我们仍不建议使用 Lua 中的正则表达式。 因为 Lua 中正则表达式的性能并不如 Nginx 中的正则表达式优秀； Lua 中的正则表达式并不符合 POSIX 规范，而 Nginx 中实现的是标准的 POSIX 规范，后者明显更具备通用性。   Lua 中的正则表达式与 Nginx 中的正则表达式相比，有 5%-15%的性能损失，而且 Lua 将表达式编译成 Pattern 之后，并不会将 Pattern 缓存，而是每此使用都重新编译一遍，潜在地降低了性能。Nginx 中的正则表达式可以通过参数缓存编译过后的 Pattern ，不会有类似的性能损失。 o 选项参数用于提高性能，指明该参数之后，被编译的 Pattern 将会在 worker 进程中缓存，并且被当前 worker 进程的每次请求所共享。 Pattern 缓存的上限值通过 lua_regex_cache_max_entries 来修改。…

在 Nginx 的典型应用场景中，几乎都是只读取 HTTP 头即可，例如负载均衡、正反向代理等场景。但是对于 API Server 或者 Web Application ，对 body 可以说就比较敏感了。 由于 OpenResty 基于 Nginx ，所以天然的对请求 body 的读取细节与其他成熟 Web 框架有些不同。在lua代码中使用 ngx.req.read_body 函数 (或打开 lua_need_request_body 选项强制本模块读取请求体，此方法不推荐）才可以获取到请求 body。究其原因，主要是 Nginx 诞生之初主要是为了解决负载均衡情况，而这种情况，是不需要读取 body 就可以决定负载策略的。…

cosocket 是 OpenResty 世界中技术、实用价值最高的部分。让我们可以用非常低廉的成本，优雅的姿势，比传统 socket 编程效率高好几倍的方式进行网络编程。无论资源占用、执行效率、并发数等都非常出色。 cosocket = coroutine + socket coroutine：协同程序（后面简称：协程） socket：网络套接字   OpenResty 中的 cosocket 不仅需要协程特性支撑，它还需 nginx 非常最重要的一部分“事件循环回调机制”，两部分拼在一起才达到了最后的 cosocket 效果，再结合 nginx 自身对各种资源的“小气”，使得整体加分不少。在 Lua 世界中调用任何一个有关 cosocket 网络函数内部关键调用如图所示：…

ngx_lua 提供了一系列共享内存相关的 API (ngx.shared.DICT)，可以很方便地通过设置过期时间来使得缓存被动过期，值得一提的是，当缓存的容量超过预先申请的内存池大小的时候，ngx.shared.DICT.set 方法则会尝试以 LRU 的形式淘汰一部分内容。   一、ngx.shared.DICT 语法: dict = ngx.shared.DICT 语法: dict = ngx.shared[name_var] 作用域: init_by_lua*, init_worker_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, ngx.timer.*, balancer_by_lua*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*,…

一、范围 float 和 double 的范围是由指数的位数来决定的。 float 的指数位有8位，而 double 的指数位有11位，分布如下： float： 1bit（符号位）  8bits（指数位）  23bits（尾数位） double：  1bit（符号位）  11bits（指数位）  52bits（尾数位）   于是，float 的指数范围为-127~+128，而 double 的指数范围为-1023~+1024，并且指数位是按补码的形式来划分的。其中负指数决定了浮点数所能表达的绝对值最小的非零数；而正指数决定了浮点数所能表达的绝对值最大的数，也即决定了浮点数的取值范围。 float 的范围为-2^128 ~ +2^128，也即-3.40E+38 ~ +3.40E+38；double 的范围为-2^1024 ~ +2^1024，也即-1.79E+308 ~ +1.79E+308。 二、精度 float 和 double 的精度是由尾数的位数来决定的。浮点数在内存中是按科学计数法来存储的，其整数部分始终是一个隐含着的“1”，由于它是不变的，故不能对精度造成影响。 float：2^23 = 8388608，一共七位，这意味着最多能有7位有效数字，但绝对能保证的为6位，也即float的精度为6~7位有效数字； double：2^52…

问题的起源：在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。 A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。   强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如 MySQL 主从同步）又有一定区别，群友的讨论分成以下 6 种解决方案。 一、规避分布式事务——业务整合 业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说，则可以将服务 A、B、C 整合为一个服务 D 给业务，这个服务…