lua-resty-lock的抢锁可能存在的bug

yunthanatos · 2015-12-04T12:22:30+00:00

thx !set_by_lua rewrite_by_lua access_by_lua content_by_lua header_filter_by_lua body_filter_by_lua log_by_lua zhengxi...@163.com 发&...

lua-resty-lock的抢锁可能存在的bug

yunthanatos

最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free

extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)

extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.

extern int pthread_spin_lock (pthread_spinlock_t *__lock)

extern int pthread_spin_trylock (pthread_spinlock_t *__lock)

extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

yuansheng_2f16

resty/lock.lua 库的 lock 操作把 add 方法替换成 safe_add ，我觉得是非常有必要的。

我提交了一个 PR：

https://github.com/openresty/lua-resty-lock/pull/6

稍候补充一下测试用例。

2015-12-04 12:22 GMT+08:00 燕云 <yunth...@gmail.com>:

最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free
extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.
extern int pthread_spin_lock (pthread_spinlock_t *__lock)
extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

moonbingbing

换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？

这个cache最小是1k大小，容量应该够了吧。

欢迎讨论。

在 2015年12月4日下午12:22，燕云 <yunth...@gmail.com>写道：

最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free
extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.
extern int pthread_spin_lock (pthread_spinlock_t *__lock)
extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

--

yunthanatos

多谢YuanSheng :)

在 2015年12月4日星期五 UTC+8下午2:23:00，YuanSheng Wang写道：

resty/lock.lua 库的 lock 操作把 add 方法替换成 safe_add ，我觉得是非常有必要的。

我提交了一个 PR：
https://github.com/openresty/lua-resty-lock/pull/6

稍候补充一下测试用例。

2015-12-04 12:22 GMT+08:00 燕云 <yunth...@gmail.com>:
最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free
extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.
extern int pthread_spin_lock (pthread_spinlock_t *__lock)
extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

yunthanatos

>> 换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？

在这种情况下,锁服务应该dump出error,告诉维护者它需要更多的共享内存,并将此失败信息告诉给锁服务的用户,即试图抢锁的进程.

我认为这种处理方法是最严谨的.因为在大多数情况下,服务短时不可用是可以接受的,服务出错是不可容忍的,因为很少有系统能够抵抗拜占庭问题.

>> 这个cache最小是1k大小，容量应该够了吧。

如果有很多业务都使用这个锁服务进行抢自己业务内的锁,例如:

有一千个业务,它们的worker会分别抢key为 "lock1" "lock2" "lock3" ... "lock1000"等等的锁,这样错误就很容易产生了.

考虑一下,如果有用户将ngx-lua当作一个异步网络开发平台,上面跑了众多业务核心逻辑,并且在分布式场景中大规模的部署,这个问题出现的概率就更加的大了.

锁服务无论在单机上还是分布式系统中,都是极为关键的服务,马虎不得.

正是因为大家都非常喜欢和关心openresty,所以才会在这儿花这么多的时间来讨论这样的一个技术问题.

openresty作为一个关键的基础设施,应该实现的足够严谨,不能成为系统的短板 :)

在 2015年12月4日星期五 UTC+8下午2:59:14，mbb写道：

换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？
这个cache最小是1k大小，容量应该够了吧。
欢迎讨论。

在 2015年12月4日下午12:22，燕云 <yunth...@gmail.com>写道：
最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free
extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.
extern int pthread_spin_lock (pthread_spinlock_t *__lock)
extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

--

yuansheng_2f16

> 正是因为大家都非常喜欢和关心openresty,所以才会在这儿花这么多的时间来讨论这样的一个技术问题.

深深被你打动。

> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

lock 操作里面的 add 替换成 safe_add ，我真觉得很有必要。

2015-12-04 18:59 GMT+08:00 Yun Thanatos <yunth...@gmail.com>:

>> 换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？

在这种情况下,锁服务应该dump出error,告诉维护者它需要更多的共享内存,并将此失败信息告诉给锁服务的用户,即试图抢锁的进程.

我认为这种处理方法是最严谨的.因为在大多数情况下,服务短时不可用是可以接受的,服务出错是不可容忍的,因为很少有系统能够抵抗拜占庭问题.

>> 这个cache最小是1k大小，容量应该够了吧。

