Parlons des différents types de données dans Redis et des connaissances liées aux clusters

Cet article vous présentera les différents types de données dans Redis, ainsi que les connaissances liées aux clusters, et vous aidera à comprendre les clusters. J'espère qu'il vous sera utile !

Divers types de données

string Le type est simple et pratique, et prend en charge la pré-allocation d'espace, c'est-à-dire que plus d'espace sera alloué à chaque fois, de sorte que si la chaîne devient plus longue la prochaine fois, il y aura pas besoin de demander un espace supplémentaire, bien sûr à condition qu'il reste suffisamment d'espace. [Recommandations associées : Tutoriel vidéo Redis] Le type

List peut implémenter une simple file d'attente de messages, mais veuillez noter qu'il peut y avoir une perte de message et qu'il ne prend pas en charge le mode ACK.

Hash La table est un peu comme une base de données relationnelle, mais lorsque la table de hachage devient de plus en plus grande, veillez à éviter d'utiliser des instructions telles que hgetall, car demander une grande quantité de données entraînera le blocage de Redis, donc que les frères derrière devront attendre.

set Le type d'ensemble peut vous aider à faire des statistiques. Par exemple, si vous souhaitez compter les utilisateurs actifs un certain jour, vous pouvez directement ajouter l'ID utilisateur dans l'ensemble. L'ensemble prend en charge certaines opérations intéressantes, telles que. sdiff, qui peut obtenir la différence entre les ensembles. , sunion peut obtenir l'union entre les ensembles et possède de nombreuses fonctions, mais vous devez être prudent, car les fonctions impressionnantes ont un prix. Ces opérations nécessitent des ressources CPU et IO et peuvent en provoquer. blocage, donc l'opération entre de grands ensembles Soyez prudent lorsque vous utilisez des opérations sympas.

zset peut être considérée comme l'étoile la plus brillante. Parce qu'elle peut être triée, il existe de nombreux scénarios d'application, comme le sommet. xx utilisateurs qui l'ont aimé, files d'attente retardées, etc.

bitmap L'avantage du bitmap est d'économiser de l'espace, en particulier lors de certaines statistiques, comme compter le nombre d'utilisateurs connectés un certain jour et si un certain utilisateur s'est connecté. Si vous n'utilisez pas de bitmap, vous pourriez penser à utiliser set.

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

set est fonctionnellement satisfaisant, mais par rapport au bitmap, set consomme plus d'espace de stockage. La couche inférieure de set est principalement composée d'une collection d'entiers ou d'une table de hachage qui n'est utilisée que lorsque la quantité de données est généralement très petite. moins de 512 éléments, et les éléments doivent tous être des entiers. Pour les ensembles, les données des ensembles d'entiers sont plus compactes et elles sont continues en mémoire. La requête ne peut être qu'une recherche binaire et la complexité temporelle est O(logN ), mais la table de hachage est différente. La table de hachage ici est la même que le hachage dans les cinq principaux types de données de Redis, sauf qu'il n'y a pas de valeur. La valeur pointe vers null et il n'y a pas de conflit car il s'agit d'une collection, mais elle est différente. doit être pris en compte. Ok, c'est un peu loin. Quand on parle du problème de connexion des utilisateurs, lorsqu'il y a beaucoup d'utilisateurs, une table de hachage sera certainement utilisée pour set. Dans le cas d'une table de hachage, en fait, chaque élément est une structure dictEntry.

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

} dictEntry;

De cette structure, vous pouvez Que voyez-vous ? Tout d'abord, bien que les valeurs union (pas de valeur) et next (pas de conflit) soient vides, la structure elle-même nécessite de l'espace et une clé. Cet espace occupé est réel, et si vous utilisez un bitmap, un bit suffit. Il représente un nombre et économise de l'espace. Voyons comment configurer et compter les bitmaps.

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

bf Il s'agit du filtre Bloom pris en charge par RedisBloom après redis4.0, mais le module correspondant doit être chargé séparément. Bien sûr, nous pouvons également implémenter notre propre filtre Bloom basé sur le bitmap ci-dessus, mais puisque redis le prend déjà en charge. Oui, nous pouvons réduire notre temps de développement grâce à RedisBloom. Que fait le filtre Bloom Je n'entrerai pas dans les détails ici.

