0×01 Avant-propos
Redis est une base de données de valeurs-clés de type journal open source écrite en langage ANSI C, prend en charge le réseau, peut être basée sur la mémoire et persistante, et fournit des API dans plusieurs langues.
De nos jours, les données commerciales sur Internet croissent à un rythme plus rapide et les types de données deviennent de plus en plus abondants, ce qui met en avant des exigences plus élevées en matière de vitesse et de capacités de traitement des données. Redis est une base de données non relationnelle en mémoire open source qui apporte une expérience disruptive aux développeurs. Conçue du début à la fin dans un souci de hautes performances, Redis est la base de données NoSQL la plus rapide disponible aujourd'hui.
Tout en considérant la haute performance, la haute disponibilité est également une considération très importante. Internet fournit un service ininterrompu 7×24 et un basculement à la vitesse la plus rapide en cas de panne, ce qui peut entraîner des pertes minimes pour l'entreprise.
Alors, quelles sont les architectures à haute disponibilité dans les applications pratiques ? Quels sont les avantages et les inconvénients entre les architectures ? Comment devrions-nous choisir ? Quelles sont les bonnes pratiques ?
0×02 Principe Sentinelle
Avant d'expliquer la solution de haute disponibilité Redis, jetons d'abord un œil au Principe de Redis Sentinel.
- Le cluster Sentinel découvre le maître via le fichier de configuration donné et surveille le maître lors de son démarrage. Obtenez tous les serveurs esclaves sous ce serveur en envoyant des informations au maître.
- Le cluster Sentinel envoie des informations de bonjour (une fois par seconde) aux serveurs maître et esclave surveillés via des connexions de commande. Ces informations incluent l'adresse IP, le port, l'identifiant de Sentinel, etc., afin d'annoncer son existence aux autres Sentinels.
- Le cluster Sentinel reçoit les informations de bonjour envoyées par d'autres Sentinels via des connexions d'abonnement pour découvrir d'autres Sentinels surveillant le même serveur maître ; les clusters créeront des connexions de commande entre eux pour la communication, car il existe déjà des serveurs maître-esclave comme expéditeurs. Non une connexion d'abonnement sera créée entre Sentinel et l'intermédiaire qui reçoit les informations hello.
- Le cluster Sentinel utilise la commande ping pour détecter l'état de l'instance. S'il n'y a pas de réponse dans le délai spécifié (arrêt après millisecondes) ou si une réponse incorrecte est renvoyée, l'instance est considérée comme hors ligne.
- Lorsque le basculement actif/veille est déclenché, le basculement ne se déroulera pas immédiatement. La majorité des Sentinelles du Sentinel doivent être autorisées avant que le basculement puisse être effectué. obtenir l'autorisation du quorum Sentinels désigné, entrer dans l'état ODOWN après succès. Par exemple, si 2 quorums sont configurés parmi 5 Sentinels, le basculement sera exécuté lorsque les 2 Sentinels penseront que le maître est mort.
- Sentinel envoie la commande SLAVEOF NO ONE à l'esclave sélectionné comme maître. La condition de sélection de l'esclave est que Sentinel triera d'abord les esclaves selon leurs priorités. Si les priorités sont les mêmes, vérifiez l'indice de réplication, celui qui reçoit le plus de données de réplication du maître sera classé en premier. Si la priorité et l'index sont identiques, celui avec l'ID de processus le plus petit est sélectionné.
- Une fois Sentinel autorisé, il obtiendra le dernier numéro de version de configuration (config-epoch) du maître défaillant. Une fois l'exécution du basculement terminée, ce numéro de version sera utilisé pour la dernière configuration via la diffusion Notifier les autres Sentinels dans. le formulaire, et d'autres Sentinels mettent à jour la configuration du maître correspondant.
1 à 3 sont des mécanismes de découverte automatique :
- Envoyez la commande d'information au maître surveillé toutes les 10 secondes et obtenez les informations actuelles du maître en fonction de la réponse.
- Envoyez des commandes PING à tous les serveurs Redis, y compris Sentinel, à une fréquence de 1 seconde, et déterminez si le serveur est en ligne grâce à la réponse.
- Envoyer le message d'information du maître Sentinel actuel à tous les serveurs maîtres et esclaves surveillés à une fréquence de 2 secondes.
4 est le mécanisme de détection, 5 et 6 sont des mécanismes de basculement et 7 est le mécanisme de configuration de mise à jour. [1]
0×03 Architecture haute disponibilité Redis
Après avoir expliqué le principe de Redis Sentinel, expliquons l'architecture haute disponibilité Redis couramment utilisée.
- Cluster Redis Sentinel + DNS intranet + script personnalisé
- Redis Sentinel Cluster + VIP + Script personnalisé
- Encapsulez le client pour vous connecter directement au port Redis Sentinel
- JedisSentinelPool, adapté à Java
- PHP est auto-emballé basé sur PHPredis
- Redis Sentinel Cluster + Keepalived/Haproxy
- Redis M/S + Keepalived
- Cluster Redis
- Twemproxy
- Codis
Ce qui suit sera expliqué un par un avec des images et du texte.
3.1 Cluster Redis Sentinel + DNS Intranet + Script personnalisé
L'image ci-dessus est une solution qui a été appliquée dans un environnement en ligne. La couche inférieure est le cluster Redis Sentinel, qui agit comme agent pour le maître et l'esclave Redis. Le côté Web se connecte au DNS intranet pour fournir des services. Le DNS intranet est attribué selon certaines règles, telles que xxxx.redis.cache/queue.port.xxx.xxx Le premier segment indique l'abréviation de l'entreprise, le deuxième segment indique qu'il s'agit du nom de domaine intranet Redis et le le troisième segment représente le type Redis, le cache représente le cache, la file d'attente représente la file d'attente, le quatrième segment représente le port Redis et les cinquième et sixième segments représentent le nom de domaine principal de l'intranet.
Lorsque le nœud maître échoue, comme une panne de machine, une panne de nœud Redis ou une inaccessibilité du réseau, le cluster Sentinel appellera le script configuré client-reconfig-script pour modifier le nom de domaine intranet du port correspondant. Le nom de domaine intranet du port correspondant pointe vers le nouveau nœud maître Redis.
Avantages :
- Commutation de deuxième niveau, effectuez toute l'opération de commutation en 10 secondes
- Personnalisation du script et architecture contrôlable
- Transparent à l'application, le front-end n'a pas à se soucier des changements dans le back-end
Inconvénients :
- Le coût de maintenance est légèrement élevé. Il est recommandé d'investir dans plus de 3 machines pour le cluster Redis Sentinel
- Dépend du DNS, il y a un délai de résolution
- Le service en mode Sentinelle sera indisponible pendant une courte période
- Cette solution ne peut pas être utilisée si le service est accessible via le réseau externe
3.2 Redis Sentinel Cluster + VIP + Script personnalisé
Ce plan est légèrement différent du précédent. La première solution utilise le DNS intranet et la seconde solution remplace le DNS intranet par une IP virtuelle. La couche inférieure est le cluster Redis Sentinel, qui agit comme un agent pour le maître et l'esclave Redis, et le côté Web fournit des services via VIP. Lors du déploiement maître-esclave Redis, vous devez lier l'adresse IP virtuelle au nœud maître Redis actuel. Lorsque le nœud maître échoue, comme une panne de machine, une panne de nœud Redis ou une inaccessibilité du réseau, le cluster Sentinel appellera le script configuré par client-reconfig-script pour faire flotter le VIP vers le nouveau nœud maître.
Avantages :
- Commutation de deuxième niveau, effectuez toute l'opération de commutation en 5 secondes
- Personnalisation du script et architecture contrôlable
- Transparent à l'application, le front-end n'a pas à se soucier des changements dans le back-end
Inconvénients :
- Le coût de maintenance est légèrement élevé. Il est recommandé d'investir dans plus de 3 machines pour le cluster Redis Sentinel
- L'utilisation de VIP augmente les coûts de maintenance et risque le chaos IP
- Le service en mode Sentinelle sera indisponible pendant une courte période
3.3 Encapsuler le client pour se connecter directement au port Redis Sentinel
部分业务只能通过外网访问 Redis，上述两种方案均不可用，于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口，然后通过这个端口获取到当前的主节点，然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是，Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。如果前端业务使用 Java，有 JedisSentinelPool 可以复用；如果前端业务使用 PHP，可以在 phpredis 的基础上做二次封装。
优点：
缺点：
- 依赖客户端支持 Sentinel
- Sentinel 服务器和 Redis 节点需要开放访问权限
- 对应用有侵入性
3.4 Redis Sentinel 集群 + Keepalived/Haproxy
底层是 Redis Sentinel 集群，代理着 Redis 主从，Web 端通过 VIP 提供服务。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Redis 之间的切换通过 Redis Sentinel 内部机制保障，VIP 切换通过 Keepalived 保障。
优点：
缺点：
- 维护成本高
- 存在脑裂
- Sentinel 模式存在短时间的服务不可用
3.5 Redis M/S + Keepalived
此方案没有使用到 Redis Sentinel。此方案使用了原生的主从和 Keepalived，VIP 切换通过 Keepalived 保障，Redis 主从之间的切换需要自定义脚本实现。
优点：
缺点：
3.6 Redis Cluster
From: http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster
Redis 3.0.0 在 2015 年 4 月 2 日正式发布，距今已有两年多的时间。Redis 集群采用 P2P 模式，无中心化。把 key 分成 16384 个 slot，每个实例负责一部分 slot。客户端请求对应的数据，若该实例 slot 没有对应的数据，该实例会转发给对应的实例。另外，Redis 集群通过 Gossip 协议同步节点信息。
优点：
- 组件 all-in-box，部署简单，节约机器资源
- 性能比 proxy 模式好
- 自动故障转移、Slot 迁移中数据可用
- 官方原生集群方案，更新与支持有保障
缺点：
- 架构比较新，最佳实践较少
- 多键操作支持有限（驱动可以曲线救国）
- 为了性能提升，客户端需要缓存路由表信息
- 节点发现、reshard 操作不够自动化
3.7 Twemproxy
From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster
Multiple isomorphic Twemproxy (same configuration) works at the same time, accepts client requests, and forwards them to the corresponding Redis according to the hash algorithm.
Twemproxy solution is relatively mature. Our team has used this solution for a long time, but the effect is not very satisfactory. On the one hand, the positioning problem is more difficult, and on the other hand, its support for automatically eliminating nodes is not very friendly.
Advantages:
- Easy to develop and almost transparent to the application
- Long history and mature solutions
Disadvantages:
- Proxy affects performance
- LVS and Twemproxy will have node performance bottlenecks
- Redis expansion is very troublesome
- Twitter has abandoned the use of this solution internally, and the new architecture is not open source
3.8 Codis
From: https://github.com/CodisLabs/codis
Codis is an open source product by Wandoujia and involves many components. Among them, ZooKeeper stores routing tables and proxy node metadata, and distributes Codis-Config commands; Codis-Config is an integrated management tool with a Web interface for use; Codis-Proxy is A stateless proxy compatible with the Redis protocol; Codis-Redis is a secondary development based on Redis 2.8 version, adding slot support to facilitate data migration.
Advantages:
- Easy to develop and almost transparent to the application
- Performance is better than Twemproxy
- Has a graphical interface, easy expansion, and convenient operation and maintenance
Disadvantages:
- Proxy still affects performance
- Too many components, requiring a lot of machine resources
- The Redis code has been modified, resulting in the inability to synchronize with the official, and the follow-up of new features is slow
- The development team is preparing to promote reborndb based on Redis transformation
0×04 Best Practices
The so-called best practices are practices that are most suitable for specific scenarios.
We mainly recommend the following plans:
- Redis Sentinel cluster + intranet DNS + custom script
- Redis Sentinel Cluster + VIP + Custom Script
The following are the best practices summarized during actual combat:
- Redis Sentinel cluster is recommended to use >= 5 machines
- Different large businesses can use a Redis Sentinel cluster to proxy all ports under the business
- Divide the Redis port range according to different businesses
- Custom scripts are recommended to be implemented in Python for easy expansion
- Custom scripts need to pay attention to determine the current Sentinel role
- Pass in the parameters of the custom script:
- Custom scripts require remote ssh to operate the machine. It is recommended to use the paramiko library to avoid repeatedly establishing SSH connections and consuming time
- To accelerate SSH connection, it is recommended to turn off the following two parameters
- UseDNS no
- GSSAPIAuthentication no
- If you receive an alert via WeChat or email, it is recommended to fork a process to avoid blocking the main process
- Automatic switching and failover, it is recommended that all operations be completed within 15s
0×05 Summary
This event shared the necessity of Redis high availability, the Sentinel principle, the common architecture of Redis high availability and the best practices summarized in the actual combat process. I hope it will be helpful to readers. If you need follow-up communication, you can add me WeChat (Wentasy), or send an email to: dbarobinwen@gmail.com
Attached PPT download: https://github.com/dbarobin/slides
Video Playback: Best Practices for Redis High Availability Architecture
0×06 Thanks
Thank you to Tingyun and Operation and Maintenance Gang for their careful organization, and thank you to everyone who came to participate in this event despite the heavy rain. This sharing was videotaped by the IT guru, and I would like to thank the IT guru for his technical support.
0×07 Reference
[1] jyzhou (2016-06-12). Redis 复制、Sentinel 的搭建和原理说明. Retrieved from http://www.cnblogs.com/zhoujinyi/p/5570024.html.
以上是Redis 高可用性实践的详细内容。更多信息请关注PHP中文网其他相关文章！
