大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
redis是一款面向分布式的NOSQL产品,天生对主备模式有很好的支持,而且配置一套完整的主备模式,非常简单。针对redis,主备模式配置非常简单,但线上意义重大。
公司主营业务:成都做网站、网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。成都创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联公司推出象山免费做网站回馈大家。
主要内容
1.CAP理论
2.简单redis的复制原理
3.redis replaction相关配置参数解析
4.配置星型模型主备模式
5.配置有向无欢模型主备模式
1.研磨redis的复制与集群概念
redis的复制与集群,刚开始我把两者闹了个误会,在不断深入学习过程中及时改正了。
简单区分一下。
redis复制:可以理解为把redis服务copy多份,供客户端访问。但服务器间持有的数据时一样的。可以类比下oracle的RAC,和MySQL数据库中的主备模式。主要解决redis服务的可靠性,扩展性上。
redis集群:集群主要解决大数据量问题。一个机器内存和存储往往是有限的,但数据量的增长往往是“无限”的,可以使用集群,将数据分散到多个redis服务中。如果你能想到memcached的一致性哈希算法,那就对了。
不管redis 复制核集群,都会涉及到节点信息的同步,不得不要受到CAP理论的影响。
2.CAP理论介绍
CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
一致性(Consistence) (等同于所有节点访问同一份最新的数据副本)
可用性(Availability)(对数据更新具备高可用性)
容忍网络分区(Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择[3]。)
根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项[4]。
redis 的设计和配置,也是在尽量解决CAP引起的问题,但不可能彻底决绝,只能在三者中进行平衡。
3.Redis复制概论
数据库复制指的是发生在不同数据库实例之间,单向的信息传播的行为,通常由被复制方和复制方组成,被复制方和复制方之间建立网络连接,复制方式通常为被复制方主动将数据发送到复制方,复制方接收到数据存储在当前实例,最终目的是为了保证双方的数据一致、同步。
复制示意图
Redis的复制方式有两种,一种是主(master)-从(slave)模式,一种是从(slave)-从(slave)模式,因此Redis的复制拓扑图会丰富一些,可以像星型拓扑,也可以像个有向无环:
Redis集群复制结构图
通过配置多个Redis实例独立运行、定向复制,形成Redis集群(这儿集群的概念是广义上的概念),master负责写、slave负责读。
通过复制,可以达成以下目标
1、高可用性(如果master宕机,slave可以介入并取代master的位置)
2、高性能(主备分离,分担master压力)
3、水平扩展性(按二八定律,增加slave机器可以横向(水平)扩展Redis服务的整个查询服务的能力)
带来的问题:
1.同步开销
2.数据不一致性问题
3.编程复杂
4.redis replaction相关配置参数解析
slaveof | #设置该数据库为其他数据库的从数据库时启用该参数。 #设置当本机为slave服务时,设置 master 服务的 IP 地址及端口,在 Redis 启动时,它会自动从 master 进行数据同步 |
slave-serve-stale-data yes | #当从库同主机失去连接或者复制正在进行,从机库有两种运行方式: #1)如果 slave-serve-stale-data 设置为 yes( 默认设置 ) ,从库会继续响应客户端的请求 #2)如果 slave-serve-stale-data 是指为 no ,出去 INFO 和 SLAVOF 命令之外的任何请求都会返回一个错误 "SYNC with master in progress" |
slave-read-only yes | #配置 slave 实例是否接受写。写 slave 对存储短暂数据(在同 master数据同步后可以很容易地被删除)是有用的,但未配置的情况下,客户端写可能会发送问题。 |
repl-ping-slave-period 10 | #从库会按照一个时间间隔向主库发送 PINGs. 可以通过 repl-ping-slave-period 设置这个时间间隔,默认是 10 秒 |
repl-timeout 60 | #repl-timeout 设置主库批量数据传输时间或者 ping 回复时间间隔,默认值是 60 秒 # 一定要确保 repl-timeout 大于 repl-ping-slave-period |
repl-diskless-sync no | 启动无磁盘复制。往备节点同步,不需要中间先生成文件再进行同步。 |
repl-diskless-sync-delay 5 | 同步前的延时, 以等待其他的要链接的slave 配置传输开始的延迟时间,以便等待更多的从服务器连接 |
repl-disable-tcp-nodelay no | #在 slave socket 的 SYNC 后禁用 TCP_NODELAY #如果选择“ yes ” ,Redis 将使用一个较小的数字 TCP 数据包和更少的带宽将数据发送到 slave , 但是这可能导致数据发送到 slave 端会有延迟 , 如果是 Linux kernel 的默认配置,会达到 40 毫秒 . #如果选择 "no",则发送数据到 slave 端的延迟会降低,但将使用更多的带宽用于复制. |
repl-backlog-size 1mb | #设置复制的backlog(后台日志)大小。 #复制的后台日志越大, slave 断开连接及后来可能执行部分复制花的时间就越长。 #后台日志在至少有一个 slave 连接时,仅仅分配一次。 |
repl-backlog-ttl 3600 | #在 master 不再连接 slave 后,后台日志将被释放。下面的配置定义从最后一个 slave 断开连接后需要释放的时间(秒).#0意味着从不释放后台日志 |
slave-priority 100 | #如果 master 不能再正常工作,那么会在多个 slave 中,选择优先值最小的一个 slave 提升为 master ,优先值为 0 表示不能提升为 master |
min-slaves-to-write 0 | 执行写操作所需的至少从服务器数量 #如果少于 N 个 slave 连接,且延迟时间 <=M 秒,则 master 可配置停止接受写操作。 #例如需要至少 3 个 slave 连接,且延迟 <=10 秒的配置:#设置 0 为禁用 |
min-slaves-max-lag 10 | 指定网络延迟的最大值 |
上面所列参数,虽然对本文涉及的内容一 一不大,但对运维和调优却非常重要。
4.配置星型模型主备模式
#为了区分,有的不需要指定,我也进行了修改。
#主(Master)节点,开启AOF,禁用RDB port 6379 pidfile /var/run/redis_6379.pid logfile "redis6379.log" save 900 1 save 300 10 save 60 10000 save "" dbfilename dump6379.rdb appendonly yes appendfilename "appendonly6379.aof" ------------------------------------------------ #备(Slaver1)节点,开启RDB,禁用AOF port 6380 pidfile /var/run/redis_6380.pid save 900 1 save 300 10 save 60 10000 dbfilename dump6380.rdb logfile "redis6380.log" appendonly no appendfilename "appendonly6380.aof" slaveof 127.0.0.1 6379 ---------------------------------------------------- #备(Slaver2)节点,禁用RDB,禁用AOF port 6381 pidfile /var/run/redis_6381.pid logfile "redis6381.log" save 900 1 save 300 10 save 60 10000 save "" dbfilename dump6381.rdb appendonly no appendfilename "appendonly6381.aof" slaveof 127.0.0.1 6379 #配置完了三个配置文件,启动 [root@hadoop2 redis]# bin/redis-server redis.conf [root@hadoop2 redis]# bin/redis-server redis6380.conf [root@hadoop2 redis]# bin/redis-server redis6381.conf
查看Master(6379)日志
[root@hadoop2 redis]# cat redis6381.log
2925:M 03 Sep 20:53:44.398 * The server is now ready to accept connections on port 6379
2925:M 03 Sep 20:53:55.042 * Slave 127.0.0.1:6380 asks for synchronization
2925:M 03 Sep 20:53:55.042 * Full resync requested by slave 127.0.0.1:6380
2925:M 03 Sep 20:53:55.042 * Starting BGSAVE for SYNC with target: disk
2925:M 03 Sep 20:53:55.043 * Background saving started by pid 2933
2933:C 03 Sep 20:53:55.055 * DB saved on disk
2933:C 03 Sep 20:53:55.055 * RDB: 0 MB of memory used by copy-on-write
2925:M 03 Sep 20:53:55.106 * Background saving terminated with success
2925:M 03 Sep 20:53:55.106 * Synchronization with slave 127.0.0.1:6380 succeeded
2925:M 03 Sep 20:53:57.772 * Slave 127.0.0.1:6381 asks for synchronization
2925:M 03 Sep 20:53:57.772 * Full resync requested by slave 127.0.0.1:6381
2925:M 03 Sep 20:53:57.772 * Starting BGSAVE for SYNC with target: disk
2925:M 03 Sep 20:53:57.772 * Background saving started by pid 2938
2938:C 03 Sep 20:53:57.784 * DB saved on disk
2938:C 03 Sep 20:53:57.785 * RDB: 0 MB of memory used by copy-on-write
2925:M 03 Sep 20:53:57.833 * Background saving terminated with success
2925:M 03 Sep 20:53:57.833 * Synchronization with slave 127.0.0.1:6381 succeeded
查看Slave1(6380)日志
[root@hadoop2 redis]# cat redis6380.log
2930:S 03 Sep 20:53:55.041 * The server is now ready to accept connections on port 6380
2930:S 03 Sep 20:53:55.041 * Connecting to MASTER 127.0.0.1:6379
2930:S 03 Sep 20:53:55.042 * MASTER <-> SLAVE sync started
2930:S 03 Sep 20:53:55.042 * Non blocking connect for SYNC fired the event.
2930:S 03 Sep 20:53:55.042 * Master replied to PING, replication can continue...
2930:S 03 Sep 20:53:55.042 * Partial resynchronization not possible (no cached master)
2930:S 03 Sep 20:53:55.043 * Full resync from master: e82c16f8f2b7e139bcaf8b690d389d6cc4ddd972:1
2930:S 03 Sep 20:53:55.106 * MASTER <-> SLAVE sync: receiving 76 bytes from master
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Flushing old data
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Loading DB in memory
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Finished with success
查看Slave2(6381)日志
[root@hadoop2 redis]# cat redis6381.log
2935:S 03 Sep 20:53:57.771 * The server is now ready to accept connections on port 6381
2935:S 03 Sep 20:53:57.771 * Connecting to MASTER 127.0.0.1:6379
2935:S 03 Sep 20:53:57.771 * MASTER <-> SLAVE sync started
2935:S 03 Sep 20:53:57.771 * Non blocking connect for SYNC fired the event.
2935:S 03 Sep 20:53:57.771 * Master replied to PING, replication can continue...
2935:S 03 Sep 20:53:57.771 * Partial resynchronization not possible (no cached master)
2935:S 03 Sep 20:53:57.772 * Full resync from master: e82c16f8f2b7e139bcaf8b690d389d6cc4ddd972:1
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: receiving 76 bytes from master
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Flushing old data
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Loading DB in memory
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Finished with success
[root@hadoop2 redis]# cat redis6382.log
通过查看日志,可以很形象的学习底层实现过程。
测试(通过复制,修改值确认是否同步)
[root@hadoop2 redis]# bin/redis-cli -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set title "replaction" OK 127.0.0.1:6379> exit [root@hadoop2 redis]# bin/redis-cli -p 6380 127.0.0.1:6380> keys * 1) "title" 127.0.0.1:6380> get title "replaction" [root@hadoop2 redis]# bin/redis-cli -p 6381 127.0.0.1:6381> keys * 1) "title" 127.0.0.1:6381> get title "replaction" 127.0.0.1:6381> set title 111 (error) READONLY You can't write against a read only slave. 修改下值 127.0.0.1:6379> set title "replaction 1" OK 127.0.0.1:6380> get title "replaction 1" 127.0.0.1:6381> get title "replaction 1"
验证通过
5.配置有向无欢模型主备模式
基本上和星型模型主备模式,没有差别。
变更点 #备(Slaver2)节点,禁用RDB,禁用AOF slaveof 127.0.0.1 6379 改为 slaveof 127.0.0.1 6380
测试略
参考资源
http://my.oschina.net/andylucc/blog/683631