# 可以通过docker的方式快速拉取镜像来玩耍
docker run -p 6379:6379 --name redis-redisbloom redislabs/rebloom:latest
docker exec -it redis-redisbloom bash
redis-cli
# 相关操作
bf.reserve sign 0.001 10000
bf.add sign 99 //99这个用户加入
bf.add exists 99//判断99这个用户是否存在

Parce que le filtre Bloom a une erreur de jugement, tous les bf prennent en charge un taux d'erreur de jugement personnalisé, 0,001 représente le taux d'erreur de jugement, 10 000 représente le nombre d'éléments que le filtre Bloom peut stocker, lorsque le nombre réel d'éléments stockés Lorsque cette valeur est dépassée, le faux le taux de positivité va augmenter.

HyperLogLog peut être utilisé pour les statistiques. Son avantage est qu'il prend très peu d'espace de stockage. Il ne nécessite que 12 Ko de mémoire pour compter 2 ^ 64 éléments. En fait, il s'agit principalement de statistiques de cardinalité, telles que UV. Fonctionnellement parlant, UV peut être stocké à l'aide d'un ensemble ou d'un hachage, mais l'inconvénient est qu'il consomme de l'espace de stockage et peut facilement devenir une grande clé si vous souhaitez économiser de l'espace, un bitmap. peut également être utilisé, 12 Ko Le bitmap spatial ne peut compter que 12*1024*8=98304 éléments, tandis que HyperLogLog peut compter 2^64 éléments. Cependant, une technologie aussi puissante compte en fait des erreurs basées sur la probabilité et l'erreur standard. calcul Le taux est de 0,81 %. Dans les scénarios où des données massives sont comptées et où les exigences de précision ne sont pas si élevées, HyperLogLog est toujours très efficace pour économiser de l'espace.

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 的。

• Après avoir reçu le rdb, la bibliothèque esclave doit appliquer le rdb à la mémoire. Pendant cette période, la bibliothèque esclave est bloquée et ne peut pas fournir de services, le tampon de réplication doit donc également être écrit pendant cette période.

Le tampon de réplication étant un tampon, sa taille est limitée. Si l'une des trois étapes ci-dessus prend du temps, le tampon de réplication augmentera rapidement (à condition qu'il y ait des écritures normales). Le tampon dépasse la limite, la connexion entre la base de données maître et la base de données esclave sera déconnectée. Après la déconnexion, si la base de données esclave est à nouveau connectée, la réplication sera redémarrée, puis les mêmes longues étapes de réplication seront répétées. tampon de réplication La taille est toujours très critique et doit généralement être évaluée de manière globale en fonction de facteurs tels que la vitesse d'écriture, la quantité d'écriture par seconde et la vitesse de transmission du réseau.

Que dois-je faire si le réseau de la base de données esclave n'est pas bon et que la base de données maître est déconnectée ?

Normalement, tant que la connexion entre le maître et l'esclave est établie, les modifications ultérieures apportées à la base de données maître peuvent être directement envoyées à la base de données esclave pour une lecture directe à partir de la base de données esclave, mais nous ne pouvons pas garantir que l'environnement réseau est à 100 % smooth. , le problème de déconnexion entre la base de données esclave et la base de données maître doit également être pris en compte.

Il devrait être qu'avant redis2.8, tant que la base de données esclave était déconnectée, même pendant une courte période, lorsque la base de données esclave était reconnectée plus tard, la base de données principale effectuait directement et sans réfléchir une synchronisation complète. Dans la version 2.8 et versions ultérieures, la réplication incrémentielle est prise en charge. Le principe de la réplication incrémentielle est qu'il doit y avoir un tampon pour sauvegarder l'enregistrement des modifications. Ce tampon est ici logiquement un tampon en anneau lorsqu'il est plein. , il sera écrasé depuis le début, il y a donc aussi une limite de taille. Lorsque la bibliothèque esclave se reconnecte, la bibliothèque esclave dira à la bibliothèque principale : « J'ai copié à l'emplacement xx. » Une fois que la bibliothèque principale a reçu le message de la bibliothèque esclave, elle commence à vérifier si les données à l'emplacement xx sont toujours présentes. dans le repl_backlog_buffer. Si c'est le cas, envoyez simplement les données après xx à la bibliothèque esclave. Si elles n'y sont pas, vous ne pouvez rien faire et vous ne pouvez effectuer à nouveau une synchronisation complète. repl_backlog_buffer

Nécessite un gestionnaire

