Artikel ini akan membincangkan tentang tiga mod teori redis (replikasi tuan-hamba, sentinel, kluster) dengan gambar dan teks. Saya harap ia akan membantu semua orang!
1 > Melalui fungsi kegigihan, redis memastikan data tidak akan hilang walaupun apabila pelayan dimulakan semula, kerana kegigihan akan menyimpan data dalam memori ke cakera keras, dan restart akan memuatkan data dari cakera keras , memandangkan data disimpan dalam Pada pelayan, jika pelayan mengalami masalah seperti kegagalan cakera keras, kehilangan data juga akan berlaku. Untuk mengelakkan satu titik kegagalan, amalan biasa adalah untuk meniru berbilang salinan pangkalan data dan menggunakan mereka pada pelayan yang berbeza, supaya walaupun satu pelayan gagal, pelayan lain masih boleh terus menyediakan perkhidmatan. Untuk tujuan ini, redis menyediakan fungsi replikasi , yang boleh menyegerakkan data yang dikemas kini secara automatik ke pangkalan data lain apabila data dalam satu pangkalan data dikemas kini. [Cadangan berkaitan:
Tutorial video Redis]replication
Dalam konsep replikasi, pangkalan data dibahagikan kepada dua kategori, satu ialah pangkalan data induk , dan satu lagi pangkalan data hamba
master
slave
2.1 Penjelasan terperinci tentang prinsip
Jika proses mesin Slave dimulakan, ia akan menghantar perintah
sync_command
RDB 做全量同步,AOF 做增量同步
2.2 Penyederhanaan Teori
2.3 Versi Lite Akhir
slave -> master 发送 sync command 申请同步 master 主进程 -> 调用 fork() 函数 派生 RDB 子进程进行持久化 -> 生成 RDB 文件 将 RDB 文件推送给 slaves(完成全量同步) #增量同步:使用到了 AOF 持久化(机制:将缓存数据保存到缓冲中),所以主从节点均需要开启 AOF 增量同步是通过 AOF 功能将缓存中的数据 append(追加)到缓冲中来进行 master 缓冲 -> slave 缓冲的同步 在持续性的运行过程中,也是增量持续同步的过程
2. Mod Sentry
slave -> master 发送 sync master 使用 RDB 生成 .rdb 文件(全量同步)发送给 slaves master 使用 AOF 将缓冲区数据同步给 slaves 缓冲区数据(增量)
Fungsi utama mod sentinel:
Gunakan sistem yang terdiri daripada satu atau lebih sentinel 哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题
kejadian untuk memantau nod redis dan muncul pada nod induk Sekiranya berlaku kegagalan, salah satu nod hamba boleh dinaik taraf kepada nod induk untuk failover bagi memastikan ketersediaan sistem.
集群监控:负责监控 redismaster 和 slave 进程是否正常工作 消息通知:如果某个 redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员 故障转移:如果 master node 挂掉了,会自动转移到 slave node 上 配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址
sentinel
2.1 Penjelasan terperinci tentang prinsip
Pertama sekali, maklumat nod induk dikonfigurasikan dalam fail konfigurasi Sentinel
.
sentinel
Sentinel akan Arahan INFO dihantar setiap 10 saat melalui sambungan arahan Melalui arahan INFO, nod induk akan mengembalikan maklumat run_id dan nod hambanya sendiri. PS:redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消 息,订阅者 (sub)接收消息。
通过订阅连接对服务器的 sentinel:hello
频道做了监听,所有向该频道发送的哨兵的消息都能被接受到。
解析监听到的消息,进行分析提取,就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了,更新结构体将这些哨兵节点记录下来。
向观察到的其他的哨兵节点建立命令连接(此时没有订阅连接)。
2.2 原理精简
3 个哨兵 3 个 redis
redis-cli info replication master
节点的信息 + 从节点位置2.3 思路
3. 哨兵模式下的故障迁移
① 主观下线
哨兵节点会每秒一次的频率向建立了命令连接的实例发送 PING 命令,如果在 down-after-milliseconds
毫秒内没有做出有效响应包括 PONG/LOADING/MASTERDOWN
以外的响应,哨兵就会将该实例在本结构体中的状态标记为 SRI_S_DOWN
主观下线。
② 客观下线
当一个哨兵节点发现主节点处于主观下线状态是,会向其他的哨兵节点发出询问,该节点是不是已经主观下线了。如果超过配置参数 quorum
个节点认为是主观下线时,该哨兵节点就会将自己维护的结构体中该主节点标记为 SRIO DOWN
客观下线询问命令 SENTINEL is-master-down-by-addr
。
③ master 选举
在认为主节点客观下线的情况下,哨兵节点节点间会发起一次选举,命令为 SENTINEL is-master-down-by-addr
,只是 runid 这次会将自己的 runid 带进去,希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为 leader 的情况下,会有该 leader 对故障进行迁移。
④ 故障转移
####在从节点中挑选出新的主节点 通讯正常 优先级排序 优先级相同时选择 offset 最大的 ###将该节点设置成新的主节点SLAVEOF no one,并确保在后续的INGO命令时 该节点返回状态为master ###将其他的从节点设置成从新的主节点复制,SLAVEOF命令 ###将旧的主节点变成新的主节点的从节点 PS:优缺点 #优点: 高可用,哨兵模式是基于主从模式的,所有主从模式的优点,哨兵模式都具有有;主从可以自动切换,系统更健壮,可用性更高 #缺点: redis 比较难支持在线扩容,在群集容量达到上限时在线扩容会变得很复杂
1. redis 集群的含义
主节点负责读写请求和集群信息的维护,从节点只进行主节点数据和状态信息的复制
redis 的哨兵模式基本已经可以实现高可用、读写分离,但是在这种模式每台 redis 服务器都存储相同的数据,很浪费内存资源,所以在 redis3.0 上加入了 Cluster 群集模式,实现了 redis 的分布式存储,也就是说每台 redis 节点存储着不同的内容。根据官方推荐,集群部署至少要 3 台以上的 master 节点,最好使用 3 主 3 从六个节点的模式。
Cluster 群集由多个 redis 服务器组成的分布式网络服务群集,群集之中有多个 master 主节点,每一个主节点都可读可写,节点之间会相互通信,两两相连,redis 群集无中心节点。
2. redis 集群的特点
redis sentinel
的节点故障检测和自动故障转移功能,当群集中的某个主节点下线时,群集中的其他在线主节点会注意到这一点,并且对已经下线的主节点进行故障转移redis sentinel
进行故障转移的方法基本一样,不同的是,在集群里面,故障转移是由集群中其他在线的主节点负责进行的,所以群集不必另外使用 redis sentinel
https://www.zhihu.com/question/300767410/answer/1749442787
如果在一个分布式系统中,我们从数据库中读取一个数据,然后修改保存,这种情况很容易遇到并发问题。因为读取和更新保存不是一个原子操作,在并发时就会导致数据的不正确。这种场景其实并不少见,比如电商秒杀活动,库存数量的更新就会遇到。如果是单机应用,直接使用本地锁就可以避免。如果是分布式应用,本地锁派不上用场,这时就需要引入分布式锁来解决。由此可见分布式锁的目的其实很简单,就是为了保证多台服务器在执行某一段代码时保证只有一台服务器执行。
简单来说:
现在的业务应用通常都是微服务架构,这也意味着一个应用会部署多个进程,那么多个进程如果需要修改数据库中的同一行记录时,为了避免操作乱序导致数据错误,此时就需要引入分布式锁解决问题。
为了保证分布式锁的可用性,至少要确保锁的实现要同时满足以下几点:
一般来说,实现分布式锁的方式有以下几种:
对 redis 来说注意三点,对 key 的加锁,如果请求未完成对快要过期的 key 的续期,请求完成后 key 的解锁。防止并发环境下被读取的一个 key 可能被多个请求修改,造成无效操作,资源浪费的情况。
redis 可以做为 mysql 的前置缓存数据库,redis 与 mysql 对接的方式需要配置线程池,需要定义后端 mysql 的位置( IP + port +sock 文件的位置)
redis 基础功能:用于内存/缓存的快速存储(读取)
实现的方式:
默认将数据存储在内存/缓存中 具有丰富的数据类型:string list hash set && order set 等 重要数据持久化的功能,持久化的方式:AOF RDB
单线程模式 -> 速度快的原因之一:Epoll + I/O 复用(cluster 中的 slots 哈希槽可以充当数据读、取的索引)
LRU:淘汰策略 1) 缓存中的数据进行随机淘汰 2) 缓存中被设置了过期时间的数据进行随机淘汰 3) 缓存中被设置了过期时间的数据,进行惰性删除(仅当访问到的数据过期了,才会删除) 4) 当数据持续存储过程中内存将满,会在设置了过期时间的数据中进行近期淘汰 令牌桶 + 漏桶算法:限流 Raft:选举机制,用于选举新的主节点
高热数据:命中次数高的数据 指定提高缓存内数据的命中数,最直接的可以刷脚本,访问这些数据
1. 单例服务器,服务器本身优化
硬件资源选择(系统五大资源)
以上需要计算费用成本,还需要考虑到该服务器上的服务在运行时消耗的性能比例(需要预留给系统一部分资源)
服务本身环境的选择
操作系统选择 Linux 发行版:centos ubuntu redhat server debian alphon mac SUSE
(PS:虚拟化 KVM XEN FUFE)
基于操作系统,依赖环境。选择最小化安装还是指定操作系统版本的安装 + 指定内核版本。软件是否有依赖(例如:tomcat 需要 JDK,编译需要 gcc gcc-c++ pcre …)
Pengoptimuman sumber perisian 五大负载+内核优化
(berkaitan protokol TCP, berkaitan baris gilir, penghalaan pemajuan, pengalihan semula, port, bilangan fail terbuka, had perisian dan perkakasan sistem, dll.)
2 Optimumkan perkhidmatan aplikasi pelayan tunggal itu sendiri
以 redis 为例
Baca pertama dari pemulihan permulaan Menurut dokumen tersebut, fungsi AOF perlu didayakan berdasarkan AOF (RDB lalai)
everysecond
Semasa penggunaan, anda perlu mempertimbangkan penggunaan memori (OOM)
Arah kegigihan
Semasa memastikan integriti data, fungsi kegigihan masih akan terus menghasilkan tekanan storan pada cakera (tekanan datang daripada data yang dijana oleh fail AOF dan RDB, AOF dan fail log RDB).
NFS GFS fastDFS
proses utama redis
3. Pengoptimuman kluster
4. >5. Optimumkan mengikut arah aliran data
Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Pengenalan kepada Pengaturcaraan! !
Atas ialah kandungan terperinci Mari kita bincangkan tentang teori replikasi tuan-hamba, pengawal, dan pengelompokan dalam redis [penjelasan terperinci dengan gambar dan teks]. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!