Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate best locking approach for Redis cluster with Predis sentinel #16

Open
willemstuursma opened this issue Apr 16, 2018 · 3 comments

Comments

@willemstuursma
Copy link
Contributor

Predis abstracts the multi-redis server setup, but this package can also take multiple predis connections and do the abstraction itself. Which one would be "better" for a locking package?

@coderNeos
Copy link

Hi. Your package is really good. I think that in case of predis cluster, we should use it's built-in functionality for abstraction. It's easier to pass one instance of predis, because you don't need to check if it's cluster or not, you just pass the instance.

@willemstuursma
Copy link
Contributor Author

I guess I first would have to define better. I would like to know, if there are some features we could use when handling the multiple connections ourselves vs. having Predis handle it.

We would need to investigate if using Sentinel allow us to continue working if one server goes down in the middle of the lock.

@willemstuursma
Copy link
Contributor Author

Partial cluster failure works perfectly with the PHPRedisMutex, todo investigate how this should work with the PredisMutex. I don't think it is realistic that multiple Predis\ClientInterface objects would be passed to the mutex, so we should try to get the distinct connections from the Client in the mutex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants