Lassen Sie uns über die verschiedenen Datentypen in Redis und Cluster-bezogenes Wissen sprechen

Dieser Artikel führt Sie durch die verschiedenen Datentypen in Redis sowie durch Cluster-bezogenes Wissen und hilft Ihnen, Cluster zu verstehen. Ich hoffe, er wird Ihnen hilfreich sein!

Verschiedene Datentypen

string Der Typ ist einfach und praktisch und unterstützt die Vorabzuweisung von Speicherplatz, d Es ist nicht erforderlich, zusätzlichen Platz zu beantragen, vorausgesetzt natürlich, dass noch genügend Platz vorhanden ist. [Verwandte Empfehlungen: Redis-Video-Tutorial] Der Typ

List kann eine einfache Nachrichtenwarteschlange implementieren. Beachten Sie jedoch, dass es zu Nachrichtenverlusten kommen kann und der ACK-Modus nicht unterstützt wird.

Hash Die Tabelle ähnelt ein wenig einer relationalen Datenbank. Wenn die Hash-Tabelle jedoch immer größer wird, vermeiden Sie bitte die Verwendung von Anweisungen wie hgetall, da das Anfordern einer großen Datenmenge dazu führt, dass Redis blockiert wird Dass die Brüder dahinter warten müssen.

Set Der Set-Typ kann Ihnen bei der Erstellung einiger Statistiken helfen. Wenn Sie beispielsweise aktive Benutzer an einem bestimmten Tag zählen möchten, können Sie die Benutzer-ID direkt in das Set einfügen sdiff kann die Differenz zwischen Sätzen ermitteln, Sunion kann die Vereinigung zwischen Sätzen ermitteln und verfügt über viele Funktionen, aber Sie müssen vorsichtig sein, da diese Funktionen ihren Preis haben Blockieren, also seien Sie vorsichtig, wenn Sie coole Operationen verwenden.

zset kann als der hellste Stern bezeichnet werden. Da es sortiert werden kann, gibt es viele Anwendungsszenarien xx Benutzern, denen es gefallen hat, verzögerte Warteschlangen usw.

Bitmap Der Vorteil von Bitmap besteht darin, Platz zu sparen, insbesondere bei der Erstellung einiger Statistiken, z. B. beim Zählen, wie viele Benutzer sich an einem bestimmten Tag angemeldet haben und ob sich ein bestimmter Benutzer angemeldet hat. Wenn Sie Bitmap nicht verwenden, Vielleicht haben Sie darüber nachgedacht, set zu verwenden.

SADD day 1234//签到就添加到集合
SISMEMBER day 1234//判断1234是否签到
SCARD day   //有多少个签到的

Set ist funktional zufriedenstellend, aber im Vergleich zu Bitmaps verbraucht Set hauptsächlich eine Ganzzahlsammlung oder eine Ganzzahlsammlung, die im Allgemeinen nur verwendet wird Weniger als 512 Elemente, und die Elemente müssen alle ganze Zahlen sein. Bei Mengen sind die Daten von ganzzahligen Mengen kompakter und im Speicher kontinuierlich. Die Abfrage kann nur eine binäre Suche sein und die Zeitkomplexität beträgt O(logN). Die Hashtabelle hier ist jedoch dieselbe wie die Hashtabelle in den fünf Hauptdatentypen von Redis, außer dass der Wert auf Null zeigt und kein Konflikt vorliegt, da es sich um eine Sammlung handelt Rehash-bezogene Probleme müssen berücksichtigt werden. Ok, es ist ein bisschen weit. Wenn es viele Benutzer gibt, wird set definitiv hashtable verwenden. Tatsächlich ist jedes Element eine dictEntry-Struktur Struktur, du kannst Was siehst du? Obwohl die Werte Union (kein Wert) und Next (kein Konflikt) leer sind, benötigt die Struktur selbst Platz und einen Schlüssel. Dieser belegte Platz ist real, und wenn Sie eine Bitmap verwenden, reicht ein Bit. Es stellt eine Zahl dar und spart Platz. Schauen wir uns an, wie man Bitmaps einrichtet und zählt.

typedef struct dictEntry {
    // 键
    void *key;
    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下个哈希表节点，形成链表
    struct dictEntry *next;

} dictEntry;

Dies ist der Bloom-Filter, den RedisBloom nach Redis4.0 unterstützt, aber das entsprechende Modul muss separat geladen werden. Natürlich können wir auch unseren eigenen Bloom-Filter basierend auf der obigen Bitmap implementieren, da Redis dies jedoch bereits unterstützt it Ja, wir können unsere Entwicklungszeit durch RedisBloom verkürzen. Ich werde hier nicht näher auf die Verwendung von RedisBloom eingehen.

