syncx: 支持分key加锁

[codecov[bot]]

Codecov Report

Merging #225 (7398862) into dev (afcc565) will increase coverage by 0.19%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev     #225      +/-   ##
==========================================
+ Coverage   95.73%   95.93%   +0.19%     
==========================================
  Files          57       58       +1     
  Lines        3094     3122      +28     
==========================================
+ Hits         2962     2995      +33     
+ Misses        101       99       -2     
+ Partials       31       28       -3     

Files	Coverage Δ
syncx/segment_key_lock.go	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[junwense]

hash冲突了能解决么

[flycash]

哈希冲突了无所谓，也就是多个 key 共用一个锁而已。但是相比全局一个锁，并发的竞争激烈程度是下降了的

[WeiJiadong]

hash冲突了能解决么

不能，但冲突也不影响。现在尽量做的是让它更均匀，尽量避免冲突，冲突时，lock会阻塞。

[junwense]

哈希冲突了无所谓，也就是多个 key 共用一个锁而已。但是相比全局一个锁，并发的竞争激烈程度是下降了的

如果锁的数量不多，并且业务允许，这个确实挺好的，这样也不用考虑锁回收和并发的问题，我开始想的是把锁的获取封装起来，对锁的获取提供不同的支持，比如hash是否允许冲突，以及底层数据结构的实现，不过这样并发问题又得考虑，这样又复杂了