fix: redis reacquire

[seth-shi]

see: TestRedisLock_SameAcquire test

[seth-shi]

locker id just use as release key

[kevwan]

Thanks for your contribution! Would you please resolve conflicts?

[seth-shi]

done

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.11%. Comparing base (8690859) to head (531ccf5).
Report is 124 commits behind head on master.

Additional details and impacted files

Files	Coverage Δ
core/stores/redis/redislock.go	86.48% <100.00%> (+5.09%)	⬆️

... and 254 files with indirect coverage changes

[zcong1993]

go-zero's redis lock is a bit like etcd's lease.
When you first acquire a lock with a TTL, you own the lock, then you can do two things:

1. release the lock
2. refresh TTL of the lock, recall Acquire method if you own the lock, same like keepalive of etcd's lease

So the lock's owner can call Acquire multi times, and will always return true if you own the lock.

[seth-shi]

that' s a good explanation, but I think the lock should be for other language users not to create ambiguity. because distributed locks can't be reowned even by themselves

[seth-shi]

a typical example is 'redis set nx ex'
the effect is the same whether it's the same client or a different client call

[kevwan]

It's better to do a rebase, which will make your changes easy to review.

[seth-shi]

new pr: #4325

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

New on: https://github.com/zeromicro/joe-zero/pull/4325