如果有很多业务都使用这个锁服务进行抢自己业务内的锁,例如:

有一千个业务,它们的worker会分别抢key为 "lock1" "lock2" "lock3" ... "lock1000"等等的锁,这样错误就很容易产生了.

考虑一下,如果有用户将ngx-lua当作一个异步网络开发平台,上面跑了众多业务核心逻辑,并且在分布式场景中大规模的部署,这个问题出现的概率就更加的大了.

锁服务无论在单机上还是分布式系统中,都是极为关键的服务,马虎不得.

正是因为大家都非常喜欢和关心openresty,所以才会在这儿花这么多的时间来讨论这样的一个技术问题.

openresty作为一个关键的基础设施,应该实现的足够严谨,不能成为系统的短板 :)

在 2015年12月4日星期五 UTC+8下午2:59:14，mbb写道：
换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？
这个cache最小是1k大小，容量应该够了吧。
欢迎讨论。

在 2015年12月4日下午12:22，燕云 <yunth...@gmail.com>写道：
最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free
extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.
extern int pthread_spin_lock (pthread_spinlock_t *__lock)
extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

--

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

agentzh

Hello!

2015-12-03 20:22 GMT-08:00 燕云:
> 问题:
> 官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).
> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.
> 不知道诸位怎么看待这个问题的呢?
>

嗯，可以在 resty.lock 类的 new 方法里面添加一个 safe_add 选项，接受布尔值（默认为 false），以适应不同的场景需求。

Regards,
-agentzh

chenweidelphi

在我们CDN设计中，有一个重要的概念叫老化;也就是说硬盘空间快满之前，要删除一些内容。老化需要策略，通常理解是非热点内容优先删除，受到保护标签的内容最后删除。

我觉得用在这里也差不多，最好LUA开发包能释放出钩子让开发者自己设计老化策略。不同场景不同做法。

------------------ 原始邮件 ------------------

发件人: "agentzh";<age...@gmail.com>;

发送时间: 2015年12月4日(星期五) 晚上8:31

收件人: "openresty"<openresty@googlegroups.com>;

主题: Re: [openresty] lua-resty-lock的抢锁可能存在的bug

Hello!

2015-12-03 20:22 GMT-08:00 燕云:
> 问题:
> 官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).
> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.
> 不知道诸位怎么看待这个问题的呢?
>

嗯，可以在 resty.lock 类的 new 方法里面添加一个 safe_add 选项，接受布尔值（默认为 false），以适应不同的场景需求。

Regards,
-agentzh

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com
发言: 请发邮件到 openresty@googlegroups.com
退订: 请发邮件至 openresty+unsubscribe@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

yuansheng_2f16

对上一个提交，增加了可选项。

https://github.com/openresty/lua-resty-lock/pull/6/files

大家看看是否是期望的，我正在补充测试用例，稍候再提交。

2015-12-05 13:13 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:

在我们CDN设计中，有一个重要的概念叫老化;也就是说硬盘空间快满之前，要删除一些内容。老化需要策略，通常理解是非热点内容优先删除，受到保护标签的内容最后删除。

我觉得用在这里也差不多，最好LUA开发包能释放出钩子让开发者自己设计老化策略。不同场景不同做法。

------------------ 原始邮件 ------------------
发件人: "agentzh";<age...@gmail.com>;
发送时间: 2015年12月4日(星期五) 晚上8:31
收件人: "openresty"<openresty@googlegroups.com>;
主题: Re: [openresty] lua-resty-lock的抢锁可能存在的bug

Hello!

2015-12-03 20:22 GMT-08:00 燕云:
> 问题:
> 官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).
> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.
> 不知道诸位怎么看待这个问题的呢?
>

嗯，可以在 resty.lock 类的 new 方法里面添加一个 safe_add 选项，接受布尔值（默认为 false），以适应不同的场景需求。

Regards,
-agentzh

--

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

harvey.zhangjl

hello!

2015-12-06 10:48 GMT+08:00 YuanSheng Wang <yuan...@iresty.org>:

对上一个提交，增加了可选项。
https://github.com/openresty/lua-resty-lock/pull/6/files

大家看看是否是期望的，我正在补充测试用例，稍候再提交。

pr 里面的 save_add 应该改为 safe_add 吧。

