罗小黑发布的文章

2022-01-16

兄弟们兄弟们

2022年01月16日
27 阅读
0 评论
0 点赞

2022-01-15

早点睡吧早点睡吧

2022年01月15日
49 阅读
0 评论
0 点赞

2021-12-13

PanDalMG（熊猫图床）一款全新的国内公益图床熊猫图床官网：www.pandaimg.com介绍熊猫图床是一款以图片上传、图片管理为核心的图床/图片管理平台，能够满足「收藏、整理、查找」的各种场景，把琐碎复杂的事情变得简单与高效，让收集素材成为⽇常习惯，更让素材真正到想用的时候可以信手拈来！是设计师和摄影爱好者必不可少的工具！功能360全景视图制作（一键制作生成全景视图页面，360度无死角观看，记录你的缤纷生活，给观看者视觉上最震撼的观看体验）自定义水印上传完善的API接口（需要一定的开发能力才能对接）画廊图像分享（对于从事摄影后者个人图像展示的，可以轻松生成并且分享自己的画廊，支持添加访问密码，防止被他人偷看）临时图像（可以设置图像上传有效时间，到期自动删除）支持图片拖拽、截图直接(Ctrl+V)和URL地址上传支持多种图像格式如:gif,jpg,jpeg,bmp,png,jfif,webp,ico,svg图像归类功能（规划图片种类，一目了然）更多功能请注册查看

2021年12月13日
207 阅读
0 评论
1 点赞

2021-12-13

XDD-PLUS登录不上或者登录失败解决方法 1、下载https://github.com/764763903a/xdd-plus/releases/download/v1.7/xdd-linux-amd642、下载好上面链文件再重命名 xdd3、把下载好的xdd 替换到xdd目录里面 xdd-plus/xdd4、下载https://github.com/764763903a/xdd-plus/releases/download/v1.7/config.yml5、把下载好的 config.yml 文件放入服务器xdd-plus/qbot文件夹下面6、修改config.yml 文件第四行的QQ号码7、进入终端运行此命令 cd xdd-plus && ./xdd 就会出现一个二维码然后用QQ扫码登录8、登录之后ctrl+c退出，再运行一下 ./xdd 再次（ctrc+c退出一次）再运行一下 ./xdd -d如果GitHub下载慢可以用我下载好的文件{cloud title="XDD修复文件" type="lz" url="https://wwe.lanzouo.com/iGmxSxjya2d" password=""/}

2021年12月13日
111 阅读
0 评论
0 点赞

2021-11-22

2021年11月22日
933 阅读
3 评论
0 点赞

2021-11-20

如何利用 Github 搭建自己的免费图床？ 1. 前言对于写博客的朋友们来讲，图床这个东西一定不会陌生，而且在一定程度上也给大家造成过一定困扰。对于不清楚这个东西的朋友，我就在这儿大概说一下图床是个啥东西。所谓图床，其实可以就相当于我们手机上的相册，不过他是在线的，而且是对大家开放的，大家都可以访问查看，但是编辑删除这些功能仅限于拥有者，就相当于用百度云分享的公开照片，你可以查看，也可以下载下来编辑，但是拥有权还是属于分享者。那你可能会疑惑，那这个东西和写博客的我们有啥关系呢？你想想，我们写博客，是不是有很多图片需要插入，我们这些博客要保留在本地的时候你可以预览到图片，但一旦你要把它发布到网上，这时候问题来了！发现图片上传失败，那是因为你本地的图片都是存在本地的，平台不会自动给你上传，那这个时候就凸显出图床的重要性了。当然了，如果你是直接在平台进行编辑，那着一点就不用担心了，基本平台都会自动给你上传到它自己的服务器。有了图床，我们在本地写好博客之后，就能够任意复制到其他平台，不用担心图片丢失问题了。今天的文章就是给大家分享一个搭建免费图床的教程，既是方便自己后续的复习，也希望对大家也有所帮助。 2. 准备工作那么在正式开始之前，你需要提前准备以下东西：一个 Github 账号 3. 搭建过程这一部分就是正式开始大家过程了，准备好大干一场吧！登录你的 Github 之后，创建一个新的仓库；填写仓库先关资料，一般只需要选一个合适的仓库名，然后确保仓库为 public 其他的保持默认就好；一般创建成功之后，会出现如下界面，至此，我们的图床算是创建好了，接下来就是如何上传图片了； 4. 上传图片通过上面的步骤，我们的图床时搭建好了，但是通过传统的方法向 Github 上传图片太麻烦了，这里我们推荐使用一个开源图床工具 PicGo 来作为我们的图片上传工具； PicGo 的安装就不说了，去他的官网下载对应版本进行安装即可，我们主要讲讲如何用它来上传图片。安装后，打开软件其主页面如下：接下来就是配置 PicGo 的过程了。首先，我们先要去 Github 创建一个 token；以此打开 Settings -> Developer settings -> Personal access tokens，最后点击 generate new token；填写及勾选相关信息，然后点击 Genetate token 即可； token 生成，注意它只会显示一次，所以你最好把它复制下来到你的备忘录存好，方便下次使用，否则下次有需要重新新建；配置 PicGo，依次打开图床设置 -> Github 图床；填写相关信息，最后点击确定即可，要将其作为默认图床的话，点击设为默认图床；上传图片，通过上传区上传即可（Ctrl V 或者将图片拖拽都可以），也可以通过快捷键的方式上传（默认上传键为 Ctrl + Shift + P）； 5. 加速访问大家可能会发现，我们上传到 Github 的图片有时候访问太慢了，有时候甚至直接加载不出来！那该咋办呢？这时候我们就可以用 jsDelivr 进行免费加速，而设置的方法也很简单，只需要在我们 PicGo 图床配置中添加如下自定义域名即可； https://cdn.jsdelivr.net/gh/用户名/仓库名比如我的就是 https://cdn.jsdelivr.net/gh/BXiaoHei/img 6. 图床推荐除开用 Github 搭建的方式之后，我们也可以用 Gitee 进行搭建，搭建方式和本文大致相同。此外，我也推荐几个免费的图床给大家，大家可以根据自己的喜好进行选择；路过图床 SM.MS Imgur 7. 总结至此，我们的搭建免费图床的教程就到此结束了，总结一下主要有如下几部分：准备一个 Github 账号；搭建图床仓库；上传图片设置；加速访问；免费图床推荐；如果你对上面的部分有疑问，欢迎留言或者私信，我会在看到的第一时间回复你！

2021年11月20日
269 阅读
4 评论
1 点赞

2021-11-08

CDN配置方式(以腾讯云为例) 引入CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。随着网民数量的急剧增长，以及网络攻击的成本降低，越来越多的网站需要通过CDN来加速并保护自己的网站。正文开始使用接入CDN，需要先在CDN控制台添加新域名，填写源站IP，并且获取域名cname记录值，并且于DNS解析处修改为CDN给出的cname记录值。之后，本地可以通过crtl+R打开运行，之后输入ping 域名来确认自己的解析是否生效。缓存规则设置大部分静态加速CDN提供文件缓存的自定义选项，允许用户通过修改缓存时间来减少源站压力。注意:动态网站请不要使用"缓存所有文件"，否则可能导致网站直接无法访问。在腾讯云CDN控制台，我们可以看到缓存配置→节点缓存过期配置请注意，不要缓存后台目录，否则后台会出现问题 (typecho默认后台为/admin)这里给出一个示例，建议使用在个人博客等对静态文件更新不严格的网站。内容缓存时间全部0秒mp3;wav;wmv;rmi;aac7天jpg;jpeg.png;gif;bmp;webp;pcx7天js;css;txt;xml;shtml30天php;jsp;asp;aspx;html0秒*温馨提示:腾讯云CDN的缓存策略是越靠下优先级越高，如果您是其他CDN，请根据实际用户文档进行配置！如果博客存在视频、急速下载等功能，可以按需缓存。(这里强烈推荐动静分离、图站分离，主站与其他文件分开缓存，可以最大承担优化体验)HTTPS配置这是目前我在群里面发现萌新问的最多的问题，这里统一解答一下。首先，HTTPS证书在同一台服务器上，要么全部使用，要么全部不要使用，否则可能会导致源站IP泄露。配置HTTPS证书的方式通常有三种:①半程加密:在CDN处配置证书，用户访问之后会与CDN建立安全连接保障数据安全。②全程加密:CDN处、服务器处均有证书，用户访问之后与CDN，CDN与服务器之间均为安全链接。③严格加密:全程加密的基础上增加对证书的验证以保障数据绝对安全。(正常情况下无需开启，可能导致网站报错)如果要配置证书，不存在在服务器处配置证书后CDN处不配置，否则会出现报错，显示为CDN节点的默认证书。同时，如果CDN支持OCSP装订 HSTS强烈建议开启，前者可以提高速度，后者可以加强HTTPS安全性。减少损失大部分CDN为按量计费，可能会被恶意盗刷，以下给大家提供一些防攻击的CDN端策略。①CDN如有提供防CC功能直接打开即可，手动配置建议设置为3秒5次②CDN没有提供防CC功能(比如腾讯云):图站分离的情况下带宽封顶配置设置为2M，若出现频繁超限可以适当增加③IP访问限频配置:若主站完全不存图和静态文件，可以设置为20及以下，若有大量图片建议50+，出现加载不全可以适当增加④下行限速配置:腾讯云CDN下行限速限制的是单一节点，只要不是密集访问，一般不会造成影响，建议设置为256KB/s(换算之后约为2M带宽)补充说明使用CDN的时候，务必确认CDN稳定性，切莫贪便宜。出现任何问题可以工单询问客服，大厂一般都会解决。版权属于：何叶本文链接：https://www.onyi.net/archives/428.html

