高性能网站架构设计之缓存篇(4)- 主从复制

Redis 的主从复制配置非常容易,但我们先来了解一下它的一些特性。

  1. redis 使用异步复制。从 redis 2.8 开始,slave 也会周期性的告诉 master
    现在的数据量。可能只是个机制,用途应该不大。

  2. 一个 master 可以拥有多个 slave,废话,这也是业界的标配吧。

  3. slave 可以接收来自其他 slave 的连接。意思是不是就是说 slave 在接收其他的slave的连接之后成为 master
    ?等下我们来验证。

  4. redis 复制在 master 这一端是非阻塞的,也就是说在和 slave 同步数据的时候,master
    仍然可以执行客户端的操作命令而不受其影响。这点都不能保证,要你干嘛?

  5. redis 复制在 slave 这一端也是非阻塞的。在配置文件里面有 slave-serve-stale-data 这一项,如果它为 yes
    ,slave 在执行同步时,它可以使用老版本的数据来处理查询请求,如果是 no ,slave 将返回一个错误。在完成同步后,slave
    需要删除老数据,加载新数据,在这个阶段,slave 会阻止连接进来。

  6. Replication can be used both for scalability, in order to have multiple
    slaves for read-only queries (for example, heavy SORT operations
    can be offloaded to slaves), or simply for data redundancy.这句话我也没理解什么意思。

  7. 使用复制可以避免 master 因为需要把全部的数据集写入磁盘而造成的开销,因此可以把 master 中 save
    配置项全部注释掉,不让它进行保存,然后配置 slave ,让 slave 保存。虽然有这个特性,但是我们好像一般不这么做。

好吧,我们做几个例子练习一下。

先打开三个终端,然后起三个实例,分别用三个 client 去连接它们:

zhaoguihuadediannao:src zhaogh$
./redis-server --port 10000 --daemonize yes

zhaoguihuadediannao:src
zhaogh$

zhaoguihuadediannao:src zhaogh$
./redis-cli -p 10000

端口10000的做 master。

slave 01:

zhaoguihuadediannao:src zhaogh$
./redis-server --port 10001 --daemonize yes

zhaoguihuadediannao:src
zhaogh$

zhaoguihuadediannao:src zhaogh$
./redis-cli -p 10001

slave 02:

zhaoguihuadediannao:src zhaogh$
./redis-server --port 10002 --daemonize yes

zhaoguihuadediannao:src
zhaogh$

zhaoguihuadediannao:src zhaogh$
./redis-cli -p 10002

上面只是让它们的实例启动了并用客户端去连接它,并没有设置主从关系。在 slave 01 和 slave 02
上执行下面的命令:

127.0.0.1:10001> slaveof 127.0.0.1
10000

OK

127.0.0.1:10001>

这样就设置好了主从关系。我们来试试有没有效果。

127.0.0.1:10001> get testkey001

(nil)

127.0.0.1:10001>

这个时候是没有值的。

master 上执行:

127.0.0.1:10000> set testkey001
testvalue001

OK

127.0.0.1:10000>

然后看看 slave 上有没有:

127.0.0.1:10001> get testkey001

"testvalue001"

127.0.0.1:10001>

127.0.0.1:10002> get testkey001

"testvalue001"

127.0.0.1:10002>

有了,是不是比***点读机还 easy ?已经有了感性的认识,我们来介绍一下它的原理吧。

当你设置了主从关系后,slave 在第一次连接或者重新连接 master 时,slave 都会发送一条同步指令给 master ;

master 接到指令后,开始启动后台保存进程保存数据,接着收集所有的数据修改指令。后台保存完了,master 就把这份数据发送给 slave,slave
先把数据保存到磁盘,然后把它加载到内存中,master 接着就把收集的数据修改指令一行一行的发给 slave,slave
接收到之后重新执行该指令,这样就实现了数据同步。

slave 在与 master 失去联系后,自动的重新连接。如果 master 收到了多个 slave 的同步请求,它会执行单个后台保存来为所有的
slave 服务。

一旦 master 和 slave 在失去联系并重新连接上,总是会重新进行一次完整的同步。不过从 redis 2.8
开始,只是部分重新同步也是可以的。具体请大家参考官方文档。

祝大家端午节快乐。

下一篇,redis 的集群配置,敬请期待。

时间: 2024-10-18 18:24:45

高性能网站架构设计之缓存篇(4)- 主从复制的相关文章

高性能网站架构设计之缓存篇(3)- Redis的配置

我们说Redis是一个强大的Key-Value存储系统,在前面我们已遇到了两个问题: 1.redis server 启动后,独占进程,能不能修改为后台服务呢? 2.redis server 服务是单线程的,而我的机器是多核的,能不能在同一台机器上开启多个实例更充分的利用 cpu 资源呢?但6379端口已经被前一个实例绑定,肯定会有冲突,那能不能修改默认端口呢? 答案是肯定的,redis 提供了灵活的配置方式,一种可以通过配置文件来配置,另一种你可以在运行时通过 config set 命令来修改配

高性能网站架构设计之缓存篇(5)- Redis 集群(上)

