当前位置: 首页 > news >正文

深圳需要做网站的公司有哪些网络营销推广目标

深圳需要做网站的公司有哪些,网络营销推广目标,wordpress媒体库太大,图片制作表情包怎么做主从复制原理剖析 1 #xff09;配置 通过下面的从节点的配置项可以开启主从之间的复制功能slaveof 192.16.10.101 6379这里的复制包含全量复制和增量复制 2 #xff09;主节点的主从配置信息解析 查看主从之间的信息#xff0c;在主节点上 $ info replication 打印出来的…主从复制原理剖析 1 配置 通过下面的从节点的配置项可以开启主从之间的复制功能slaveof 192.16.10.101 6379这里的复制包含全量复制和增量复制 2 主节点的主从配置信息解析 查看主从之间的信息在主节点上 $ info replication 打印出来的细节# Replication role: master connected_slaves: 2 slave0:ip192.168.10.102,port6379,stateonline,offset2184,lag1 slave1:ip192.168.10.103,port6379,stateonline,offset2184,lag1 master_replid:0e233bbb3b38aada4764b58c2dc9e74ddfc85ccc master_replid2:0000000000000000000000000000000000000000 master_repl_offset:2184 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen: 2184从节点 offset 是指读取命令的偏移量 相当于: 从节点现在已复制的偏移量的长度主节点实际上会把所有的命令转成字节然后写到一个队列里边然后它写入了多少会记录下最终的值也就是对应下面的 master_repl_offset两者相等表示主从数据一致 lag 延迟时间lag1 延迟时间是1s主从同步数据会有延迟master_repl_offset 主节点已写入的命令偏移量master_replid 和 master_replid2 master_replid 表示主节点的一个 replicationID, 它是40个16进制的字符串随机生成的master_replid2 表示主节点的状态发生改变之后新的主节点ID会存放在 master_replid 中旧的主节点ID会存放在 master_replid2 中 下面的5项都是在 Redis 2.8 之后, 出现的特性 这里既然涉及到了主从复制肯定会有一个全量复制增量复制这样一个概念在里边全量复制是指从节点把主节点的数据据全部都拷贝过去这种一般发生在环境初始化和从节点扩展以及主节点故障在从节点选举新的主节点场景中在主节点故障重新选举的过程中run_id 会出现变化 在 $ info server 命令中就有这个 run_id从节点根据这个 run_id 来判断是全量复制还是增量复制 在2.8版本之后出现 second_repl_offset 这个配置还有一个缓冲区的概念关于 second_repl_offset 这个配置 2.8 之后全量增量复制多了一个命令叫 psync, 之前是建立一个 sync 的操作比如说, 现在主节点故障重启之后它发现 run_id 变了二话不说走一个全量复制再有比如说主节点故障了重新选取主节点会把上一次主节点已写入队列的偏移量 master_repl_offset 记录下来寄存到这个 second_repl_offset比如现在 master_repl_offset 已经是 2590 了在存的时候 second_repl_offset 一般做一个 1 的操作也就是变成了 2591这样从节点再重新跟主节点建立连接的时候会拿到这个 second_repl_offset根据上面的情况 second_repl_offset 比 master_repl_offset 多了一个字节就没有必要做全量复制了只需要继续保持现状跟它持续连接每十秒 ping 一下监听着它就行了, 继续做增量操作所以second_repl_offset 的作用就是为了避免每一次主从的角色改变/故障重启等场景带来可能的全量复制操作而浪费性能这样增量操作就能解决问题 关于缓冲区的配置 repl_backlog_active: 1 表示缓冲区开启repl_backlog_size:1048576 表示缓冲区的大小, 这里是 1M的大小repl_backlog_first_byte_offset:1 表示从1的位置开始写repl_backlog_histlen: 2184 表示当前缓冲区的长度 3 从节点的主从配置信息解析 在从节点上 $ info replication 打印出来的细节# Replication role:slave master_host:192.168.10.101 master_port:6379 master_link_status:up master_last_io_seconds_ago:5 master_sync_in_progress:0 slave_repl_offset:2842 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:0e233bbb3b38aada4764b58c2dc9e74ddfc85ccc master_replid2:0000000000000000000000000000000000000000 master_repl_offset:2842 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:2842上面 master_* 是主节点的一系列信息主要看下 master_last_io_seconds_ago:5 表示从库和主库最后一次同步数据的时间在五秒之前master_sync_in_progress:0 表示和主库的同步状态0是未同步1是正在同步master_repl_offset:2842 表示主节点写入的偏移量 上面 slave_* 是从节点的一些列配置 slave_repl_offset 表示从节点复制的偏移量和上面主节点写入偏移量一致说明同步了slave_priority:100 表示从节点在选举时成为主节点的一个几率 比如主节点宕机剩下的2个从节点开始参与选举谁能竞选成功就看上面这个数值的大小越大则优先级越高竞选越容易成功如果这个值为 0则这个从节点永远不会变成主节点 slave_read_only:1 从节点只读模式1表示开启0表示关闭 connected_slaves:0 表示连接到从节点的信息 作为从节点也是可以去连其他的从节点的 其他选项不再赘述 4 ) Master复制日志查看 master/slave 进行主从进行复制的时候在日志中也是可以体现出来 下面通过查看日志的方式把主从的一个复制流程走一遍 在主节点查看日志$ tail -f -n 800 /usr/local/redis/log/redis.log, 我们从下面位置来看 l. This will create latency and memory usage issues with Redis. To fix this issue run the command echo madvi se /sys/kernel/mm/transparent hugepage/enabled as root, and add it to your /etc/rc. local in order to retai n the setting after a reboot. Redis must be restarted after THP is disabled (set to madvise or never). 1468:M 1 Oct 2020 14:21:15.520 * DB loaded from append only file: 0.000 seconds 1468:M 1 Oct 2020 14:21:15.520 * Ready to accept connections 1468:M 1 Oct 2020 14:21:28.323 * Replica 192.168.10.102:6379 asks for synchronization 1468:M 1 Oct 2020 14:21:28.324 * Full resync requested by replica 192.168.10.102:6379 1468:M 1 Oct 2020 14:21:28.324 * Replication backlog created, my new replication IDs are 0e233bbb3b38aada47 64b58c2dc9e74ddfc85cccand 0000000000000000000000000000000000000000 1468:M 1 Oct 2020 14:21:28.324 * Starting BGSAVE for SYNC with target: disk 1468:M 1 Oct 2020 14:21:28.324 * Background saving started by pid 1474 1474:C 1 Oct 2020 14:21:28.326 * DB saved on disk 1474:C 1 Oct 2020 14:21:28.326 * RDB: 4 MB of memory used by copy-on-write 1468:M 1 Oct 2020 14:21:28.332 * Background saving terminated with success 1468:M 1 Oct 2020 14:21:28.332 * Synchronization with replica 192.168.10.102:6379 succeeded 1468:M 1 Oct 2020 14:21:30.858 * Replica 192.168.10.103:6379 asks for synchronization 1468:M 1 Oct 2020 14:21:30.858 * Full resync requested by replica 192.168.10.103:6379 1468:M 1 Oct 2020 14:21:30.858 * Starting BGSAVE for SYNC with target: disk 1468:M 1 Oct 2020 14:21:30.859 * Background saving started by pid 1475 1475:C 1 Oct 2020 14:21:30.861 * DB saved on disk 1475:C 1 Oct 2020 14:21:30.861 * RDB: 4 MB of memory used by copy-on-write 1468:M 1 Oct 2020 14:21:30.952 * Background saving terminated with success 1468:M 1 Oct 2020 14:21:30.952 * Synchronization with replica 192.168.10.103:6379 succeededReady to accept connections 表示随时等待其他节点的连接 Replica 192.168.10.102:6379 asks for synchronization 表示 102 从节点开始过来复制了 这里可见它发起了 sync 的请求 Full resync requested by replica 192.168.10.102:6379 表示 102 的复制请求是全量的复制请求 Replication backlog created, my new replication IDs are 0e233bbb3b38aada4764b58c2dc9e74ddfc85cccand 0000000000000000000000000000000000000000 刚把环境起起来这里主节点开始创建缓冲区并生成新的 replication IDs这里有2个ID就是上文说的 master_replid 和 master_replid2 下面是RDB的操作 1468:M 10 Nov 2020 14:21:28.324 * Starting BGSAVE for SYNC with target: disk 1468:M 10 Nov 2020 14:21:28.324* Background saving started by pid 1474 1474:C 10 Nov 2020 14:21:28.326 * DB saved on disk 1474:C 10 Nov 2020 14:21:28.326 * RDB: 4 MB of memory used by copy-on-write 1468:M 10 Nov 2020 14:21:28.332 * Background saving terminated with success首先通过 BGSAVE 把数据写入磁盘可以看到它是后台的写入进程之后通过 copy-on-write 把内存的 4M 数据写入磁盘最后保存结束终止 Synchronization with replica 192.168.10.102:6379 succeeded 这里提示 102 机器的复制成功了 下面是 103 重复RDB的复制操作 1468:M 10 Nov 2020 14:21:30.858 * Replica 192.168.10.103:6379 asks for synchronization 1468:M 10 Nov 2020 14:21:30.858 * Full resync requested by replica 192.168.10.103:6379 1468: M 10 Nov 2020 14:21:30.858 * Starting BGSAVE for SYNC with target: disk 1468:M 10 Nov 2020 14:21:30.859 * Background saving started by pid 1475 1475:C 10 Nov 2020 14:21:30.861 * DB saved on disk 1475:C 10 Nov 2020 14:21:30.861 * RDB: 4 MB of memory used by copy-on-write 1468:M 10 Nov 2020 14:21:30.952 * Background saving terminated with success 1468:M 10 Nov 2020 14:21:30.952 * Synchronization with replica 192.168.10.103:6379 succeeded不再赘述 5 画图来看复制流程(全量复制) 环境搭建好之后slave节点就发起了一个 sync 的请求这个请求是一个 全量复制 其实增量无非就是在环境构建完成之后每次你写入一个我就复制一个写入一个复制一个 sync 的命令到主节点主节点这边执行 BGSAVE 执行BGsave之后生成RDB快照然后主节点会把RDB的快照发送给 slave 节点slave 节点拿到RDB快照之后会把它节点上旧的数据全部删掉加载RDB的文件在上述过程中我们看下 master主节点在执行 BGSAVE 的时候它是一个非阻塞的就是说, 在生成RDB执行BGSAVE 期间, 仍然是可以对外提供服务的也就是说它仍然是可以读写的如果说这时候有一些命令它就会把命令写到缓冲区里边去就是我们的backlog里边它为什么要这么做呢一方面为了提高性能无阻塞可提供反馈另一方面写到缓冲区里边master 已经生成RDB快照发给 slave节点了后续的命令从节点就拿不到了所以给它放到这个缓冲区里边等 slave 这边RDB加载完之后它再从缓冲区里边去拿走后续的那些命令相当于就是把整个的数据全部复制过去了 所以我们的 slave 除了加载 RDB 之外它还会去缓冲区里边继续接受这些命令最终完成一个init所以这里面包含RDB的加载完成和缓冲区命令的复制都完成了 6 再来看下增量复制 增量复制更多的是 Slave 初始化完成后环境已经稳定了这个时候就会做增量的复制增量复制就是主服务器那边发生了写操作它就会同步到从服务器的一个过程复制的过程就是 主服务器执行一个命令从服务器就会发送一个相同的写命令从服务器接收到之后就开始执行 我们可以演示一下 在从服务器中执行 $ sync 先建立连接在主服务器中进行写操作 $ set age 18在从服务器终端中输入PING SELECT,0 set,age,18 PING可以看到每10s就会PING一下得到新的同步的命令这样保持心跳 在2.8之前都是全量复制之后便可以增量复制了 7 主从复制的异步性 主从复制这个过程主节点是非阻塞的在复制的这个流程中它是开启的一个后台子守护进程去做这件事情的比如 BGSAVE 和 生成 RDB快照发送等当前服务器仍然是可以对外提供读写这样的一些请求的这个就是非阻塞体现异步性从节点也是一样的比如说正在复制主节点的数据这个SYNC的操作也是非阻塞的复制的过程中, 它可能就会有一点问题, 比如正在复制时一个查询过来 那我可能查到的就是比如说一些老数据这里边就会有脏读数据不一致等等的问题这块在故障解决中有一些方案来处理 8 过期 key 的处理 实际上从节点是不会让 key 过期的从节点它没有 key 过期的概念它会等待接收主节点delete的命令可以看下面的演示 从节点$ sync 先监控下主节点$ set age 18 ex 10查看从节点输出PING set,age,18,ex,10 PING DEL,age PING可以看到它在等主节点发DEL 命令 也就是当Master让key到期时会合成一个 DEL 命令传输到所有 Slave 9 加速复制 上面看日志可知每一次的复制都会生成RDB然后把RDB的快照文件发给从节点如果说你的磁盘性能比较差每一次的主从复制都要写入磁盘如后再生成RDB文件发送给从节点性能就会被降低因为磁盘性能差可以不写入磁盘直接生成RDB文件发给从节点就可以了在 Redis2.8.18这个版本之后加入了这个功能可以设置无需写入磁盘直接把这个RDB的快照文件发给从节点修改配置repl-diskless-sync yes 默认值是 no 不开启 不开启的情况下BGSAVE 先写磁盘然后把生成RDB快照再发送设置为 yes 开启之后就直接把RDB快照发给从节点不会写磁盘操作这样就加速了复制
http://www.dnsts.com.cn/news/181537.html