SETBIT day 1234 1//签到
GETBIT day 1234//判断1234是否签到
BITCOUNT day//有多少个签到的

kann für Statistiken verwendet werden. Sein Vorteil besteht darin, dass es nur 12 KB Speicher benötigt, um 2^64 Elemente zu zählen. Tatsächlich handelt es sich hauptsächlich um Kardinalitätsstatistiken wie UV. Funktionell kann UV mit Set oder Hash gespeichert werden. Der Nachteil besteht jedoch darin, dass es Speicherplatz verbraucht und leicht zu einem großen Schlüssel werden kann Kann auch verwendet werden, 12 KB Die räumliche Bitmap kann nur 12 * 1024 * 8 = 98304 Elemente zählen, während HyperLogLog 2 ^ 64 Elemente zählen kann. Allerdings weist HyperLogLog tatsächlich Fehler auf, die auf der Wahrscheinlichkeit und dem Standardfehler basieren Die Berechnungsrate beträgt 0,81 %. In Szenarien, in denen große Datenmengen gezählt werden und die Genauigkeitsanforderungen nicht so hoch sind, ist HyperLogLog immer noch sehr gut darin, Platz zu sparen.

PFADD uv 1 2 3 //1 2 3是活跃用户
PFCOUNT uv //统计

GEO 是可以应用在地理位置的业务上，比如微信附近的人或者附近的车辆等等，先来看一下如果没有GEO 这种数据结构，你如何知道你附近的人？首先得上报自己的地理位置信息吧，比如经度 116.397128，纬度 39.916527，此时可以用 string、hash 数据类型存储，但是如果要查找你附近的人，string 和 hash 这种就无能为例了，你不可能每次都要遍历全部的数据来判断，这样太耗时了，当然你也不可能通过 zset 这种数据结构来把经纬度信息当成权重，但是如果我们能把经纬度信息通过某种方式转换成一个数字，然后当成权重好像也可以，这时我们只需通过zrangebyscore key v1 v2也可以找到附近的人。真的需要这么麻烦吗？于是 GEO 出现了，GEO 转换经纬度为数字的方法是“二分区间，区间编码”，这是什么意思呢？以经度为例，它的范围是[-180,180]，如果要采用3位编码值，那么就是需要二分3次，二分后落在左边的用0表示，右边的用1表示，以经度是121.48941 来说，第一次是在[0,180]这个区间，因此记1，第二次是在[90,180]，因此再记1，第三次是在[90,135]，因此记0。纬度也是同样的逻辑，假设此时对应的纬度编码后是010，最后把经纬度合并在一起，需要注意的是经度的每个值在偶数位，纬度的每个值在奇数位。

1 1 0   //经度
 0 1 0  //纬度
------------
101100 //经纬度对应的数值

原理是这样，我们再来看看 redis 如何使用 GEO：

GEOADD location 112.123456 41.112345 99 //上报用户99的地理位置信息
GEORADIUS location  112.123456 41.112345 1 km ASC COUNT 10 //获取附近1KM的人

搞懂集群

生产环境用单实例 redis 的应该比较少，单实例的风险在于：

• 单点故障即服务故障，没有backup

• 单实例压力大，又要提供读，又要提供写

于是我们首先想到的就是经典的主从模式，而且往往是一主多从，这是因为大部分应用都是读多写少的情况，我们的主负责更新，从负责提供读，就算我们的主宕机了，我们也可以选择一个从来充当主，这样整个应用依然可以提供服务。

复制过程的细节

当一个 redis 实例首次成为某个主的从的时候，这时主得把数据发给它，也就是 rdb 文件，这个过程 master 是要 fork 一个子进程来处理的，这个子进程会执行 bgsave 把当前的数据重新保存一下，然后准备发给新来的从，bgsave 的本质是读取当前内存中的数据然后保存到 rdb 文件中，这个过程涉及大量的 IO，如果直接在主进程中来处理的话，大概率会阻塞正常的请求，因此使用个子进程是个明智的选择。

那 fork 的子进程在 bgsave 过程中如果有新的变更请求会怎么办？

