珠宝网站建设的主要方式wordpress 哪个好

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

珠宝网站建设的主要方式,wordpress 哪个好,wordpress上传与安装包,能不能用自己的主机做网站主从复制的补充问题 从节点和主节点之间断开连接#xff0c;有两种情况#xff1a; 1、从节点和主节点断开连接 slaveof no one 命令。这个时候#xff0c;从节点就能能够晋升成主节点。意味着我们程序员要主动修改redis的组成结构。#xff0c; 2、主节点挂了 这个时…主从复制的补充问题 从节点和主节点之间断开连接有两种情况 1、从节点和主节点断开连接 slaveof no one 命令。这个时候从节点就能能够晋升成主节点。意味着我们程序员要主动修改redis的组成结构。 2、主节点挂了 这个时候从节点不会晋升成主节点的。必须通过人工干预的方式恢复主节点。 这个是脱离咱们掌控的。 Redis主节点无法重启的问题 通过service redis-server start 启动的redis服务器是通过一个redis这样的用户来启动的。而redis server需要按照可读可写的方式打开aof文件而这个文件对于root之外的用户只有读权限。因此service redis-server start启动的redis服务器无法打开appendonly.aof文件。因为这里我们的三个服务器是使用的同一个appendonly.aof文件。 解决方案把三个redis服务器的生成的文件也给区分开。更靠谱的是直接把三个redis服务器的工作目录区分开。修改配置文件中的dir选项 1、停止之前的redis服务器 2、删除之前工作目录下已经生成的aof文件或者通过也可以通过chown命令修改以下所属用户。 3、给从节点创建出新的目录用来作为从节点的工作目录。并且修改从节点的配置文件设定成新的目录为工作目录。 4、启动redis服务器。 一、哨兵机制 人工大部分是不太靠谱的。通过自动化的手段来解决主节点挂了的问题。也就是哨兵机制。 更哨兵机制有关的概念 哨兵机制是通过独立的进程来体现的和之前的redis-server是不同的进程。redis-sentinel不负责存储数据只是对其他的redis-server起到监控的作用。通常哨兵节点也会搞一个集合。单个哨兵节点挂了咋办。 Redis sentinel架构 单独的redis sentinel进程提供了多个。并且这三个哨兵进程就会自动监控现有的redis master和slave。监控这些进程之间会建立tcp长连接通过这样的长连接定期发送心跳包。借助上述的监控机制就可以即使发现某个主机是否是挂了。如果是从节点挂了其实没有关系。如果是主节点挂了哨兵就要发挥作用了。 第一步此时一个哨兵节点发现主节点挂了还不够需要多个哨兵节点来共同认同这件事情主要是为了防止出现误判。 第二步主节点确实是挂了这些哨兵节点中就会推举一个leader有这个leader负责从现有从节点中挑一个作为新的主节点。 第三步挑选出新的主节点之后哨兵节点就会自动控制该被选中的节点执行slaveof no one并且控制其他从节点修改slaveof到新的主节点上。 第四步哨兵节点会自动的通知客户端程序告知新的主节点是谁并且后续客户端再进行写操作就会针对新的主节点进行操作了。 Redis哨兵的核心功能 1、监控 2、自动的故障转移 3、进行通知 注意redis哨兵节点有一个也是可以的。 1、如果哨兵节点只有一个它自身也是容易出现问题的。万一这个哨兵节点挂了后续redis节点也挂了就无法进行自动的恢复过程了。 2、出现误判的概率也比较高。毕竟网络传输数据也是容易出现抖动或者延迟或者丢包的。如果只有一个哨兵节点出现上述问题之后影响就比较大了。 基本原则在分布式系统中应该避免使用单点。也就是冗余。哨兵节点最后要搞奇数个最少也应该是3个。 使用docker搭建环境 一个主节点和两个从节点和三个哨兵的节点。 按理说这6个节点是要在6个不同的服务器主机上的。此时只有一个云服务器就在一个云服务器上来完成这里的环境搭建。在实际工作中把上述节点放到一个服务器上是没有意义的。当前这么做只是迫于无奈的。 由于这些节点还挺多的相互之间容易打架依赖的端口号/配置文件/数据文件。如果咱们直接部署就需要小心翼翼的去避开这些冲突。这种方式比较繁琐。也会和不同主机上部署存在较大差异。 但是我们使用docker就可以有效的解决上述的问题。 简单介绍虚拟机通过软件在一个电脑上模拟出另外的一些硬件。构造了另一个虚拟的电脑。虚拟机这样的软件就可以使用一个计算机。来模拟出多个电脑的情况。但是虚拟机有一个很大的问题比较吃配置。这个事情对咱们的云服务器来说压力山大。docker可以认为是一个轻量级的虚拟机起到了虚拟机这样的隔离环境的效果但是又没有吃很多的硬件资源。即使是配置比较拉跨的云服务器也能构造出好几个这样的虚拟的环境。docker现在后端开发这块非常流行的组件。 docker中关键概念容器看作一个轻量级的虚拟机。 1、需要安装docker和docker-compose。 2、停止之前的redis服务器。 3、使用docker获取到redis的镜像。docker中的镜像和容器类似于可执行程序和进程的关系。镜像可以自己构建也可以直接拿别人已经构建好的。docker hub。包含了很多其他大佬们构建好的镜像。 git pull使用git从中央仓库拉取代码。docker pull使用docker从中央仓库默认是从docker hub来拉取镜像。拉取到的镜像里面包含一个精简的Linux操作系统并且上面会安装redis。只要直接基于这个镜像创建一个容器跑起来此时redis服务器就搭建好了。 查看镜像。 基于docker来搭建redis哨兵环境了。 通过docker-compose来进行容器编排此处涉及到多个redis server 也有多个redis哨兵节点。每一个redis server或者每一个redis哨兵节点都是作为一个单独的容器了。我们现在又6个容器了。 通过一个配置文件把具体创建哪些容器每个容器运行的各种参数描述清楚。后续通过一个简单的命令就能够批量的启动/停止这些容器了。使用yml这样的格式来作为配置文件。经典的配置文件格式xml通过标签的格式进行组织的。 中成对出现的标签。html中的标签都是标准规定的。xml中的标签都是自定义的。写起来特别啰嗦。并且也比较占用空间。后来又有了json这样的格式。 yml格式和json有一些相似之处yml虽然没有json格式这么火也还是挺广泛使用的。 和json都是这种比较直观的键值对结构json是使用{}来表示层级结构yml则是使用缩进来表示。yml相对于json的优势。对于格式要求的更严格可读性会更好。更有助于人来理解。 编排工作 1创建三个容器作为redis的数据节点一个主两个从 2创建三个容器作为redis的哨兵节点。 文件名必须是固定的。 书写以下信息 version版本号 services启动哪些服务器 masterslave1slave2 主从服务器名。 image容器基于哪一个镜像。 command启动redis服务器的选项。 ports端口映射docker容器可以理解成是一个轻量的虚拟机。在这个容器里端口号和外面宿主机的端口号是两个体系。如果容器外面使用了5000端口在容器内部也可以使用5000彼此不会冲突。有的时候希望在容器外面能够访问到容器里面的端口号。就可以把容器内部的端口映射成宿主机的端口。 有的端口希望在容器外访问容器内部的端口需要进行端口映射把容器里的端口映射到宿舍主机上后续访问宿主机的这个端口就相当于在访问对应容器的对应端口了。站在宿主的角度访问上述几个端口的时候也不知道这个端口实际上是一个宿主机上的服务还是一个来自于一个容器内部的服务。只要正常去使用即可。这里的映射过程非常像NAT一样。 启动容器。 查看对应的日志。 redis哨兵节点是单独的redis服务器进程。 文件映射哨兵节点会在运行过程中对配置文件进行自动的修改。因此就不能拿一个配置文件给三个容器分别映射。 接下里再来看这三个配置文件的具体细节。初始情况下这三个配置文件内容可以是一样的。 bind 绑定ipport 端口号sentinel monitor告诉哨兵节点监控哪个redis服务器。ip端口号法定票数。这里的票数就是为了更稳健的确认当前redis-server是否挂了不能只听一个哨兵的一面之词。 down-after-milliseconds 心跳包的超时时间。 创建redis-sentinel1文件。把上述的内容写到该文件中。复制出2和3文件。但是这里报了一个错误。 docker-compose以下启动了N个容器。此时N个容器都处于同一个局域网中可以使者N个容器之间可以相互访问。三个redis-server节点是一个局域网。三个哨兵节点是另一个局域网。默认情况下这两网络似乎不能互通的。解决方案可以使用docker-compose把此处的两组服务给放到同一个局域网中docker network ls 列出当前docker中的局域网。 此处先启动了三个redis server节点就相当于自动创建了第一个局域网。在启动后面三个哨兵节点就直接让这三个节点加入到上面的局域网中而不是创建新的局域网。 通过上述的操作就完成了此处的配置。 启动后我们发现sentinel1文件里的内容已经被我们的程序自动配置重写了。 哨兵存在的意义能够在redis主从结构出现问题的时候此时哨兵节点就能够自动的帮我们重新选出一个主节点来代替之前挂了的节点保证整个redis仍然是可用的状态。 手动把主节点干掉 当主节点挂了之后哨兵节点就开始工作了。 sdown主观下线本哨兵节点认为该主节点挂了odown客观下线好几个哨兵都认为该节点挂了达成了一致此时主节点挂了这个事情就被实锤了。 此时就需要哨兵节点选出一个从节点作为新的主节点此处就需要提拔出一个新的主节点。 切换过程。 如果主节点挂了之后恢复过来作为了一个从节点。 主从切换具体流程 哨兵重新选取主节点的流程经典面试题 1、主观下线 哨兵节点通过心跳包判定redis服务器是否正常工作。如果心跳包没有如约而至就说明redis服务器挂了。此时还不能排除网络波动的影响因此就只能单方面认为这个redis节点挂了。 2、客观下线 多个哨兵都认为主节点挂了认为挂了哨兵节点数目达到法定票数。哨兵们就认为这个主节点是客观下线。 3、要让多个哨兵节点选出一个leader节点由这个leader负责选一个从节点作为新的主节点。 每个哨兵手里只有一票。当哨兵1第一个发现当前是客观下线之后就立即给自己投了一票并且告诉了23我来负责这个事情2 3反应慢了半拍才发现是客观下线一看1乐意负责这个事情立即投了赞成票。如果总的票数超过哨兵总数的一半选举完成了。上面的投票过程看谁反应快。谁的网络延时小。 4、此时leader选举完毕leader就需要挑选一个从节点作为新的主节点。 1比较一个优先级每个redis数据节点都会在配置文件中有一个优先级的设置slave-priority优先级高的从节点就会胜出。 2offset最大就胜出。offset从节点 从主节点同步数据的进度数值越大说明从节点的数据和主节点的数据就越接近。 3run-id每个redis节点启动的时候都会随机生成一串数字。大小全凭缘分了此时选谁都可以了随便挑一个。 把新的主节点指定好了之后leader就会控制这个节点执行slave no one成为master。在控制其他的节点执行slave of让其他节点以新的master作为主节点了。 总结 哨兵节点不能只有一个。 哨兵节点最好是奇数个。大部分情况下3个就够了。 哨兵节点不负责存储数据仍然是redis主从节点负责存储。哨兵节点就可以使用一些配置不高的机器来部署。但是不能搞一个机器部署三个哨兵。 哨兵 主从复制 提高可用性。 哨兵 主从复制 不能提高数据的存储容量当我们需要存的数据接近或者超过机器的物理内存这样的结构就难以胜任了。redis集群可以来解决存储容量问题的有效方案。