Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Leer Praktisch Gebruik van Hashes | Caching met Redis en Spring Boot
Introductie tot Redis

bookPraktisch Gebruik van Hashes

We zullen onze applicatie volledig assembleren en testen met Redis en Spring Boot. Caching zal de verwerking van aanvragen aanzienlijk versnellen en de belasting op de database verminderen.

Korte samenvatting van de video

In ons programma gebruikten we de volgende logica: wanneer een gebruiker wordt toegevoegd aan de hoofddatabase, worden zijn gegevens niet gecached omdat dit nog niet nodig is.

@Transactional
public User createUser(User user) {
    return userRepository.save(user);
}

De methode createUser slaat de gebruiker eenvoudig op in de database.

Wanneer er een verzoek binnenkomt om gebruikersgegevens op te halen via ID, wordt eerst gecontroleerd of de informatie beschikbaar is in de Redis-cache. Dit voorkomt onnodige databasequery's als de gegevens al gecached zijn.

@Transactional
@Cacheable(value = "user-cache", key = "#id")
@SneakyThrows
public User getUserById(Long id) {
    Thread.sleep(100);
    return userRepository.findById(id).orElseThrow(
            () -> new RuntimeException(String.format("User with this id: %d not found", id))
    );
}

Met de annotatie @Cacheable wordt de gegevens gecached onder de sleutel user-cache, die de waarde van de id bevat (user-cache:20 voor een gebruiker met ID 20). Als de gegevens in de cache staan, worden ze opgehaald en teruggegeven. Als de gegevens niet in de cache staan, raadpleegt de methode de database.

Bij het verwijderen van gegevens uit de database is het belangrijk deze ook uit de cache te verwijderen om de consistentie van de gegevens te waarborgen en te voorkomen dat verouderde informatie wordt gebruikt.

@CacheEvict(value="user-cache", key="#id")
public void deleteUser(Long id) {
    userRepository.deleteById(id);
}

De methode deleteUser verwijdert de gebruiker uit de database en leegt hun gegevens uit de Redis-cache om te voorkomen dat verouderde informatie wordt gebruikt bij toekomstige aanvragen.

Voordelen van caching

Nu het interessante gedeelte — waarom hebben we caching geïmplementeerd? Na het toevoegen van de Redis-cache werden aanvragen veel sneller — tot wel 20 keer sneller! Dit wordt duidelijk aangetoond in de onderstaande screenshots.

Voor caching

Voor de implementatie van caching ging elke aanvraag direct naar de database, wat leidde tot aanzienlijke vertragingen tijdens de verwerking.

Na caching

Met caching worden de meeste aanvragen nu afgehandeld door Redis, wat de responstijd aanzienlijk verkort.

Samenvatting

Caching met Redis heeft het mogelijk gemaakt om de prestaties van de applicatie te optimaliseren, de verwerkingssnelheid van verzoeken te verhogen en de belasting op de database te verminderen. Deze aanpak is vooral voordelig voor applicaties met veel verkeer waarbij de snelheid van verzoekverwerking cruciaal is.

Was alles duidelijk?

Hoe kunnen we het verbeteren?

Bedankt voor je feedback!

Sectie 5. Hoofdstuk 4

Vraag AI

expand

Vraag AI

ChatGPT

Vraag wat u wilt of probeer een van de voorgestelde vragen om onze chat te starten.

bookPraktisch Gebruik van Hashes

Veeg om het menu te tonen

We zullen onze applicatie volledig assembleren en testen met Redis en Spring Boot. Caching zal de verwerking van aanvragen aanzienlijk versnellen en de belasting op de database verminderen.

Korte samenvatting van de video

In ons programma gebruikten we de volgende logica: wanneer een gebruiker wordt toegevoegd aan de hoofddatabase, worden zijn gegevens niet gecached omdat dit nog niet nodig is.

@Transactional
public User createUser(User user) {
    return userRepository.save(user);
}

De methode createUser slaat de gebruiker eenvoudig op in de database.

Wanneer er een verzoek binnenkomt om gebruikersgegevens op te halen via ID, wordt eerst gecontroleerd of de informatie beschikbaar is in de Redis-cache. Dit voorkomt onnodige databasequery's als de gegevens al gecached zijn.

@Transactional
@Cacheable(value = "user-cache", key = "#id")
@SneakyThrows
public User getUserById(Long id) {
    Thread.sleep(100);
    return userRepository.findById(id).orElseThrow(
            () -> new RuntimeException(String.format("User with this id: %d not found", id))
    );
}

Met de annotatie @Cacheable wordt de gegevens gecached onder de sleutel user-cache, die de waarde van de id bevat (user-cache:20 voor een gebruiker met ID 20). Als de gegevens in de cache staan, worden ze opgehaald en teruggegeven. Als de gegevens niet in de cache staan, raadpleegt de methode de database.

Bij het verwijderen van gegevens uit de database is het belangrijk deze ook uit de cache te verwijderen om de consistentie van de gegevens te waarborgen en te voorkomen dat verouderde informatie wordt gebruikt.

@CacheEvict(value="user-cache", key="#id")
public void deleteUser(Long id) {
    userRepository.deleteById(id);
}

De methode deleteUser verwijdert de gebruiker uit de database en leegt hun gegevens uit de Redis-cache om te voorkomen dat verouderde informatie wordt gebruikt bij toekomstige aanvragen.

Voordelen van caching

Nu het interessante gedeelte — waarom hebben we caching geïmplementeerd? Na het toevoegen van de Redis-cache werden aanvragen veel sneller — tot wel 20 keer sneller! Dit wordt duidelijk aangetoond in de onderstaande screenshots.

Voor caching

Voor de implementatie van caching ging elke aanvraag direct naar de database, wat leidde tot aanzienlijke vertragingen tijdens de verwerking.

Na caching

Met caching worden de meeste aanvragen nu afgehandeld door Redis, wat de responstijd aanzienlijk verkort.

Samenvatting

Caching met Redis heeft het mogelijk gemaakt om de prestaties van de applicatie te optimaliseren, de verwerkingssnelheid van verzoeken te verhogen en de belasting op de database te verminderen. Deze aanpak is vooral voordelig voor applicaties met veel verkeer waarbij de snelheid van verzoekverwerking cruciaal is.

Was alles duidelijk?

Hoe kunnen we het verbeteren?

Bedankt voor je feedback!

Sectie 5. Hoofdstuk 4
some-alt