2015-12-05 13:13 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:
在我们CDN设计中，有一个重要的概念叫老化;也就是说硬盘空间快满之前，要删除一些内容。老化需要策略，通常理解是非热点内容优先删除，受到保护标签的内容最后删除。

我觉得用在这里也差不多，最好LUA开发包能释放出钩子让开发者自己设计老化策略。不同场景不同做法。

------------------ 原始邮件 ------------------
发件人: "agentzh";<age...@gmail.com>;
发送时间: 2015年12月4日(星期五) 晚上8:31
收件人: "openresty"<openresty@googlegroups.com>;
主题: Re: [openresty] lua-resty-lock的抢锁可能存在的bug

Hello!

2015-12-03 20:22 GMT-08:00 燕云:
> 问题:
> 官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).
> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.
> 不知道诸位怎么看待这个问题的呢?
>

嗯，可以在 resty.lock 类的 new 方法里面添加一个 safe_add 选项，接受布尔值（默认为 false），以适应不同的场景需求。

Regards,
-agentzh

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

--

yuansheng_2f16

丢人了，这就修改。见笑。

2015-12-06 11:02 GMT+08:00 jialiang zhang <harvey...@gmail.com>:

hello!

2015-12-06 10:48 GMT+08:00 YuanSheng Wang <yuan...@iresty.org>:
对上一个提交，增加了可选项。
https://github.com/openresty/lua-resty-lock/pull/6/files

大家看看是否是期望的，我正在补充测试用例，稍候再提交。

pr 里面的 save_add 应该改为 safe_add 吧。

2015-12-05 13:13 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:
在我们CDN设计中，有一个重要的概念叫老化;也就是说硬盘空间快满之前，要删除一些内容。老化需要策略，通常理解是非热点内容优先删除，受到保护标签的内容最后删除。

我觉得用在这里也差不多，最好LUA开发包能释放出钩子让开发者自己设计老化策略。不同场景不同做法。

------------------ 原始邮件 ------------------
发件人: "agentzh";<age...@gmail.com>;
发送时间: 2015年12月4日(星期五) 晚上8:31
收件人: "openresty"<openresty@googlegroups.com>;
主题: Re: [openresty] lua-resty-lock的抢锁可能存在的bug

Hello!

2015-12-03 20:22 GMT-08:00 燕云:
> 问题:
> 官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).
> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.
> 不知道诸位怎么看待这个问题的呢?
>

嗯，可以在 resty.lock 类的 new 方法里面添加一个 safe_add 选项，接受布尔值（默认为 false），以适应不同的场景需求。

Regards,
-agentzh

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

--

--

Membhis

My github: https://github.com/membphis

Our Book: OpenResty Best Practices

moonbingbing

这个时候，如果这个共享内存空间能够动态增加，是不是更完美？

在 2015年12月4日下午6:59，Yun Thanatos <yunth...@gmail.com>写道：

>> 换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？

在这种情况下,锁服务应该dump出error,告诉维护者它需要更多的共享内存,并将此失败信息告诉给锁服务的用户,即试图抢锁的进程.

我认为这种处理方法是最严谨的.因为在大多数情况下,服务短时不可用是可以接受的,服务出错是不可容忍的,因为很少有系统能够抵抗拜占庭问题.

>> 这个cache最小是1k大小，容量应该够了吧。

如果有很多业务都使用这个锁服务进行抢自己业务内的锁,例如:

有一千个业务,它们的worker会分别抢key为 "lock1" "lock2" "lock3" ... "lock1000"等等的锁,这样错误就很容易产生了.

考虑一下,如果有用户将ngx-lua当作一个异步网络开发平台,上面跑了众多业务核心逻辑,并且在分布式场景中大规模的部署,这个问题出现的概率就更加的大了.

锁服务无论在单机上还是分布式系统中,都是极为关键的服务,马虎不得.

正是因为大家都非常喜欢和关心openresty,所以才会在这儿花这么多的时间来讨论这样的一个技术问题.

openresty作为一个关键的基础设施,应该实现的足够严谨,不能成为系统的短板 :)

在 2015年12月4日星期五 UTC+8下午2:59:14，mbb写道：
换个思路想想，如果这个cache占满了，而且里面的key很长时间才会失效。这时候怎么add都失败，应该怎么办？
这个cache最小是1k大小，容量应该够了吧。
欢迎讨论。

