So implementieren Sie den verteilten Cache und Flash-Verkäufe von Redis

1. Probleme mit Single-Point-Redis

1. Datenverlustproblem

Redis-Datenpersistenz.

2. Parallelitätsproblem

Wir verwenden Master-Slave-Cluster, um eine Trennung von Lesen und Schreiben zu erreichen.

3. Fehlerwiederherstellungsproblem

Verwenden Sie Redis Sentinel, um die Gesundheitserkennung und die automatische Wiederherstellung zu implementieren.

4. Problem mit der Speicherkapazität

Erstellen Sie einen Shard-Cluster und nutzen Sie den Slot-Mechanismus, um eine dynamische Erweiterung zu erreichen.

2. RDB

RDB steht für Redis Database Backup File (Redis-Datensicherungsdatei), auch Redis-Daten-Snapshot genannt. Vereinfacht ausgedrückt werden alle Daten im Speicher auf der Festplatte aufgezeichnet. Wenn die Redis-Instanz ausfällt und neu startet, wird die Snapshot-Datei von der Festplatte gelesen und die Daten werden wiederhergestellt.
Snapshot-Dateien werden RDB-Dateien genannt und standardmäßig im aktuell ausgeführten Verzeichnis gespeichert.

Redis verfügt über einen internen Mechanismus zum Auslösen von RDB, der in der Datei redis.conf zu finden ist. Das Format ist wie folgt:

Wenn der Befehl bgsave ausgeführt wird, wird über das Fork-System ein untergeordneter Prozess erstellt Aufruf, der mit den Hauptprozessdaten geteilt wird. Lesen Sie nach Abschluss der Verzweigung die Speicherdaten und schreiben Sie sie in die RDB-Datei.

Fork verwendet die Copy-on-Write-Technologie:

• Wenn der Hauptprozess einen Lesevorgang ausführt, greift er auf den gemeinsam genutzten Speicher zu.

• Wenn der Hauptprozess einen Schreibvorgang ausführt, kopiert er eine Kopie der Daten und führt den Schreibvorgang aus;

Der grundlegende Prozess von bgsave im RDB-Modus?

1. Forken Sie den Hauptprozess, um einen untergeordneten Prozess zu erhalten und den Speicherplatz zu teilen.

2. Der untergeordnete Prozess liest die Speicherdaten und schreibt die neue RDB-Datei.

3. Ersetzen Sie die alte RDB-Datei Datei;

Wann wird RDB ausgeführt? Was bedeutet 60 1000 sparen?

• Der Standardwert ist, wenn der Dienst gestoppt wird.

• bedeutet, dass RDB ausgelöst wird, wenn mindestens 1000 Änderungen innerhalb von 60 Sekunden durchgeführt werden.

Die Nachteile von RDB?

• Das RDB-Ausführungsintervall ist lang und es besteht die Gefahr eines Datenverlusts zwischen zwei RDB-Schreibvorgängen.

• Fork-Unterprozesse, Komprimierung und das Schreiben von RDB-Dateien sind alle zeitaufwändig Befehlsdatensätze Die Häufigkeit kann auch über die Datei redis.conf konfiguriert werden:

3 AOF steht für Append Only File. Jeder von Redis verarbeitete Schreibbefehl wird in der AOF-Datei aufgezeichnet, die als Befehlsprotokolldatei betrachtet werden kann.

AOF ist standardmäßig deaktiviert. Sie müssen die Konfigurationsdatei redis.conf ändern, um AOF zu aktivieren:

Die Häufigkeit der AOF-Befehlsaufzeichnung kann auch über die Datei redis.conf konfiguriert werden:

Konfigurationselemente

Zeit zum Flashen der FestplatteVorteileHohe Zuverlässigkeit, fast kein DatenverlustLeistung moderatBeste Leistung

Nachteile

Immer

Synchronisches Flashen

Große Auswirkung auf die Leistung

jede Sekunde

Blinken jede Sekunde

Bis zu einer Minute Datenverlust

nein

Betriebssystemsteuerung

Schlechte Zuverlässigkeit, möglicher Verlust großer Datenmengen

Da es sich um einen Aufzeichnungsbefehl handelt, ist die AOF-Datei viel größer als die RDB-Datei. Obwohl AOF mehrere Schreibvorgänge auf denselben Schlüssel aufzeichnet, ist nur der letzte Schreibvorgang von Bedeutung. Sie können den Befehl bgrewriteaof verwenden, um die Funktion zum Umschreiben der AOF-Datei mit der minimalen Anzahl von Befehlen abzuschließen.

set id 1
set name nezha
set id 2

bgrewriteaof

mset name nezha id 2

Redis schreibt die AOF-Datei auch automatisch neu, wenn der Schwellenwert ausgelöst wird. Der Schwellenwert kann auch in redis.conf konfiguriert werden:

# Der Prozentsatz, um den die AOF-Datei im Vergleich zur letzten Datei wächst, löst das automatische Umschreiben von aof-rewrite-percentage aus. 100# Die Mindestgröße der AOF-Datei löst das automatische Umschreiben aus. aof. -rewrite-min-size 64mb