2021年11月08日
212 阅读
1 评论
0 点赞

2021-11-08

腾讯云CDN第三方存储桶私有读写，纵享安全引入在公网对对象存储进行读取，有公有读和私有读两个方式，但是由于CDN无法进行验证，导致如果非同一厂商支持内网验证的CDN环境下，必须使用公有读才可以正常从外网访问。最近腾讯云CDN的源站多了一个新选项第三方对象存储，控制台对此的注释是AWS S3和阿里云OSS。言下之意，就是腾讯云CDN支持私有访问第三方存储桶了。腾讯云的老用户都知道如果使用COS服务，可以通过CDN私有访问，防止有别的用户通过直接访问COS源站，忽略了CDN的简易防御，产生大量损失。而现如今腾讯云CDN将这个功能适配到第三方存储桶上，恰好解决了这个问题。本教程以阿里云OSS对接腾讯云CDN为例，简述如何使用该项功能~准备使用该项业务，需要先在第三方创建新的存储桶。新建的时候存储桶的读写权限(Bucket ACL)选择私有，已有存储桶的清选择低访问量的时段进行操作避免影响用户体验。AccessKey的获取与使用创建完私有存储桶之后，我们需要获取AccessKey ID和AccessKey Secret。由于AccessKey拥有账户的全部权限，所以不建议直接将主账号的AccessKey作为对接CDN的AccessKey。阿里云用户可以通过RAM 访问控制创建新的子账户，具体命名规则参照用户文档。需要给相应的子账户授权AliyunOSSReadOnlyAccess的权限策略名称，该权限是只读访问对象存储服务(OSS)的权限。因为不需要用到编辑，只需要只读权限，因此不建议给对应子账户授权太多内容避免出现风险。对接腾讯云CDN一切创建好之后，进入腾讯云CDN控制台，选择添加域名，源站选择第三方存储桶，源站地址填写对象存储的外网访问地址。然后勾选私有存储桶访问，填写刚刚获取的子账户AccessKey ID和AccessKey Secret然后点击确认。缓存策略及问题检查对于动静分离和图站分离的站长，建议直接缓存全站30天，当静态文件出现变更时，再到控制台进行刷新，这样可以大量减少对象存储的计费。如果出现文件加载异常，建议先把存储桶改成公有读私有写，之后关闭私有访问，若依旧存在问题则为对象存储/CDN配置不当。若问题解决，建议检查AccessKey有效性和权限。结语腾讯云CDN居然可以推出此项功能是我没想到，相比别家自己只能对接自己的对使用多家云厂商产品的用户更加友好。也希望别的厂商能尽快推出类似功能。版权属于：何叶本文链接：https://www.onyi.net/archives/432.html

2021年11月08日
103 阅读
0 评论
1 点赞

2021-10-17

Redhat8.0本地Yum源配置方法由于redhat系统的yum源需要注册后再使用（也就是要花钱买），我们可以自己创建一个yum的源来解决。问题提示：system is not registered with an entitlement server. You can use subscription-manager to register1、挂载系统光盘到/mnt/cdrom目录mkdir -p /mnt/cdrom mount /dev/sr0 /mnt/cdrom2、设置系统启动后自动挂载/mnt/cdrom# blkid #查看文件类型就是下面的iso9660 echo "/dev/sr0 /mnt/cdrom iso9660 defaults 0 0" >>/etc/fstab3、创建RHEL8.repovi /etc/yum.repos.d/RHEL8.repo [BaseOS] name=BaseOS baseurl=file:///mnt/cdrom/BaseOS enabled=1 gpgcheck=0 [AppStream] name=AppStream baseurl=file:///mnt/cdrom/AppStream enabled=1 gpgcheck=04、测试yum配置是否可用 yum install -y lrzsz 或者dnf -y install lrzszPS:dnf是新一代的rpm包管理器，取代了Yum包管理器，但是原来的yum命令依旧可以用