集群技术是构建高性能网站架构的重要手段,试想在网站承受高并发访问压力的同时,还需要从海量数据中查询出满足条件的数据,并快速响应,我们必然想到的是将数据进行切片,把数据根据某种规则放入多个不同的服务器节点,来降低单节点服务器的压力. 上一篇我们讲到了 Redis 的主从复制技术,当实现了多节点的 master-slave 后,我们也可以把它叫做集群,但我们今天要讲的集群主要是利用切片技术来组建的集群. 集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点,这里我们需要一个规则或

高性能网站架构设计之缓存篇(1)- Redis C#客户端

一.什么 Redis REmote DIctionary Server,简称 Redis,是一个类似于Memcached的Key-Value存储系统.相比Memcached,它支持更丰富的数据结构,包括string(字符串).list(链表).set(集合).zset(sorted set --有序集合)和hash(哈希类型),并提供了数据持久化机制,在某些场景下,你完全可以把它当做非关系型数据库来使用.它是一个高性能的存储系统,能支持超过 100K+ 每秒的读写频率.同时还支持消息的发布/订阅

高性能网站架构设计之缓存篇(6)- Redis 集群(中)

昨天晚上钓鱼回来,大发神经,写了篇概括程序员生活现状的文章,没想到招来众多人的口诛笔伐,大有上升到政治层面的趋势. 我也许不会再发表任何冲击心灵的文章,我希望给大家带来更多的正能量,所以那篇文章已被我删除. 我的本意只是想让各位看过文章之后能冷静地思考自己的程序人生,不管是对是错,人都有选择的权力,走好自己的路. 我没有你们想象中那么悲观,我也在不懈的努力,哪怕一时的跌倒,我也要重新站起. 生活无时无刻不是压力,让我们背起行囊,迈出踏实的一步,走起! 我们继续我们的 redis 缓存之旅. 前一

高性能网站架构设计之缓存篇(1)- Redis的安装与使用

今天有幸被召回母校给即将毕业的学弟学妹们讲我这两年的工作史,看了下母校没啥特别的变化,就是寝室都安了空调,学妹们都非常漂亮而已..好了不扯蛋了,说下今天的主题吧.这些天我在深度定制语法高亮功能的同时发现了博客园提供的一些有意思的函数,甚至有几个博客园都没用到,我也不知道怎么才能触发那些功能..打开这个js就可以看到很多好用的东西了,虽然写的不怎么样,但是至少有这些功能. ps: 推荐安装一个代码格式化的插件,否则一坨看着蛋疼.比如第一个就是 log,方便调试. http://www.qidian

大规模高性能网站架构设计思路整理

近期关注了一些主流高并发大型网站如:大众点评.携程.去哪儿等 整理实现思路如下: 一.第一步 1.js .CSS.图片 优化压缩 2.站点动静分离,将动态网站单独部署.静态网站单独部署 3.数据库读写分离,比如:高频率读写的表分离 4.数据库优化,分表.分库.索引等 二.负载均衡 1.软件负载均衡,如:lvs,ngnix等 2.硬件负载均衡,如:F5等 三.缓存 1.数据缓存,如:memcacahe 2.Varnish Cache 3.Squid 四: 1.CDN

高性能网站架构方案

高性能网站架构方案,本文谈了七点网站架构方案,用以优化网站响应时间,实现大型网站技术架构方案.无论是电子商务或者其他网站且可使用. 一.优化网站响应时间的架构方案: 网站能不能留的住用户,一方面是看内容,另一方面是看响应时间.通常有以下几个方式来降低网站响应时间: 1.减少HTTP请求.包括合并css和javascript.减少图片数量,比如利用css的偏移技术来在一个图片中选择不同的位置内容.利用浏览器的Cache功能,我们可以在头中声明是否被浏览器缓存. 2.动态内容静态化.比如永久生成HT

大型分布式网站架构设计与实践

大型分布式网站架构设计与实践(一线工作经验总结,囊括大型分布式网站所需技术的全貌.架构设计的核心原理与典型案例.常见问题及解决方案,有细节.接地气/京东:大型分布式网站所需技术的全貌.架构设计的核心原理与典型案例.常见问题及解决方案) 陈康贤 著   ISBN 978-7-121-23885-7 2014年9月出版 定价:79.00元 460页 16开 编辑推荐 --作者一直奋战在阿里巴巴及淘宝网一线,书中所讲是其亲身经验的总结,显得更加实战和珍贵. --全面介绍大型分布式网站架构所涉及的技术细

个人网站架构设计(三) - 从设计到前端到后台

在五月份,写过两篇博客,提到了要给自己做个网站,当时人在实习,没太多的时间,只是把大概的思路捋了一番,顺道也买了个云主机(配置比较低,内存才500M).接着返校处理毕业事宜,于是六月也随着同学之间挥泪告别的声音渐渐远去.七月,家里呆着,中旬回公司.想必这也是我近几年最长的一次假期了=. = 一.先说设计 1. 阮一峰的博客 目前我的博客设计是 fork 了 BeiYuu 的主题,然后七改八改,除了主页 BeiYuu 还认得出是他的之外,其他页面已经动了很大的手术,而这些手术灵感都是源自阮一峰阮大