En mode maître-esclave, si la base de données principale raccroche, nous pouvons mettre à niveau une base de données esclave vers la base de données principale, mais ce processus est manuel et repose sur une opération manuelle, ce qui ne peut pas réduire la perte À tout le moins, vous avez toujours besoin d'un ensemble de mécanismes de gestion et d'élection automatiques. C'est

Sentinel lui-même est également un service, mais il ne traite pas la lecture et l'écriture des données, il est uniquement responsable de la gestion de toutes. instances redis. Sentinel est envoyé de temps en temps. Le temps communiquera avec chaque redis (opération ping). Chaque instance redis peut exprimer sa position tant qu'elle répond à temps dans le délai spécifié. Bien sûr, le Sentinel lui-même peut être en panne ou le réseau n'est pas disponible, donc généralement le Sentinel construira également un cluster Sentinel. Il est préférable d'avoir un nombre impair de clusters, par exemple 3 ou 5. Le but du nombre impair est. principalement pour les élections. (La minorité obéit à la majorité).

Lorsqu'une sentinelle ne reçoit pas pong à temps après le lancement d'un ping, l'instance redis sera marquée hors ligne. À ce moment, elle n'est toujours pas vraiment hors ligne. À ce moment, d'autres sentinelles détermineront également si la sentinelle actuelle est hors ligne. .Vraiment hors ligne, lorsque la plupart des sentinelles déterminent que le redis est hors ligne, elles l'expulseront du cluster. S'il s'agit d'une base de données esclave qui est hors ligne, alors ce n'est pas grave. S'il s'agit de la base de données principale. , alors c'est OK. La base de données déclenche également une élection, et l'élection n'est pas une élection aveugle. Il faut sélectionner celle qui est la plus appropriée pour servir de nouvelle base de données principale. Cette bibliothèque la plus adaptée pour servir de bibliothèque principale sera généralement déterminée en fonction des priorités suivantes :

• Poids Chaque bibliothèque esclave peut effectivement définir un poids. La bibliothèque esclave ayant un poids plus élevé sera priorisée

.
• Copie La progression de la copie à partir de chaque base de données esclave peut être différente. Donnez la priorité à l'ID du service avec la plus petite différence entre les données actuelles et celles de la base de données principale. En fait, chaque instance Redis a son propre ID si les conditions ci-dessus sont remplies. De même, la bibliothèque avec le plus petit ID sera sélectionnée pour servir de bibliothèque principale

• Une évolutivité horizontale plus forte

Le mode maître-esclave résout le problème du point de défaillance unique et la technologie de séparation lecture-écriture permet le support d'application plus fort. Le mode Sentinel peut superviser automatiquement le cluster, réaliser une sélection automatique du maître et supprimer automatiquement les nœuds défaillants.

Normalement, tant que la pression de lecture augmente, nous pouvons ajouter des bibliothèques esclaves pour l'alléger. Mais que se passe-t-il si la pression sur la bibliothèque principale est très élevée ? Cela nous amène à la technologie sharding

dont nous parlerons ensuite. Il nous suffit de découper la bibliothèque principale en plusieurs morceaux et de les déployer sur différentes machines. Ce sharding est le concept de

slots

dans redis. Lors du sharding, redis sera divisé en 0~16383 par défaut, soit un total de 16384 emplacements. Ensuite, ces emplacements sont répartis uniformément sur chaque nœud de sharding pour charger le rôle d'équilibre. . A quel emplacement doit-on attribuer chaque touche ? L'essentiel est d'utiliser d'abord CRC16 pour obtenir un numéro de 16 bits, puis d'utiliser ce numéro modulo 16384 :

crc16(key)%16384

然后客户端会缓存槽信息，这样每当一个 key 到来时，只要通过计算就知道该发给哪个实例来处理来了。但是客户端缓存的槽信息并不是一成不变的，比如在增加实例的时候，这时候会导致重新分片，那么原来客户端缓存的信息就会不准确，一般这时候会发生两个常见的错误，严格来说也不是错误，更像一种信息，一个叫做MOVED，一个叫做ASK。moved的意思就说，原来是实例A负责的数据，现在被迁移到了实例B，MOVED 代表的是迁移完成的，但是 ASK 代表的是正在迁移过程中，比如原来是实例A负责的部分数据，现在被迁移到了实例B，剩下的还在等待迁移中，当数据迁移完毕之后 ASK 就会变成 MOVED，然后客户端收到 MOVED 信息之后就会再次更新下本地缓存，这样下次就不会出现这两个错误了。

更多编程相关知识，请访问：编程入门！！

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!