相关文章:

  • php做网站优点软件技术学的是什么
  • 建立网站需要多少钱八寇湖南岚鸿团队wordpress 上传目录
  • 网站怎么做域名关于网站建设好处文章
  • 红色专题网站首页模板wordpress的采集插件
  • 黄骅做网站价格电影大型网站制作
  • 分析建设网站的可行性湛江建设部网站
  • 微信网站入口网站信息备案变更 哪里做
  • 买服务器的网站网站建设客户会问的问题
  • 中国做跨境电商出口的网站大同网站建设企业
  • 公司网站开发用什么软件win10优化
  • seo网站推广教程企业咨询服务合同模板免费
  • 网站外连软件外包服务公司是做什么的
  • 开发网站的技术路线网页网站制作维护
  • 网站demo要几个人做前端网站开发心得体会
  • 深圳龙岗做网站的公司支付宝网页版
  • 百度网站建设如何定制鞋子哪个网站好
  • 网站建设最好的公司排名999导航
  • 网站开发毕业设计任务书wordpress怎么在本地安装
  • app和网站的区别建设网银怎么开通使用
  • 太仓建设工程网站咨询型网站
  • 网站建设好的乡镇网站后台建设 招聘
  • 做网站需要办什么手续嘉定做网站的
  • 网站外部链接建设易网网站多少
  • 做cpa必须要有网站吗网络营销是营销的网络化吗
  • 外汇做单在什么网站做网站切图
  • 自学商城网站建设网站广告出价平台
  • 做VIP视频网站赚钱小程序制作费用多少
  • 传奇网站传奇住房和城乡建设部门户网站
  • 做网站 宁波软件开发外包合同范本
  • 能免费做片头的网站亚马逊跨境电商个人开店流程