2021年10月17日
121 阅读
0 评论
2 点赞

2021-10-15

『教程』首页及文章页滚动广告栏前言因为之前在很多网站上都能看到广告，虽然但是，这对很多博主来说也是一笔额外的收入，我一直是入不敷出！:@(吐血倒地) 然后我看到了执念博客的首页广告栏，虽然曝光确实大，但是用户体验极其不好，因为要翻很多广告才能翻到文章，就像这样：所以我就想到了滚动广告，一个广告的位置，能够显示多条广告成果展示{tabs}{tabs-pane label="首页"}{/tabs-pane}{tabs-pane label="文章页"}{/tabs-pane}{/tabs}教程开始灵感及相关代码来自于Joe主题的首页轮播图一、添加后台打开 functions.php 添加以下代码$JADPost = new Typecho_Widget_Helper_Form_Element_Textarea( 'JADPost', NULL, NULL, '文章页顶部广告', '介绍：用于设置文章页顶部广告 <br /> 格式：广告图片 || 跳转链接（中间使用两个竖杠分隔）<br /> 注意：如果您只想显示图片不想跳转，可填写：广告图片 || javascript:void(0) <br /> 其他：一行一个，一行代表一个轮播广告图' ); $JADPost->setAttribute('class', 'joe_content joe_post'); $form->addInput($JADPost);这是文章页的代码，因为首页广告主题自带了二、添加滚动广告栏{tabs}{tabs-pane label="首页"} 因为首页已经有广告位了，所以直接替换就行了将主题 index.php 的以下代码直接替换为新代码{collapse}{collapse-item label="代码位置" open}{/collapse-item}{collapse-item label="新代码"}隐藏内容，请前往内页查看详情{/collapse-item}{/collapse}{/tabs-pane}{tabs-pane label="文章页"}文章页直接在主题的 post.php 文件内合适的地方加入以下代码{collapse}{collapse-item label="代码位置" open}{/collapse-item}{collapse-item label="代码"}隐藏内容，请前往内页查看详情{/collapse-item}{/collapse}{/tabs-pane}{/tabs}三、修改广告栏样式{tabs}{tabs-pane label="首页"} 直接在 Joe/assets/css 打开 joe.index.min.css 然后在最后添加以下代码.joe_index__ad .swiper-container{height: 180px!important;border-radius: var(--radius-inner);}.joe_index__ad .swiper-container .icon{position:absolute;z-index:1;top:10px;right:10px;font-size:12px;background:rgba(0,0,0,0.25);padding:2px 5px;border-radius:2px;color:#ebebeb;pointer-events:none}@media (max-width: 768px){.joe_index__ad .swiper-container{height: 120px!important}.joe_index__ad .swiper-container .image{height: 120px;object-fit: cover;border-radius: var(--radius-inner);}}{/tabs-pane}{tabs-pane label="文章页"}直接在 Joe/assets/css 打开 joe.post.min.css 然后在最后添加以下代码.joe_post__ad .swiper-container{height: 180px!important;margin-top:15px;border-radius: var(--radius-inner);}.joe_post__ad .swiper-container .icon{position:absolute;z-index:1;top:10px;right:10px;font-size:12px;background:rgba(0,0,0,0.25);padding:2px 5px;border-radius:2px;color:#ebebeb;pointer-events:none}@media (max-width: 768px){.joe_post__ad .swiper-container{height: 120px!important}.joe_post__ad .swiper-container .image{height: 120px;object-fit: cover;border-radius: var(--radius-inner);}}{/tabs-pane}{/tabs}四、添加滚动效果{tabs}{tabs-pane label="首页"}首页因为引入了滚动效果，所有不需要设置，会直接调用首页轮播图的滚动效果但是会根据首页轮播图的滚动方式滚动，效果不太好，暂时没想到比较好的解决方法{/tabs-pane}{tabs-pane label="文章页"}首先在主题的 post.php 文件内标签内加入以下代码<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/swiper@5.4.5/css/swiper.min.css" /> <script src="https://cdn.jsdelivr.net/npm/swiper@5.4.5/js/swiper.min.js"></script>然后再在 Joe/assets/js 打开 joe.post_page.min.js 然后在最后添加以下代码if(0!==$(".joe_post__ad .swiper-container").length){let e="vertical";new Swiper(".swiper-container",{keyboard:!1,direction:e,loop:!0,autoplay:!0,mousewheel:!0,pagination:{el:".swiper-pagination"},})}添加位置{/tabs-pane}{/tabs}教程结束大功告成，快刷新你的网站看看效果吧！{callout color="#ef6d4d"}转载来源： {abtn color="#ff0d00" href="https://blog.52aill.xyz/archives/389/" content="六六丶"/}{/callout}

2021年10月15日
349 阅读
3 评论
1 点赞

2021-10-07

2021年10月07日
103 阅读
0 评论
0 点赞

2021-09-27

解决Ubuntu系统无法连接网络今天在公司安装了Ubuntu系统，安装之后发现不能上网，在网上了找了好多解决方法，都没找到，主要是我对Ubuntu系统不是很熟 :@(阴暗) ，而且网上大部都是Ubuntu20以前的解决方法，20版后network配置文件变了。在Ubuntu20.04版本中使用netplan管理网络在安装好的Ubuntu20.04中没有networking和NetworkManage服务netplan配置文件：/etc/netplan/*.yaml,文件名每一个都不一样netplan示例文件：/usr/share/doc/netplan/example目录下，在该目录下有各种示例文件，可以提供帮助修改网卡配置文件vim /etc/netplan/00-installer-config.yaml network: ethernets : ens32 : addresses : - 192.168.0.138/24 gateway4 : 192.168.0.1 nameservers : addresses : - 8.8.8.8 version : 2netplan apply具体可看：https://netplan.io/examples

2021年09月27日
138 阅读
1 评论
1 点赞

2021-09-26

新的风暴已经出现怎么能够停滞不前... 迪迦

2021年09月26日
220 阅读
1 评论
3 点赞

2021-09-21

Redis集群搭建主从复制概述主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave已读为主默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。主从复制的作用主从复制的作用主要包括：数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。环境配置只配置从库，不用配置主库127.0.0.1:6379> info replication # Replication role:master connected_slaves:0 master_replid:f47467f195c4ed51c50938a60c17de4b01bb0f72 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0复制3个配置文件，然后修改对应的信息1、端口2、pid名字3、log文件名字4、 dump.rdp名字一主二从从机127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 #slaveof host 6379 OK 127.0.0.1:6380> info replication # Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:2 master_sync_in_progress:0 slave_repl_offset:42 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:da314952dadd611849cb227b8706af7bcd8af486 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:42 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:42 127.0.0.1:6381> SLAVEOF 127.0.0.1 6379 #slaveof host 6379 OK 127.0.0.1:6381> info replication # Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:8 master_sync_in_progress:0 slave_repl_offset:224 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:da314952dadd611849cb227b8706af7bcd8af486 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:224 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:113 repl_backlog_histlen:112建议在配置文件中设置，用命令的话是暂时的主机可写，从机可读如果主机断开连接，从机依旧可以连接到主机，但是没有写的权限，一旦主机恢复，从机就可以再次读取主机信息。如果是用命令行配置的从机，一旦断开连接就会变成主机，需要重新配置，但是在配置文件配置的就不会出现这种情况主从复制（复制原理）Slave启动成功连接到master后会发送一个sync同步命令Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后, master将传送整个数据文件到slave , 并完成一-次完全同步。全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。增量复制: Master继续将新的所有收集到的修改命令依次传给slave ,完成同步但是只要是重新连接master , 一次完全同步(全量复制)将被自动执行层层链路上一个M链接下一个S这个时候如果主机（79）宕机，我们可以用SLAVEOF no one80从机就会变成主机,如果79主机恢复，需要从新配置哨兵模式主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预 ,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵)架构来解决这个问题。谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库.哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一一个独立的进程 ,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。这里的哨兵有两个作用通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。当哨兵监测到master宕机,会自动将slave切换成master ,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票 ,投票的结果由一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。测试配置哨兵配置文件vim sentinel.conf# 监听端口 port 26379 # 后台运行 daemonize yes #pid文件 pidfile /var/run/redis-sentinel.pid # 哨兵得日志文件 logfile "sentinel.log" # 日志文件存放路径 dir /www/server/redis/ # 设置初始master以及法定认为下线人数： #sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 192.168.0.10 6379 1 # master主观下线时间,默认30秒，30秒内没有回复pong，则认为下线了 #sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000 # 指定故障转移超时时间，默认为3分钟 sentinel failover-timeout mymaster 180000 # 设置通知脚本，发生故障转移可以向管理员发送通知（可选） sentinel notification-script mymaster /www/server/redis/notify.sh # 禁止修改脚本，避免脚本重置 sentinel deny-scripts-reconfig yes启动哨兵模式[root@cs bin]# redis-sentinel xhconfig/sentinel.conf 如果master节点断开了，这个时候就会从从机随机选一个从机当主机如果主机回来了，只能归并到新的主机下，当作从机优点:1、哨兵集群,基于主从复制模式,所有的主从配置优点,它全有2、主从可以切换,故障可以转移,系统的可用性就会更好3、哨兵模式就是主从模式的升级,手动到自动,更加健壮!缺点:1、Redis 不好啊在线扩容的,集群容量一旦到达上限,在线扩容就十分麻烦!2、实现哨兵模式的配置其实是很麻烦的,里面有很多选择!哨兵全部配置[root@cs bin]# cat /opt/redis-5.0.13/sentinel.conf # Example sentinel.conf # *** IMPORTANT *** # # By default Sentinel will not be reachable from interfaces different than # localhost, either use the 'bind' directive to bind to a list of network # interfaces, or disable protected mode with "protected-mode no" by # adding it to this configuration file. # # Before doing that MAKE SURE the instance is protected from the outside # world via firewalling or other means. # # For example you may use one of the following: # # bind 127.0.0.1 192.168.1.1 # # protected-mode no # port <sentinel-port> # The port that this sentinel instance will run on port 26379 # By default Redis Sentinel does not run as a daemon. Use 'yes' if you need it. # Note that Redis will write a pid file in /var/run/redis-sentinel.pid when # daemonized. daemonize no # When running daemonized, Redis Sentinel writes a pid file in # /var/run/redis-sentinel.pid by default. You can specify a custom pid file # location here. pidfile /var/run/redis-sentinel.pid # Specify the log file name. Also the empty string can be used to force # Sentinel to log on the standard output. Note that if you use standard # output for logging but daemonize, logs will be sent to /dev/null logfile "" # sentinel announce-ip <ip> # sentinel announce-port <port> # # The above two configuration directives are useful in environments where, # because of NAT, Sentinel is reachable from outside via a non-local address. # # When announce-ip is provided, the Sentinel will claim the specified IP address # in HELLO messages used to gossip its presence, instead of auto-detecting the # local address as it usually does. # # Similarly when announce-port is provided and is valid and non-zero, Sentinel # will announce the specified TCP port. # # The two options don't need to be used together, if only announce-ip is # provided, the Sentinel will announce the specified IP and the server port # as specified by the "port" option. If only announce-port is provided, the # Sentinel will announce the auto-detected local IP and the specified port. # # Example: # # sentinel announce-ip 1.2.3.4 # dir <working-directory> # Every long running process should have a well-defined working directory. # For Redis Sentinel to chdir to /tmp at startup is the simplest thing # for the process to don't interfere with administrative tasks such as # unmounting filesystems. dir /tmp # sentinel monitor <master-name> <ip> <redis-port> <quorum> # # Tells Sentinel to monitor this master, and to consider it in O_DOWN # (Objectively Down) state only if at least <quorum> sentinels agree. # # Note that whatever is the ODOWN quorum, a Sentinel will require to # be elected by the majority of the known Sentinels in order to # start a failover, so no failover can be performed in minority. # # Replicas are auto-discovered, so you don't need to specify replicas in # any way. Sentinel itself will rewrite this configuration file adding # the replicas using additional configuration options. # Also note that the configuration file is rewritten when a # replica is promoted to master. # # Note: master name should not include special characters or spaces. # The valid charset is A-z 0-9 and the three characters ".-_". sentinel monitor mymaster 127.0.0.1 6379 2 # sentinel auth-pass <master-name> <password> # # Set the password to use to authenticate with the master and replicas. # Useful if there is a password set in the Redis instances to monitor. # # Note that the master password is also used for replicas, so it is not # possible to set a different password in masters and replicas instances # if you want to be able to monitor these instances with Sentinel. # # However you can have Redis instances without the authentication enabled # mixed with Redis instances requiring the authentication (as long as the # password set is the same for all the instances requiring the password) as # the AUTH command will have no effect in Redis instances with authentication # switched off. # # Example: # # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # sentinel down-after-milliseconds <master-name> <milliseconds> # # Number of milliseconds the master (or any attached replica or sentinel) should # be unreachable (as in, not acceptable reply to PING, continuously, for the # specified period) in order to consider it in S_DOWN state (Subjectively # Down). # # Default is 30 seconds. sentinel down-after-milliseconds mymaster 30000 # sentinel parallel-syncs <master-name> <numreplicas> # # How many replicas we can reconfigure to point to the new replica simultaneously # during the failover. Use a low number if you use the replicas to serve query # to avoid that all the replicas will be unreachable at about the same # time while performing the synchronization with the master. sentinel parallel-syncs mymaster 1 # sentinel failover-timeout <master-name> <milliseconds> # # Specifies the failover timeout in milliseconds. It is used in many ways: # # - The time needed to re-start a failover after a previous failover was # already tried against the same master by a given Sentinel, is two # times the failover timeout. # # - The time needed for a replica replicating to a wrong master according # to a Sentinel current configuration, to be forced to replicate # with the right master, is exactly the failover timeout (counting since # the moment a Sentinel detected the misconfiguration). # # - The time needed to cancel a failover that is already in progress but # did not produced any configuration change (SLAVEOF NO ONE yet not # acknowledged by the promoted replica). # # - The maximum time a failover in progress waits for all the replicas to be # reconfigured as replicas of the new master. However even after this time # the replicas will be reconfigured by the Sentinels anyway, but not with # the exact parallel-syncs progression as specified. # # Default is 3 minutes. sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION # # sentinel notification-script and sentinel reconfig-script are used in order # to configure scripts that are called to notify the system administrator # or to reconfigure clients after a failover. The scripts are executed # with the following rules for error handling: # # If script exits with "1" the execution is retried later (up to a maximum # number of times currently set to 10). # # If script exits with "2" (or an higher value) the script execution is # not retried. # # If script terminates because it receives a signal the behavior is the same # as exit code 1. # # A script has a maximum running time of 60 seconds. After this limit is # reached the script is terminated with a SIGKILL and the execution retried. # NOTIFICATION SCRIPT # # sentinel notification-script <master-name> <script-path> # # Call the specified notification script for any sentinel event that is # generated in the WARNING level (for instance -sdown, -odown, and so forth). # This script should notify the system administrator via email, SMS, or any # other messaging system, that there is something wrong with the monitored # Redis systems. # # The script is called with just two arguments: the first is the event type # and the second the event description. # # The script must exist and be executable in order for sentinel to start if # this option is provided. # # Example: # # sentinel notification-script mymaster /var/redis/notify.sh # CLIENTS RECONFIGURATION SCRIPT # # sentinel client-reconfig-script <master-name> <script-path> # # When the master changed because of a failover a script can be called in # order to perform application-specific tasks to notify the clients that the # configuration has changed and the master is at a different address. # # The following arguments are passed to the script: # # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # # <state> is currently always "failover" # <role> is either "leader" or "observer" # # The arguments from-ip, from-port, to-ip, to-port are used to communicate # the old address of the master and the new address of the elected replica # (now a master). # # This script should be resistant to multiple invocations. # # Example: # # sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # SECURITY # # By default SENTINEL SET will not be able to change the notification-script # and client-reconfig-script at runtime. This avoids a trivial security issue # where clients can set the script to anything and trigger a failover in order # to get the program executed. sentinel deny-scripts-reconfig yes # REDIS COMMANDS RENAMING # # Sometimes the Redis server has certain commands, that are needed for Sentinel # to work correctly, renamed to unguessable strings. This is often the case # of CONFIG and SLAVEOF in the context of providers that provide Redis as # a service, and don't want the customers to reconfigure the instances outside # of the administration console. # # In such case it is possible to tell Sentinel to use different command names # instead of the normal ones. For example if the master "mymaster", and the # associated replicas, have "CONFIG" all renamed to "GUESSME", I could use: # # SENTINEL rename-command mymaster CONFIG GUESSME # # After such configuration is set, every time Sentinel would use CONFIG it will # use GUESSME instead. Note that there is no actual need to respect the command # case, so writing "config guessme" is the same in the example above. # # SENTINEL SET can also be used in order to perform this configuration at runtime. # # In order to set a command back to its original name (undo the renaming), it # is possible to just rename a command to itsef: # # SENTINEL rename-command mymaster CONFIG CONFIG

2021年09月21日
158 阅读
0 评论
0 点赞

2021-09-21

Redis持久化 Redis持久化　　redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一但服务器进程退出，服务器中的数据库状态也会消失，所有redis提供了持久化功能redis 提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。　　RDB，简而言之，就是在不同的时间点，将 redis 存储的数据生成快照并存储到磁盘等介质上；　　AOF，则是换了一个角度来实现持久化，那就是将 redis 执行过的所有写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。　　其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高。　　如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一个纯内存数据库，就像 memcache 一样。redis持久化RDB　　RDB 方式，是将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。　　redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。对于 RDB 方式，redis 会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何 IO 操作的，这样就确保了 redis 极高的性能。　　如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。　　虽然 RDB 有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么 RDB 方式就不太适合你，因为即使你每 5 分钟都持久化一次，当 redis 故障时，仍然会有近 5 分钟的数据丢失。所以，redis 还提供了另一种持久化方式，那就是 AOF。测试触发机制1、save的规则满足的情况下，会自动触发rdb规则2、执行flushall命令也会触发rdb规则3、退出redis,也会产生rdb文件备份就会自动产生一个dump.rdp如何恢复rdb文件1、只需要rdb文件放在我们redis启动目录就可以了 redis会自动检查dump.rdp恢复其中的数据2、检查需要存在的位置127.0.0.1:6379> config get dir 1) "dir" 2) "/usr/local/bin"优点：适合大规模的数据恢复对数据完整性要求不高缺点：需要一定的时间间隔进程操作，如果redis宕机，这个最好一次修改数据就没有了fork进程的时候，会占用一定的内容空间redis持久化AOF　　AOF，英文是 Append Only File，即只允许追加不允许改写的文件。　　如前面介绍的，AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。　　我们通过配置 redis.conf 中的 appendonly yes 就可以打开 AOF 功能。如果有写操作（如 SET 等），redis 就会被追加到 AOF 文件的末尾。　　默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync 是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis 仍然可以保持很好的处理性能，即使 redis 故障，也只会丢失最近 1 秒钟的数据。如果在追加日志时，恰好遇到磁盘空间满、inode 满或断电等情况导致日志写入不完整，也没有关系，redis 提供了 redis-check-aof 工具，可以用来进行日志修复。　　因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis 提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了 100 次 INCR 指令，在 AOF 文件中就要存储 100 条指令，但这明显是很低效的，完全可以把这 100 条指令合并成一条 SET 指令，这就是重写机制的原理。在进行 AOF 重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响 AOF 文件的可用性，这点大家可以放心。　　AOF 方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作 redis 时，不小心执行了 FLUSHALL，导致 redis 内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要 redis 配置了 AOF 持久化方式，且 AOF 文件还没有被重写（rewrite），我们就可以用最快的速度暂停 redis 并编辑 AOF 文件，将最后一行的 FLUSHALL 命令删除，然后重启 redis，就可以恢复 redis 的所有数据到 FLUSHALL 之前的状态了。是不是很神奇，这就是 AOF 持久化方式的好处之一。但是如果 AOF 文件已经被重写了，那就无法通过这种方法来恢复数据了。虽然优点多多，但 AOF 方式也同样存在缺陷，比如在同样数据规模的情况下，AOF 文件要比 RDB 文件的体积大。而且，AOF 方式的恢复速度也要慢于 RDB 方式。　　如果你直接执行 BGREWRITEAOF 命令，那么 redis 会生成一个全新的 AOF 文件，其中便包括了可以恢复现有数据的最少的命令集。　　如果运气比较差，AOF 文件出现了被写坏的情况，也不必过分担忧，redis 并不会贸然加载这个有问题的 AOF 文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：1.备份被写坏的 AOF 文件2.运行 redis-check-aof –fix 进行修复3.用 diff -u 来看下两个文件的差异，确认问题点4.重启 redis，加载修复后的 AOF 文件redis持久化 – AOF重写　　AOF 重写的内部运行原理，我们有必要了解一下。　　在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。　　与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。　　当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中。　　当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了。测试如果aof文件有错误，这个时候redis是启动不起来的，需要修复这个aof文件redis-check-aof[root@cs bin]# redis-check-aof --fix appendonly.aof 0x 4: Expected prefix '$', got: 'e' AOF analyzed: size=122, ok_up_to=0, diff=122 This will shrink the AOF from 122 bytes, with 122 bytes, to 0 bytes Continue? [y/N]: y Successfully truncated AOF优点：每次修改都同步，文件的完整性更好每秒同步一次可能会丢失一秒数据从不同步，效率最高缺点：相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化redis持久化 – 如何选择RDB和AOF对于我们应该选择 RDB 还是 AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。

2021年09月21日
96 阅读
0 评论
0 点赞

罗小黑

绿水本无忧，因风皱面

青山原不老，为雪白头