Microservice Architectures - Distributed Caches

From Luis Gallego Hurtado - Not Another IT guy
Jump to: navigation, search


There are different approaches on caching with microservices (https://hazelcast.com/blog/architectural-patterns-for-caching-microservices/).

Embedded Caches

Spring Caches

Hazelcast Embedded Caches

Client/Server caches

https://engineering.datorama.com/moving-from-hazelcast-to-redis-b90a0769d1cb

Advantages

  • Data separate from applications
  • Separate management (scaling, backup)
  • Programming-language agnostic

Disadvantages

  • 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

http://23.253.120.235/sentinel-or-cluster/


Redis Sentinel

Sentinel is a sepparate application which provides automated fail over for master and slaves.

<TODO>

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.

https://medium.com/@amila922/redis-sentinel-high-availability-everything-you-need-to-know-from-dev-to-prod-complete-guide-deb198e70ea6

Redis Cluster

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.