Microservice Architectures - Distributed Caches
There are different approaches on caching with microservices (https://hazelcast.com/blog/architectural-patterns-for-caching-microservices/).
Hazelcast Embedded Caches
- Data separate from applications
- Separate management (scaling, backup)
- Programming-language agnostic
- Separate Ops effort
- Higher latency
- Server network requires adjustment (same region, same VPC)
Hazelcast client-server mode
In the Client/Server deployment, Hazelcast data and services are centralized in one or more server members and they are accessed by the application through clients. You can have a cluster of server members that can be independently created and scaled. Your clients communicate with these members to reach to Hazelcast data and services on them.
See the below illustration. <TODO>
Client/Server deployment has advantages including more predictable and reliable Hazelcast performance, easier identification of problem causes and, most importantly, better scalability. When you need to scale in this deployment type, just add more Hazelcast server members. You can address client and server scalability concerns separately.
Redisson (java Redis client)
It supports cluster, AWS Elasticache, Sentinel, master/slave and single connection modes.
High Availability with Redis
Sentinel is a sepparate application which provides automated fail over for master and slaves.
Monitoring. Sentinel constantly checks if your master and replica instances are working as expected.
Notification. Sentinel can notify the system administrator, or other computer programs, via an API, that something is wrong with one of the monitored Redis instances.
Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a replica is promoted to master, the other additional replicas are reconfigured to use the new master, and the applications using the Redis server are informed about the new address to use when connecting.
Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address. Sentinel is then used to keep one node handling data traffic at all times, within limits of aliveness-testing.
Alternatively, one could deploy a single Sentinel and have each standalone master or each pod connect to it to provide service discovery.
Redis Cluster is a data sharding solution with automatic management, handling failover and replication. Redis are configured to spread data across a given number of Redis instances.