完全去掉锁恐怕不行, shdict内部的锁是用来保护内部的2个数据结构rbtree和queue的. 读写操作必须在锁里进行, 否则rbtree和queue的结构可能会乱掉. 也就是说set(key,value)在api上原子但在api内部不原子.
现在shdict里用的是ngx_shmtx_lock来加锁, 理论上替换成读写锁确实可以改善并发问题. ngx_rwlock_rlock() 功能上可以用来替换shmtx_lock, 性能不好说. 在抢锁进程多的时候还是会有2048次spin lock操作, 按照每次spin lock 100 ns计算, 每次锁等待可能有0.2毫秒了.
而且rwlock的实现中没有睡眠机制(shmtx_lock里有), 会一直占用cpu 去spin.
On Thursday, January 17, 2019 at 7:33:16 PM UTC+8, fengxi...@gmail.com wrote:
我们在生产环境越来越多的使用lua_shared_dict，
底层共享内存块粒度的自旋锁对性能的影响还不小，这块OR官方是否有规划把锁控制暴露到指令参数上，比如lua_shared_dict 10m off;表示关闭底层的锁。很多场景业务层面可以做到无锁的，比如 ngx中一写多读的情况，可以通过双buffer或者超级双buffer去掉业务层面的读写锁，虽然去掉锁会失去缓存LRU的特性，但确实是业务需要。或者是否可以提供些 关于底层锁的优化思路？