在 2015年12月4日下午12:22，燕云 <yunth...@gmail.com>写道：
最近整理了下这个问题的详细描述,如下.

前提P1:

ngx.shared.DICT的API使得它有两种典型的用法:

1)存储重要的全局元数据,在其整个的生命周期内,是不能容忍被错误地删除、或者淘汰掉的,否则会导致系统的核心逻辑无法正常地执行下去,甚至逻辑出错;

2)用来存储全局的Cache,它的存在只是为了提高这种信息的缓存命中率,即使一些条目被淘汰掉掉了,也对系统的核心逻辑无致命的影响.

对于存储元数据的DICT,应对其使用{safe_set,safe_add}等安全的API,因为这些用法不会触发LRU淘汰策略;

而对于作为全局Cache存储的DICT,则可以使用所有类型的API,因为它可以容忍被淘汰.

如果P1是成立的,继续往下.

再看pthread_spin_lock的API:

// malloc and free
extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
extern int pthread_spin_destroy (pthread_spinlock_t *__lock)

// op.
extern int pthread_spin_lock (pthread_spinlock_t *__lock)
extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
extern int pthread_spin_unlock (pthread_spinlock_t *__lock)

基于DICT的全局锁与传统的进程间互斥锁的模型是有区别的:

DICT: 借助add类的操作,单个操作本身隐含了init和lock两个语义;

传统: 在init成功之后,再对已经分配到的锁进行trylock/lock,试图改变它的状态,以占有它.

关键:

DICT的抢锁,在init阶段也是可能失败的,这时应该返回分配失败,更不应该去淘汰别的锁成员.

问题:

官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).

如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.

不知道诸位怎么看待这个问题的呢?

--

--

moonbingbing

safe_add 应该显式的给个默认值 false ，和其他变量的风格保持一致。

在 2015年12月6日上午11:02，jialiang zhang <harvey...@gmail.com>写道：

hello!

2015-12-06 10:48 GMT+08:00 YuanSheng Wang <yuan...@iresty.org>:
对上一个提交，增加了可选项。
https://github.com/openresty/lua-resty-lock/pull/6/files

大家看看是否是期望的，我正在补充测试用例，稍候再提交。

pr 里面的 save_add 应该改为 safe_add 吧。

2015-12-05 13:13 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:
在我们CDN设计中，有一个重要的概念叫老化;也就是说硬盘空间快满之前，要删除一些内容。老化需要策略，通常理解是非热点内容优先删除，受到保护标签的内容最后删除。

我觉得用在这里也差不多，最好LUA开发包能释放出钩子让开发者自己设计老化策略。不同场景不同做法。

------------------ 原始邮件 ------------------
发件人: "agentzh";<age...@gmail.com>;
发送时间: 2015年12月4日(星期五) 晚上8:31
收件人: "openresty"<openresty@googlegroups.com>;
主题: Re: [openresty] lua-resty-lock的抢锁可能存在的bug

Hello!

2015-12-03 20:22 GMT-08:00 燕云:
> 问题:
> 官方lua-resty-lock的抢锁,使用ngx.shared.DICT.add来实现,这相当于把这个DICT当作Cache来使用(实际应该是重要的元数据).
> 如果这个DICT的容量不够大的时候,一旦add触发了淘汰机制,就会可能发生在临界区,同时有多个进程存在的情况,如果使用safe_add就不会有这种问题了.
> 不知道诸位怎么看待这个问题的呢?
>

嗯，可以在 resty.lock 类的 new 方法里面添加一个 safe_add 选项，接受布尔值（默认为 false），以适应不同的场景需求。

Regards,
-agentzh

--

--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices

--

--

agentzh

Hello!

2015-12-06 18:04 GMT-08:00 Ming:
> 这个时候，如果这个共享内存空间能够动态增加，是不是更完美？
>

这个有一定的难度……一来需要确保能找到足够大的连续空闲内存空间（如果现有的空间不能直接延展，还需要重新分配并迁移数据），二来需要修改
nginx 的 slab 分配器（它假设固定大小的空间）。

所以 zone 一般尽量设得大一些，其实即使实际不到那么多也关系不大，毕竟现代 OS 都是以页为单位按需分配物理内存的。

> safe_add 应该显式的给个默认值 false ，和其他变量的风格保持一致。

是，行为上应保持向后兼容性。

Regards,
-agentzh