学习路线:
这个方向初期比较容易入门一些,掌握一些基本技术,拿起各种现成的工具就可以开黑了。不过,要想从脚本小子变成黑客大神,这个方向越往后,需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容:
需要体系化学习资料的朋友,可以加我V获取:vip204888 (备注网络安全)
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
redis的主从复制分为三个阶段:
1)slave连接master(建立连接阶段)
2)master同步数据到slave(数据同步阶段)
3)期间master接到来自客户端"写"的命令之后需要将数据同步到slave(命令传播阶段)
1.2.1 建立连接阶段
在主从配置的建立连接阶段master与slave之间会做如下操作:
1)slave发送slaveof masterhost masterport
命令连接master
2)master接到来自slave的连接,并开始响应对方。
3)slave得到响应之后将masterhost与masterport及一些其他的master信息保存到slave端。
4)slave确保连接无误后开始创建socket通道,用于后续的数据复制工作。
5)slave与master之间周期性的发送ping心跳,检查slave与master之间是否通信正常。
6)master接收到slave的ping心跳后会给对应的slave响应pong。
7)slave发送本机设置的master密码masterauth
来到master进行验证(master有设置密码的情况下)。
8)master进行身份识别,如果身份错误则端口此slave的socket通道,并尝试重新连接。服务器端报如下错误:
MASTER aborted replication with an error: NOAUTH Authentication required.
9)master身份识别成功后slave会将自己的ip、端口等信息发送到master,master将保存此slave的ip、端口以及一些其他状态信息,记录在info Replication。
- 主从复制命令:
slave连接master,在slave的客户端输入如下命令:
slaveof <masterip> <masterport>
示例:
127.0.0.1:6379> slaveof 192.168.170.142 6379
OK
127.0.0.1:6379>
如果master设置了密码,那么在slave服务器启动的时候就要指定master的密码:
redis-server ../config/redis-6379.conf --masterauth admin
分别查看slave与master启动日志:
- master日志:
23305:M 11 Apr 10:24:20.225 * Slave 127.0.0.1:6479 asks for synchronization
23305:M 11 Apr 10:24:20.225 * Partial resynchronization not accepted: Replication ID mismatch (Slave asked for '18b61ced5990337dd8377e8bf81fcd2b20e7d399', my replication IDs are 'fa4d40f8562c10acbbd7a9955a88f7cd6dc33182' and '0000000000000000000000000000000000000000')
23305:M 11 Apr 10:24:20.225 * Starting BGSAVE for SYNC with target: disk
23305:M 11 Apr 10:24:20.225 * Background saving started by pid 23339
23339:C 11 Apr 10:24:20.227 * DB saved on disk
23339:C 11 Apr 10:24:20.227 * RDB: 2 MB of memory used by copy-on-write
23305:M 11 Apr 10:24:20.315 * Background saving terminated with success
23305:M 11 Apr 10:24:20.315 * Synchronization with slave 127.0.0.1:6479 succeeded
- slave日志:
23279:S 11 Apr 10:24:20.224 * Connecting to MASTER 127.0.0.1:6379
23279:S 11 Apr 10:24:20.224 * MASTER <-> SLAVE sync started
23279:S 11 Apr 10:24:20.224 * Non blocking connect for SYNC fired the event.
23279:S 11 Apr 10:24:20.224 * Master replied to PING, replication can continue...
23279:S 11 Apr 10:24:20.224 * Trying a partial resynchronization (request 18b61ced5990337dd8377e8bf81fcd2b20e7d399:1).
23279:S 11 Apr 10:24:20.226 * Full resync from master: f1d39130cfadf4b3e0eb192e4143ae6bcb01677b:0
23279:S 11 Apr 10:24:20.226 * Discarding previously cached master state.
23279:S 11 Apr 10:24:20.315 * MASTER <-> SLAVE sync: receiving 176 bytes from master
23279:S 11 Apr 10:24:20.315 * MASTER <-> SLAVE sync: Flushing old data
23279:S 11 Apr 10:24:20.315 * MASTER <-> SLAVE sync: Loading DB in memory
23279:S 11 Apr 10:24:20.316 * MASTER <-> SLAVE sync: Finished with success
23279:S 11 Apr 10:24:20.316 * Background append only file rewriting started by pid 23340
23279:S 11 Apr 10:24:20.356 * AOF rewrite child asks to stop sending diffs.
23340:C 11 Apr 10:24:20.356 * Parent agreed to stop sending diffs. Finalizing AOF...
23340:C 11 Apr 10:24:20.356 * Concatenating 0.00 MB of AOF diff received from parent.
23340:C 11 Apr 10:24:20.356 * SYNC append only file rewrite performed
23340:C 11 Apr 10:24:20.357 * AOF rewrite: 6 MB of memory used by copy-on-write
23279:S 11 Apr 10:24:20.426 * Background AOF rewrite terminated with success
23279:S 11 Apr 10:24:20.426 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
23279:S 11 Apr 10:24:20.426 * Background AOF rewrite finished successfully
- 当master宕机后slave会一直尝试连接Master,日志信息如下:
29511:S 11 Apr 10:37:37.567 # Error condition on socket for SYNC: Connection refused
29511:S 11 Apr 10:37:38.577 * Connecting to MASTER 127.0.0.1:6379
29511:S 11 Apr 10:37:38.577 * MASTER <-> SLAVE sync started
29511:S 11 Apr 10:37:38.577 # Error condition on socket for SYNC: Connection refused
29511:S 11 Apr 10:37:39.587 * Connecting to MASTER 127.0.0.1:6379
29511:S 11 Apr 10:37:39.587 * MASTER <-> SLAVE sync started
29511:S 11 Apr 10:37:39.587 # Error condition on socket for SYNC: Connection refused
29511:S 11 Apr 10:37:40.597 * Connecting to MASTER 127.0.0.1:6379
29511:S 11 Apr 10:37:40.597 * MASTER <-> SLAVE sync started
29511:S 11 Apr 10:37:40.597 # Error condition on socket for SYNC: Connection refused
29511:S 11 Apr 10:37:41.606 * Connecting to MASTER 127.0.0.1:6379
slave端口与master的连接(断开与master连接后,slave不再接收master的同步数据):
slaveof no one
1.2.2 数据同步阶段
1.2.2.1 工作流程
在master与slave建立连接成功后,开始数据同步。
1)slave发送psync2(psync1、sync)指令给master,需要同步时数据
2)master接到指令后开始执行bgsave指令,并创建复制积压缓冲区,在此期间,master接收到任何来自客户端的"写"操作都会记录在复制积压缓冲区一份。
3)master将rdb通过前面创建的socket通道发送给slave
4)slave接收到rdb文件后,清空当前机器的所有数据,开始同步rdb中的数据
5)告知master文件以及恢复完毕
6)master将复制积压缓冲区中的指令发送给slave
7)slave将接收到的指令执行bgrewriteaof重写,之后进行数据恢复
步骤1-4属于全量同步
步骤5-7属于增量同步
1.2.2.2 增量同步原理
从上图可以看出,在master执行bgsave期间接收到的所有命令都会存放在复制积压缓冲区一份,而复制积压缓冲区的大小是有限度的,默认是1MB,如果缓冲区已经满了,则会把最前面的数据挤出去(删除),后期进行增量同步时发现数据不一致,则会进行全量同步,从而造成同步死循环,因此复制积压缓冲区不易设置为太小。
- 查看复制积压缓冲区:
127.0.0.1:6379> config get repl-backlog-size
1) "repl-backlog-size"
2) "1048576"
127.0.0.1:6379>
- 调整复制积压缓冲区大小:
repl-backlog-size 2096576
1.2.3 命令传播阶段
master与slave保持连接后,此后master接到来自客户端"写"的命令之后,需要将数据同步各个slave端,此阶段叫命令传播阶段。
1.2.3.1 偏移量(offset)
在数据同步中,master与slave之间分别维护着一个offset偏移量,用于存储增量同步时主节点发送给从节点数据的位置,这样利于在网络抖动情况下,主从节点之间还可以继续接着上一次同步的位置进行同步,而不必要进行全量同步。
假设在命令传播时,master在传输到"4"这个字节时出现网络抖动,那么master与slave都会将此offset的值(7)保存起来,下次同步数据时,slave带着此offset来到master继续增量同步数据,而不需要重新全量同步数据。
1.2.3.2 运行id(runid)
在上一小结说了master与slave之间都维护着一个offset偏移量,让我们可以根据offset的偏移量进行增量同步,避免网络抖动情况下进行全量同步。
但是如果在同步的过程中切换了master节点则会出现问题,因为新的master节点并没有维护着offset偏移量,并且slave中的数据应该与新master节点数据保持一致。那么redis是如何做到的呢?
其实在master与slave服务器启动时都保存有一个由40位随机的16进制字符串组成的运行id(runid),用于标识一台唯一的redis,每次启动都不一样。在info的server组下可以查看到
info server
本人从事网路安全工作12年,曾在2个大厂工作过,安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过,对这个行业了解比较全面。
最近遍览了各种网络安全类的文章,内容参差不齐,其中不伐有大佬倾力教学,也有各种不良机构浑水摸鱼,在收到几条私信,发现大家对一套完整的系统的网络安全从学习路线到学习资料,甚至是工具有着不小的需求。
最后,我将这部分内容融会贯通成了一套282G的网络安全资料包,所有类目条理清晰,知识点层层递进,需要的小伙伴可以点击下方小卡片领取哦!下面就开始进入正题,如何从一个萌新一步一步进入网络安全行业。
![](https://img-blog.csdnimg.cn/img_convert/311903982dea1d8a5d2c98fc271b5b41.jpeg)
**需要体系化学习资料的朋友,可以加我V获取:vip204888 (备注网络安全)**
### 学习路线图
其中最为瞩目也是最为基础的就是网络安全学习路线图,这里我给大家分享一份打磨了3个月,已经更新到4.0版本的网络安全学习路线图。
相比起繁琐的文字,还是生动的视频教程更加适合零基础的同学们学习,这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。
![](https://img-blog.csdnimg.cn/img_convert/1ddfaf7dc5879b1120e31fafa1ad4dc7.jpeg)
#### 网络安全工具箱
当然,当你入门之后,仅仅是视频教程已经不能满足你的需求了,你肯定需要学习各种工具的使用以及大量的实战项目,这里也分享一份**我自己整理的网络安全入门工具以及使用教程和实战。**
![](https://img-blog.csdnimg.cn/img_convert/bcd1787ce996787388468bb227d8f959.jpeg)
#### 项目实战
最后就是项目实战,这里带来的是**SRC资料&HW资料**,毕竟实战是检验真理的唯一标准嘛~
![](https://img-blog.csdnimg.cn/img_convert/35fc46df24091ce3c9a5032a9919b755.jpeg)
#### 面试题
归根结底,我们的最终目的都是为了就业,所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过!
**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
**[需要这份系统化资料的朋友,可以点击这里获取](https://bbs.csdn.net/topics/618540462)**
**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**