严格来说子进程出来的一瞬间，要保存的数据应该就是当时那个点的快照数据，所以是直接把当时的内存再复制一份吗？不复制的话，如果这期间又有变更改怎么办？其实这要说到写实复制（COW）机制，首先从表象上来看内存是一整块空间，其实这不太好维护，因此操作系统会把内存分成一小块一小块的，也就是内存分页管理，一页的大小一般是4K、8K或者16K等等，redis 的数据都是分布在这些页面上的，出于效率问题，fork 出来的子进程是和主进程是共享同一块的内存的，并不会复制内存，如果这期间主进程有数据变更，那么为了区分，这时最快捷的做法就是把对应的数据页重新复制一下，然后主的变更就在这个新的数据页上修改，并不会修改来的数据页，这样就保证了子进程处理的还是当时的快照。

以上说的变更是从快照的角度来考虑的，如果从数据的一致性来说，当快照的 rdb 被从库应用之后，这期间的变更该如何同步给从库？答案是缓冲区，这个缓冲区叫做 replication buffer，主库在收到需要同步的命令之后，会把期间的变更都先保存在这个缓冲区中，这样在把 rdb 发给从库之后，紧接着会再把 replication buffer 的数据也发给从库，最终主从就保持了一致。

replication buffer不是万能的补给剂

我们来看看 replication buffer 持续写入的时间有多长。

• 我们知道主从同步的时候，主库会执行 fork 来让子进程完成相应地工作，因此子进程从开始执行 bgsave 到执行完毕这期间，变更是要写入 replication buffer 的。

• rdb 生成好之后，需要把它发送给从库，这个网络传输是不是也需要耗点时间，这期间也是要写入 replication buffer 的。

• Nach dem Empfang der RDB muss die Slave-Bibliothek die RDB auf den Speicher anwenden. Während dieser Zeit ist die Slave-Bibliothek blockiert und kann keine Dienste bereitstellen, sodass in dieser Zeit auch der Replikationspuffer geschrieben werden muss.

Da es sich beim Replikationspuffer um einen Puffer handelt, ist seine Größe begrenzt. Wenn einer der oben genannten drei Schritte lange dauert, führt dies dazu, dass der Replikationspuffer schnell anwächst (vorausgesetzt, es finden normale Schreibvorgänge statt). Wenn der Puffer den Grenzwert überschreitet, wird die Verbindung zwischen der Master-Datenbank und der Slave-Datenbank getrennt. Wenn die Verbindung zur Slave-Datenbank erneut hergestellt wird, wird die Replikation neu gestartet und die gleichen langen Replikationsschritte werden wiederholt Die Größe des Replikationspuffers ist immer noch sehr kritisch und muss im Allgemeinen anhand von Faktoren wie Schreibgeschwindigkeit, Schreibmenge pro Sekunde und Netzwerkübertragungsgeschwindigkeit umfassend beurteilt werden.

Was soll ich tun, wenn das Netzwerk der Slave-Datenbank nicht in Ordnung ist und die Verbindung zur Master-Datenbank getrennt ist?

Normalerweise können nachfolgende Änderungen an der Master-Datenbank direkt an die Slave-Datenbank gesendet werden, um direkt von der Slave-Datenbank wiedergegeben zu werden, solange die Verbindung zwischen Master und Slave hergestellt ist. Wir können jedoch nicht garantieren, dass die Netzwerkumgebung vorhanden ist 100 % reibungslos, daher muss auch das Trennungsproblem zwischen der Slave-Datenbank und der Master-Datenbank berücksichtigt werden.

Es sollte so sein, dass vor Redis2.8 die Hauptdatenbank direkt und gedankenlos eine vollständige Synchronisierung durchführte, solange die Slave-Datenbank auch nur für kurze Zeit getrennt war und die Slave-Datenbank später wieder verbunden wurde. In Version 2.8 und höher wird die inkrementelle Replikation unterstützt, da ein Puffer zum Speichern der Änderungen vorhanden sein muss. Dieser Puffer wird logischerweise als Ringpuffer bezeichnet , wird es von Anfang an überschrieben, daher gibt es auch eine Größenbeschränkung. Wenn die Slave-Bibliothek die Verbindung wiederherstellt, teilt die Slave-Bibliothek der Hauptbibliothek mit: „Ich habe an den Speicherort xx kopiert.“ Nachdem die Hauptbibliothek die Nachricht von der Slave-Bibliothek erhalten hat, beginnt sie zu prüfen, ob die Daten am Speicherort xx noch vorhanden sind Wenn ja, senden Sie die Daten einfach nach xx an die Slave-Bibliothek. Wenn sie nicht vorhanden sind, können Sie nichts tun und nur eine vollständige Synchronisierung durchführen. repl_backlog_buffer

Erfordert einen Manager