，学习才是最终的归宿，过年🧧红包发的收的感觉不用上班一样。
Crer_lu
获得徽章 1
赞了这篇文章
#青训营笔记创作活动#
1.28 day13
本文是介绍MySQL底层架构的，它主要分为四个部分
1. 网络连接层：负责用户与服务器之间建立连接，采用半双工通讯机制
- 全双工：代表通讯的双方在同一时间内，即可以发送数据，也可以接收数据。
- 半双工：代表同一时刻内，单方要么只能发送数据，要么只能接受数据。
- 单工：当前连接只能发送数据或只能接收数据，也就是“单向类型的通道”。
2. 系统服务层：SQL接口、解析器、优化器、缓存&缓冲
3. 系统引擎层：负责执行具体的数据操作
4. 文件系统层：是MySQL的基石，本质上就是基于物理磁盘的一个文件系统
1.28 day13
本文是介绍MySQL底层架构的，它主要分为四个部分
1. 网络连接层：负责用户与服务器之间建立连接，采用半双工通讯机制
- 全双工：代表通讯的双方在同一时间内，即可以发送数据，也可以接收数据。
- 半双工：代表同一时刻内，单方要么只能发送数据，要么只能接受数据。
- 单工：当前连接只能发送数据或只能接收数据，也就是“单向类型的通道”。
2. 系统服务层：SQL接口、解析器、优化器、缓存&缓冲
3. 系统引擎层：负责执行具体的数据操作
4. 文件系统层：是MySQL的基石，本质上就是基于物理磁盘的一个文件系统
展开
评论
点赞
#青训营笔记创作活动#
1.28 day12
本文主要围绕着HTTPS加密协议——TLS协议/SSL证书的介绍展开的
HTTPS建立连接时首先要经历TCP三次握手，然后进入到TLS的四次握手
1. 第一次从客户端到服务端，客户端发送的信息包括加密协议版本、加密套件和一个随机数（Client Random）
2. 第二次从服务端到客户端，服务端发送的信息包括确定下来的加密协议版本、服务器证书和一个随机数（Server Random）
3. 第三次从客户端到服务端，首先客户端接收到第二次的响应后，会用hash解密证书（公钥、持有者信息、有效时间、证书认证机构（CA）的信息、其他信息），然后验证它的有效性，然后生成一个随机数（pre-master），并且用服务端的公钥加密（等会服务端会用私钥解密），然后用三个随机数生成“会话密钥”，用它来进行加密通信，然后用这个密钥加密迄今为止所有的通信内容，发送给服务器（等会服务器用它来校验）
4. 第四次从服务端到客户端，首先通过私钥解密pre-master的密文， 然后集齐三个随机数后生成“会话密钥”，然后再用会话密钥进行校验，如果通过，则接下来都用这个密钥进行加密通信，
Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是截取网络封包，并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。
在过去，网络封包分析软件是非常昂贵的，或是专门属于盈利用的软件。Ethereal的出现改变了这一切。在GNUGPL通用许可证的保障范围底下，使用者可以以免费的途径取得软件与其源代码，并拥有针对其源代码修改及客制化的权利。Ethereal是全世界最广泛的网络封包分析软件之一
1.28 day12
本文主要围绕着HTTPS加密协议——TLS协议/SSL证书的介绍展开的
HTTPS建立连接时首先要经历TCP三次握手，然后进入到TLS的四次握手
1. 第一次从客户端到服务端，客户端发送的信息包括加密协议版本、加密套件和一个随机数（Client Random）
2. 第二次从服务端到客户端，服务端发送的信息包括确定下来的加密协议版本、服务器证书和一个随机数（Server Random）
3. 第三次从客户端到服务端，首先客户端接收到第二次的响应后，会用hash解密证书（公钥、持有者信息、有效时间、证书认证机构（CA）的信息、其他信息），然后验证它的有效性，然后生成一个随机数（pre-master），并且用服务端的公钥加密（等会服务端会用私钥解密），然后用三个随机数生成“会话密钥”，用它来进行加密通信，然后用这个密钥加密迄今为止所有的通信内容，发送给服务器（等会服务器用它来校验）
4. 第四次从服务端到客户端，首先通过私钥解密pre-master的密文， 然后集齐三个随机数后生成“会话密钥”，然后再用会话密钥进行校验，如果通过，则接下来都用这个密钥进行加密通信，
Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是截取网络封包，并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。
在过去，网络封包分析软件是非常昂贵的，或是专门属于盈利用的软件。Ethereal的出现改变了这一切。在GNUGPL通用许可证的保障范围底下，使用者可以以免费的途径取得软件与其源代码，并拥有针对其源代码修改及客制化的权利。Ethereal是全世界最广泛的网络封包分析软件之一
展开
评论
点赞
赞了这篇文章
#青训营笔记创作活动#
1.18 day10
TCP和UDP对待丢包的态度是完全不一样的：
UDP：”哦，丢包了关我什么事“
TCP：”丢包了？！我马上重发一下“（但是使用TCP协议也是可能出现丢包的，详见
juejin.cn）
不过如果经常出现重发，这是对资源的浪费。
TCP的特性有以下几点：
1. 重发机制：
2. 滑动窗口机制：接收端有时候处理的快，有时候处理的慢，
3. 拥塞控制机制：这里与处理能力无关，主要是外部环境是否够好，TCP会先从少量发送，然后逐渐扩大，直到找到一个相对稳定的值。
4. 分段机制：当某个数据包十分大时，考虑把它进行分割
5. 乱序重排机制：接收方收到包的顺序可能会乱，等到所有都到了之后再根据sequence进行排序
6. 连接机制：TCP面向连接，而UDP不面向连接，所以可靠性基本全靠TCP来保证，UDP丢包丢到你怀疑人生
UDP一定比TCP快吗？
通常我们在使用UDP时，由于忌惮它的丢包，我们通常会在应用层做一些机制处理。这个问题的答案其实是大多数，不过也有UDP比较慢的时候。比如对于TCP的分段是在传输层，而UDP如果在应用层没有实现分段的话，可能就会导致发送大数据包时频繁重发导致效率降低的情况。
1.18 day10
TCP和UDP对待丢包的态度是完全不一样的：
UDP：”哦，丢包了关我什么事“
TCP：”丢包了？！我马上重发一下“（但是使用TCP协议也是可能出现丢包的，详见
juejin.cn）不过如果经常出现重发，这是对资源的浪费。
TCP的特性有以下几点：
1. 重发机制：
2. 滑动窗口机制：接收端有时候处理的快，有时候处理的慢，
3. 拥塞控制机制：这里与处理能力无关，主要是外部环境是否够好，TCP会先从少量发送，然后逐渐扩大，直到找到一个相对稳定的值。
4. 分段机制：当某个数据包十分大时，考虑把它进行分割
5. 乱序重排机制：接收方收到包的顺序可能会乱，等到所有都到了之后再根据sequence进行排序
6. 连接机制：TCP面向连接，而UDP不面向连接，所以可靠性基本全靠TCP来保证，UDP丢包丢到你怀疑人生
UDP一定比TCP快吗？
通常我们在使用UDP时，由于忌惮它的丢包，我们通常会在应用层做一些机制处理。这个问题的答案其实是大多数，不过也有UDP比较慢的时候。比如对于TCP的分段是在传输层，而UDP如果在应用层没有实现分段的话，可能就会导致发送大数据包时频繁重发导致效率降低的情况。
展开
评论
点赞
赞了这篇文章
#青训营笔记创作活动#
1.18 day8
今天的文章是围绕kafka消息处理机制展开的，首先介绍了kafka的特性，然后就从版本迭代角度详细解释，最后回答了一些常见的疑问，不过感觉技术还是太超前了，值得后续跟进学习
1.18 day8
今天的文章是围绕kafka消息处理机制展开的，首先介绍了kafka的特性，然后就从版本迭代角度详细解释，最后回答了一些常见的疑问，不过感觉技术还是太超前了，值得后续跟进学习
评论
点赞
赞了这篇沸点
#青训营笔记创作活动#
1.16 day7
Day7：websocket与http
一个例子引入——扫码登陆的场景
两种解决方案：http不断轮询（占用大量资源而且卡顿）和长轮询（增大http的等待时间）
全双工：客户端和服务端都可以主动向对方发送信息（TCP协议就具有这样的特点）
但是我们平时使用的http1.1，虽然是基于TCP，但是半双工的，即客户端发送请求，服务端才会返回数据
那么这就意味着如果我们想要用http1.1处理网页游戏场景，是不太可能的
websocket的出现就是为了解决这个问题，它的建立首先是三次TCP握手建立连接，然后经过http协议进行一次通信，不过在这次通信中会增加header表示uprade请求，还有增加一个base64码，服务端收到后会用某公开算法进行计算并返回，同时配上101状态码，如果客户端收到的不是200而是101，那就把刚刚base64进行计算并于收到的计算结果进行核对，如果核对成功，那就进入websocket协议阶段，之后就与http协议无关了
1.16 day7
Day7：websocket与http
一个例子引入——扫码登陆的场景
两种解决方案：http不断轮询（占用大量资源而且卡顿）和长轮询（增大http的等待时间）
全双工：客户端和服务端都可以主动向对方发送信息（TCP协议就具有这样的特点）
但是我们平时使用的http1.1，虽然是基于TCP，但是半双工的，即客户端发送请求，服务端才会返回数据
那么这就意味着如果我们想要用http1.1处理网页游戏场景，是不太可能的
websocket的出现就是为了解决这个问题，它的建立首先是三次TCP握手建立连接，然后经过http协议进行一次通信，不过在这次通信中会增加header表示uprade请求，还有增加一个base64码，服务端收到后会用某公开算法进行计算并返回，同时配上101状态码，如果客户端收到的不是200而是101，那就把刚刚base64进行计算并于收到的计算结果进行核对，如果核对成功，那就进入websocket协议阶段，之后就与http协议无关了
展开
评论
点赞
#青训营笔记创作活动#
1.14 day6
分阶段进行解释：
1. Discover：采用广播方式（采用UDP，而TCP做不到），同一局域网内的多个DHCP服务器可能都会接收到，其中包含了Client的一些基本信息，比如mac地址等
2. Offer：DHCP服务器收到请求后，会从自己空余的IP池中分配一个给Client，并且以广播或单播的形式返回（取决于Discover阶段时一个参数值，Broadcast flag=0，表明接受单播），单播的原因是，处理和判断局域网内的消息是需要耗费CPU资源的，所以尽量采用单播可以避免冗杂的判断处理，节省资源。
3. Request：再次确认就是用这个IP，就像是你给HR发自己最后的决定。
4. ACK：HR在收到你的最终决定后，再确认一下这个岗位是否空闲，如果有，则放回ACK，否则是NAK
当以上所有做完后，Client会发送三次无偿ARP[Gratuitous ARP]消息（就像发pyq炫offer），包含本机mac地址和分配得到的IP地址，来保证局域网内IP地址不冲突，并且其它Client在收到消息后，会选择存在自己的ARP缓存中，便于后续建立连接。
【注意：如果之前已经建立过连接，那么1 2阶段会自动跳过，因为在Client缓存中有曾经分配到的IP，只需要再确认下能不能用即可，如果不行，就重新从1来过】
1.14 day6
分阶段进行解释：
1. Discover：采用广播方式（采用UDP，而TCP做不到），同一局域网内的多个DHCP服务器可能都会接收到，其中包含了Client的一些基本信息，比如mac地址等
2. Offer：DHCP服务器收到请求后，会从自己空余的IP池中分配一个给Client，并且以广播或单播的形式返回（取决于Discover阶段时一个参数值，Broadcast flag=0，表明接受单播），单播的原因是，处理和判断局域网内的消息是需要耗费CPU资源的，所以尽量采用单播可以避免冗杂的判断处理，节省资源。
3. Request：再次确认就是用这个IP，就像是你给HR发自己最后的决定。
4. ACK：HR在收到你的最终决定后，再确认一下这个岗位是否空闲，如果有，则放回ACK，否则是NAK
当以上所有做完后，Client会发送三次无偿ARP[Gratuitous ARP]消息（就像发pyq炫offer），包含本机mac地址和分配得到的IP地址，来保证局域网内IP地址不冲突，并且其它Client在收到消息后，会选择存在自己的ARP缓存中，便于后续建立连接。
【注意：如果之前已经建立过连接，那么1 2阶段会自动跳过，因为在Client缓存中有曾经分配到的IP，只需要再确认下能不能用即可，如果不行，就重新从1来过】
展开
评论
点赞
#青训营笔记创作活动#
1.13 day5
今天的文章讲到了一些关于Mysql语句设计不当导致效率下降甚至失败的情况，感觉是一篇好文章，不过由于我的Mysql基础少，希望之后补起来基础后来重新拜读一下。
1.13 day5
今天的文章讲到了一些关于Mysql语句设计不当导致效率下降甚至失败的情况，感觉是一篇好文章，不过由于我的Mysql基础少，希望之后补起来基础后来重新拜读一下。
评论
点赞
#青训营笔记创作活动#
1.13 day4
三刷官方文档
这是转方向时极为有效的学习方式
客户端与服务端的理解
前者的核心是“页面驱动设计”，后者的核心是“数据驱动设计”
而更为深刻的方式是“领域驱动设计”（DDD）
这里对领域驱动设计做一些介绍，它讲求的是不以用户为中心，即在设计时按照不同的方面进行划分（就像我们平时生活中的互联网领域，传统工科领域等），所以归纳来讲，就是“客观性”，进而我们就能实现功能的解耦，形成各个领域的接口交互，方便团队协作，这其实更多地需要开发经验才能理解透彻。
微服务就可以让DDD落地，这个后续再进行学习
1.13 day4
三刷官方文档
这是转方向时极为有效的学习方式
客户端与服务端的理解
前者的核心是“页面驱动设计”，后者的核心是“数据驱动设计”
而更为深刻的方式是“领域驱动设计”（DDD）
这里对领域驱动设计做一些介绍，它讲求的是不以用户为中心，即在设计时按照不同的方面进行划分（就像我们平时生活中的互联网领域，传统工科领域等），所以归纳来讲，就是“客观性”，进而我们就能实现功能的解耦，形成各个领域的接口交互，方便团队协作，这其实更多地需要开发经验才能理解透彻。
微服务就可以让DDD落地，这个后续再进行学习
展开
评论
点赞
#青训营笔记创作活动#
1.13 day3
今天是一篇硬干货，通过对B+树的特性分析（Innodb和B+树还没学过），得到了数据Max应为1000万左右的结论，之后自己有相关的经验再回来读这篇文章吧
1.13 day3
今天是一篇硬干货，通过对B+树的特性分析（Innodb和B+树还没学过），得到了数据Max应为1000万左右的结论，之后自己有相关的经验再回来读这篇文章吧
评论
点赞
#青训营笔记创作活动#
1.12 day2
今天是一些关于IntelliJ IDEA 这个软件的一些插件介绍，从介绍来看是一款非常接近真实软件开发级别的IDE，可能将来会用到一些相关的东西吧
1.12 day2
今天是一些关于IntelliJ IDEA 这个软件的一些插件介绍，从介绍来看是一款非常接近真实软件开发级别的IDE，可能将来会用到一些相关的东西吧
评论
点赞
#青训营笔记创作活动#
1.11 打卡day1
今天学习了高并发场景下限流的方案，总结如下
计数器：用一个counter来技术一定时间内的请求数，超出狗则拒绝请求，不能处理边界情况。
滑动窗口：滑动窗口是计数器更一般的实现方式，通过动态添加新的请求数和删除最早的请求数来实现，有优化，但还是不能处理边界。
桶漏限流：通过把请求当做水倒入桶中，并且桶以固定流速流出，不能解决突发流量（最大流入速率为桶漏的速率）
令牌桶：一个桶内放着一些令牌，每有请求发过来我们就拿出相应数量的令牌来抵消，并且我们单位时间会放入一定的令牌进去桶中，可以解决突发流量。
Redis+Lua分布式限流：这个是没太学明白的一个，需要后续学习认知，大意是我们以集群为维度，方便地控制整个请求。
1.11 打卡day1
今天学习了高并发场景下限流的方案，总结如下
计数器：用一个counter来技术一定时间内的请求数，超出狗则拒绝请求，不能处理边界情况。
滑动窗口：滑动窗口是计数器更一般的实现方式，通过动态添加新的请求数和删除最早的请求数来实现，有优化，但还是不能处理边界。
桶漏限流：通过把请求当做水倒入桶中，并且桶以固定流速流出，不能解决突发流量（最大流入速率为桶漏的速率）
令牌桶：一个桶内放着一些令牌，每有请求发过来我们就拿出相应数量的令牌来抵消，并且我们单位时间会放入一定的令牌进去桶中，可以解决突发流量。
Redis+Lua分布式限流：这个是没太学明白的一个，需要后续学习认知，大意是我们以集群为维度，方便地控制整个请求。
展开
评论
点赞