RDB und AOF haben jeweils ihre eigenen Vor- und Nachteile. Wenn die Anforderungen an die Datensicherheit hoch sind, werden sie in der tatsächlichen Entwicklung häufig kombiniert. ?? Unvollständig, zwei Backups gehen relativ verloren

vollständig, abhängig von der Disk-Brushing-Strategie 4. Redis-Optimierungs-Flash Verkaufsprozess 1. Flash-Sale-Schritte: Flash-Sale-Produktbestand beurteilen; Bestellungen überprüfen; Lagerbestand reduzieren; Bestellung erstellen;

Dateigröße	wird komprimiert, die Dateigröße ist klein	Aufnahmebefehl, die Dateigröße ist groß
Downtime-Wiederherstellungsgeschwindigkeit	sehr schnell	Langsam
Datenwiederherstellungspriorität	Niedrig, weil die Datenintegrität nicht niedrig ist	Hoch, weil die Datenintegrität höher ist
Systemressourcennutzung	Hoch, viel CPU- und Speicherverbrauch	Niedrig, hauptsächlich Festplatten-IO-Ressourcen, aber das AOF-Umschreiben beansprucht viele CPU- und Speicherressourcen
Nutzungsszenarien	Kann Datenverlust für mehrere Minuten tolerieren, strebt eine schnellere Startgeschwindigkeit an	Höhere Anforderungen an die Datensicherheit Häufig

2. Redis-Optimierungs-Flash-Sale-Schritte:

1. Flash-Sale-Coupons hinzufügen und die Coupon-Informationen in Redis speichern;

2. Basierend auf dem Lua-Skript wird der Lagerbestand ermittelt Bei Flash-Sale-Produkten bestellt eine Person eines und bestimmt, ob der Flash-Sale des Benutzers erfolgreich ist. Wenn der Flash-Sale erfolgreich ist, werden die Coupon-ID, die Benutzer-ID und die Produkt-ID in die Sperrwarteschlange eingekapselt
   Aktivieren Sie asynchrone Aufgaben, lesen Sie kontinuierlich Informationen aus der Blockierungswarteschlange und realisieren Sie die asynchrone Bestellfunktion.

4. 3. Lua-Skript für Flash-Verkauf

   public Result seckillVoucher(Long voucherId) {
        Long userId = UserHolder.getUser().getId();
        long orderId = redisIdWorker.nextId("order");
        // 1.执行lua脚本
        Long result = stringRedisTemplate.execute(
                SECKILL_SCRIPT,
                Collections.emptyList(),
                voucherId.toString(), userId.toString(), String.valueOf(orderId)
        );
        int r = result.intValue();
        // 2.判断结果是否为0
        if (r != 0) {
            // 2.1.不为0 ，代表没有购买资格
            return Result.fail(r == 1 ? "库存不足" : "不能重复下单");
        }
        // 3.返回订单id
        return Result.ok(orderId);
    }

5. Durch den Thread-Pool blockiert der Vorgang die Warteschlange

5. // 线程池
   private static final ExecutorService SECKILL_ORDER_EXECUTOR = Executors.newSingleThreadExecutor();
   
   /**
   * 在类初始化完成后执行
   */
   @PostConstruct
   private void init() {
       SECKILL_ORDER_EXECUTOR.submit(new VoucherOrderHandler());
   }
   
   // 阻塞队列
   private BlockingQueue<VoucherOrder> orderTasks = new ArrayBlockingQueue<>(1024 * 1024);
   private class OrderHandler implements Runnable{
   
       @Override
       public void run() {
           while (true){
               try {
                   doSomething();
               } catch (Exception e) {
                   log.error("处理订单异常", e);
               }
           }
       }
   }

   5. Gemeinsame Sitzungsanmeldung basierend auf Redis

Anmeldung basierend auf Sitzung

Gemeinsame Sitzungsanmeldung basierend auf Redis

public class RefreshTokenInterceptor implements HandlerInterceptor {

    private StringRedisTemplate stringRedisTemplate;

    public RefreshTokenInterceptor(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        // 1、获取请求头中的token
        String token = request.getHeader("authorization");
        if (StrUtil.isBlank(token)) {
            return true;
        }
        // 2、基于TOKEN获取redis中的用户
        String key  = LOGIN_USER_KEY + token;
        Map<Object, Object> userMap = stringRedisTemplate.opsForHash().entries(key);
        // 3、判断用户是否存在
        if (userMap.isEmpty()) {
            return true;
        }
        // 5、将查询到的hash数据转为UserDTO
        UserDTO userDTO = BeanUtil.fillBeanWithMap(userMap, new UserDTO(), false);
        // 6、存在，保存用户信息到 ThreadLocal
        UserHolder.saveUser(userDTO);
        // 7、刷新token有效期
        stringRedisTemplate.expire(key, LOGIN_USER_TTL, TimeUnit.MINUTES);
        // 8、放行
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        // 移除用户
        UserHolder.removeUser();
    }
}

Das obige ist der detaillierte Inhalt vonSo implementieren Sie den verteilten Cache und Flash-Verkäufe von Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!