TerminalLight
本科生
获得徽章 1
- #青训营笔记创作活动#
1月22日 打卡day10
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
· 用UDP就一定比用TCP快吗？什么情况下用UDP会比用TCP慢？
大部分情况下，因为UDP没有复杂的TCP可靠性机制，所以会很快。具体展开来说，就是TCP为了实现可靠性而引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制，而UDP则没有实现，因此一般来说TCP比UDP快。
TCP是面向连接的协议，而UDP是无连接的协议。这里的"连接"其实是，操作系统内核在两端代码里维护的一套复杂状态机。
大部分项目，会在基于UDP的基础上，模仿TCP，实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套重传机制。
对于UDP+重传的场景，如果要传超大数据包，并且没有实现分段机制的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下TCP更快。展开赞过 评论1 - #青训营笔记创作活动#
1月21日 打卡day9
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
1.如何结合文档学习语法
如果只是在文档的学习中遇到的问题解决的情况下，如果无法正确理解的时候，从词性、时态、句型、从句等方面去针对性的查找。
2.“笨”方法找到适合自己的路
在工作中遇到的问题，查找、分解的方法。总的来说大概几个方面，包括:
搜索
翻译
找文献
分解复杂句子
查找语法知识
3.中文翻译文献模棱两可怎么办
相信对于你的感到模糊的词汇或者句子，在谷歌、百度、韦氏、剑桥、牛津五家线上词典的围攻下将你的疑问降低到零。展开赞过 评论1 - #青训营笔记创作活动#
1月20日 打卡day8
根据文章作者总结与阅读文章标注重点，该篇文章的概念要点如下：
一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干 Consumer，以及一个 ZooKeeper 集群。
（1）ZooKeeper 是 Kafka 用来负责集群元数据的管理、控制器的选举等操作的。
（2）Producer：生产者，也就是发送消息的一方。生产者负责创建消息，然后将其投递到 Kafka 中。Producer 将消息发送到 Broker。
（3）Broker：服务代理节点。Broker 负责将收到的消息存储到磁盘中。Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例，也可看作一台 Kafka 服务器（前提服务器上只部署了一个 Kafka 实例）。一个或多个 Broker 组成了一个 Kafka 集群。
（4）Consumer：消费者，接收消息的一方。消费者连接到 Kafka 上并接收消息，进而进行相应的业务逻辑处理。Consumer 负责从 Broker 订阅并消费消息。
（5）Topic：主题。Kafka 中的消息以 topic 题为单位进行归类，生产者负责将消息发送到特定的 topic，而消费者负责订阅主题并进行消费。
（6）Partition：分区。主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区（Topic-Partition）。每一条消息被发送到 broker 之前，会根据分区规则选择被存储到哪个具体的分区。如果分区规则设定得合理，所有的消息都可以均匀地分配在不同的分区中。
（7）Consumer Group：消费组。每个消费者都有一个对应的消费组。当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。展开赞过 评论1 - #青训营笔记创作活动#
1月19日 打卡day7
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
看起来服务器主动发消息给客户端的场景（伪服务器推的形式）的实现：
· 关键痛点：怎么样才能在用户不做任何操作的情况下，网页能收到消息并发生变更。
（1）解决方法-1：使用HTTP不断轮询
网页的前端代码里不断定时发HTTP请求到服务器，服务器收到请求后给客户端响应消息；它其实并不是服务器主动发消息到客户端，而是客户端自己不断偷偷请求服务器，只是用户无感知而已。
· 应用场景：扫码登录
· 缺点：
① HTTP请求消耗带宽，同时也会增加下游服务器的负担。
② 最坏情况下每次执行时正好才触发下一次http请求，然后才执行相关逻辑，用户会感到明显的卡顿。
（2）解决方法-2：使用HTTP不断轮询
将HTTP请求超时设置的很大；本质上其实还是客户端主动去取数据；
发起一个请求并在较长时间内等待服务器响应的机制，就是长训轮机制；
在用户不感知的情况下，服务器将数据推送给浏览器的技术，就是所谓的服务器推送技术。
· 应用场景：常用的消息队列RocketMQ中消费者去取数据时用到这种方式。
（3）解决方法-3：使用WebSocket
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏都可以考虑使用websocket协议；正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
· 应用场景：
① TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。展开赞过 评论1 - #青训营笔记创作活动#
1月18日 打卡day6
总结该篇文章要点如下：
（一）插上网线后获得IP的方式：
1.手动为主机配置IP
2.DHCP
（二）DHCP的工作原理：
1.原理：向某个管IP分配的服务器申请IP地址
2.四阶段：
① DHCP Discover：联网时通过广播向本地网段内其他主机发出消息询问是否有空闲IP
② DHCP Offer：非DHCP服务器的机子忽略源主机的广播消息，而DHCP服务器收到消息后会在其维护的IP池里搜出空闲IP通过广播的形式发回源主机
③ DHCP Request：源主机拿到IP后再发起广播表示拥有该IP
④ DHCP ACK：DHCP服务器回复源主机ACK，代表源主机正式获得该IP在一段时间的使用权
（三）为什么DHCP用UDP？
TCP是面向连接而UDP是无连接
（四）为什么DHCP第二阶段不是广播而是单播？
优化手段。原则上2阶段都用广播最容易，目标机器收到后进入3阶段。非目标机器收到后解包后发现目的机器的mac地址跟自己的不同之后会丢掉这个包，过程很浪费机器性能，因此可以选择不同方式：
1.对于不能收单播包的系统，选择广播。因为此时目的机器无IP地址。
2.对于能收单播包的系统，会在发1阶段设 Broadcast flag = 0的标志位，告诉服务器支持单播回复，服务器就会在2阶段以单播形式进行回复。
（五）每次联网是否都要经历DHCP的四个阶段？
不需要。主机想联网就需要IP，若没有IP用DHCP协议去分配。但主机会记录曾经使用过的IP，在重新联网后会优先再次请求这个IP，可省下第一第二阶段的广播。
（六）DHCP分配下来的IP一定不会重复吗？
可能会重复。有两个常见的情况会出现IP重复：
1.手动配的IP有可能跟其他DHCP分配下来的IP是相同的。
解决方案：尽量不手动配IP而统一走DHCP。或者在DHCP服务器里维护的IP范围将这条IP剔除。
2.一个本地网段内可以有多个DHCP服务器，而他们维护的IP地址范围可能重叠，可能将相同的IP给不同机子。
解决方案：修改两台DHCP服务器的维护的IP地址范围让它们不重叠。
（七）得到DHCP ACK之后立马就能使用这个IP吗？
不能。在三次无偿ARP消息后确认没有冲突才会开始使用该IP地址进行通信。展开赞过 评论1 - #青训营笔记创作活动#
1月17日 打卡day5
根据文章作者总结与阅读文章标注重点，该篇文章的要点如下：
（1）MYSQL数据库索引——最左匹配原则
最左匹配原则：在联合索引中，如果 SQL 语句中用到了联合索引中的最左边的索引，那么这条 SQL 语句就可以利用这个联合索引去进行匹配。
（2）为什么左链接一定要遵循最左缀原则呢？
要想理解联合索引的最左匹配原则，首先需要理解索引的底层原理。
· 原理： 索引的底层是一颗B+树，联合索引的底层也是一颗B+树，只不过联合索引的B+树节点中存储的是键值。由于构建一棵B+树只能根据一个值来确定索引关系，所以数据库依赖联合索引最左的字段来构建；
· MySQL8.0版本开始增加了索引跳跃扫描的功能，当第一列索引的唯一值较少时，即使where条件没有第一列索引，查询的时候也可以用到联合索引；
· MySQL联合索引有时候遵循最左前缀匹配原则，有时候不遵循。
展开赞过 评论1 - #青训营笔记创作活动#
1月16日 打卡day4
根据文章作者总结与阅读文章标注重点，该篇文章的总结笔记如下：
1.作者认为客户端转服务端开发最大的挑战：编程思维的改变
客户端和服务端就有不同的编程思维、关注点；
客户端不需要关心数据是怎么来的，要求服务端返回自己需要的数据；
服务端不需要关心客户端如何管理应用的生命周期，只需要按照客户端要求返回数据。
2.高效学习一门新的编程语言的制胜法宝：“三刷”官方文档
①从头看到尾，扫清知识盲点，搞清楚概念；
②必须手敲，而且要写注释和总结；
③先只写注释，不看文档实现功能，遇到问题再和文档比较，加深理解。
3.开发GO的Web项目前提：掌握GO基础，通过“三刷”的方式掌握SQL、Redis、Linux、Nginx的基础知识点
4.开发GO的Web项目进阶：要学“微服务”和“DDD”
① 更好的从单体架构和集中式架构转型到分布式微服务架构的方法：DDD：
a.DDD的核心思想就是避免业务逻辑的复杂性和技术实现的复杂性耦合在一起；明确业务复杂性和技术复杂性的边界，隔离双方的复杂性，站在更高的角度实现解耦。
b.DDD最大的价值就是梳理业务需求，抽象出一个个“领域”，并形成各个领域之间的接口交互，方便团队协作，推进项目前进。
② 分布式微服务架构是主流趋势，越来越多的企业采用分布式微服务架构进行业务转型。
a. 单一职责：DDD思想指导我们对业务逻辑进行拆分，明确各自边界，形成不同的领域，不同的领域对应不同的微服务，这就是单一职责。
b. 团队独立：不同的领域对应不同的业务团队，也对应着不同的技术团队，彼此之间是解耦的。
c. 技术独立：不同的领域，不同的团队可以使用不同的开发语言，各自独立，只要按规范提供服务即可。
d. 数据库分离：每个领域（每个服务）都拥有自己的数据源。
e. 独立部署：每个领域（每个服务）都是独立的组件，可复用，可替换，降低耦合，易维护，易集群Docker部署服务
5.软件的架构模式经历了三个阶段的演进：单机->集中式->分布式微服务
第一阶段：单机架构，这个阶段通常采用面向过程的设计方法。
第二阶段：集中式架构，这个阶段通常采用面向对象的设计方法，一般采用经典的三层架构MVC。
第三阶段：分布式微服务架构，微服务架构可以实现业务和应用之间的解耦。展开赞过 评论1 - #青训营笔记创作活动#
1月15日 打卡day3
问题：MySQL每张表最好不要超过2000万条数据，否则就会导致性能下降。
单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
实际：每张表由于自身的字段不同、字段所占用的空间不同等，它们在最佳性能下可以存放的数据量也就不同。
· 如何计算出每张表适合的数据量？
已知条件如下：
1.字符编码不同情况下的每一页中的具体存储空间
2.非叶子节点计算：前两层非叶子节点计算、单个节点计算
3.数据条数计算：最少存放记录数、较多的存放记录数
根据原文的三种不同情况下的计算：
InnoDB三层B+树情况下的数据存储量范围为 一百二十多万条到将近5亿条，这个跨度还是非常大的，同时我们也计算了一张博客信息表，可以存储 约一千万条数据。
总结：做项目考虑分表时需要多关注表的实际情况，而不是盲目的认为两千万数据就是那个临界点。展开赞过 评论1 - #青训营笔记创作活动#
1月13日 打卡day2
了解了MacroZheng大佬推荐的常用IDEA插件。
（1）Key Promoter X
Key Promoter X 是一款帮助你快速学习IDEA快捷键的插件，当你在IDEA中用鼠标点击某些功能时，它会自动提示你使用该功能的快捷键。
（2）Lombok
Lombok目前已经是开发Java应用的标配了，不仅SpringBoot默认支持它，连IDEA也内置了Lombok插件，无需安装即可使用。
（3）MyBatisX
MybatisX是一款基于IDEA的快速开发插件，由MyBatis-Plus团队开发维护，提示很全功能也很强大。支持xml和Mapper接口之间的跳转，自带图形化的代码生成器，可以通过类似JPA的方式，直接根据方法名称生成SQL实现。
（4）RestfulFastRequest
RestfulFastRequest号称是IDEA版本的Postman，它是一个功能强大的Restful API工具包插件，可以根据已有的方法快速生成接口调试用例。
（5）PlantUML
PlantUML是一款开源的UML图绘制工具，支持通过文本来生成图形，使用起来非常高效。可以支持时序图、类图、对象图、活动图、思维导图等图形的绘制。
（6）SequenceDiagram
SequenceDiagram是一款能根据代码生成时序图的插件，还支持在时序图上直接导航到对应代码以及导出为图片或PlantUML文件。
（7）GsonFormatPlus
一款能根据JSON字符串自动生成实体类的插件，支持Lombok。
（8）Json Parser
一款简单小巧的JSON格式化插件，还在使用在线工具格式化JSON？试试这款IDEA插件吧！
（9）String Manipulation
一款专业处理字符串的插件，支持各种格式代码命名方式的切换、支持各种语言的转义和反转义、支持字符加密、支持多个字符的排序、对齐、过滤等。
（10）MapStruct support
MapStruct是一款基于Java注解的对象属性映射工具，使用的时候我们只要在接口中定义好对象属性映射规则，它就能自动生成映射实现类，不使用反射，性能优秀。展开赞过 评论1 - #青训营笔记创作活动#
1月12日 打卡day1
掌握学习了按照作用范围、限流方式划分限流各种类的特点和基本实现。
（1）限流：
限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求；
对于超过限制的流量通过拒绝服务的方式保证整体系统的可用性。
（2）限流的分类——限流作用范围划分：
· 单机版限流总结：
1.单机版限流仅能保护自身节点但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。
· 分布式限流总结：
1.分布式限流以集群为维度通过方便控制集群的请求限制来保护下游依赖的服务资源。
2.分布式限流最关键的是要将限流服务做成原子化
（2）限流的分类——限流作用范围划分：
· 计数器总结：
1.原理：在一段时间间隔内对请求进行计数，并且与阀值进行比较判断是否需要限流；若一旦到了时间临界点，将计数器清零。
2.特点：
① 特定情况下，使用该限流方式的系统可能会承受恶意用户的大量请求或使得系统被击穿
② 没有很好的处理单位时间的边界
· 滑动窗口总结：
1.原理：把固定时间片进行划分，并且随着时间的流逝进行移动，固定数量的可以移动的格子，进行计数并判断阀值。
2.特点：格子的数量影响着滑动窗口算法的精度，依然有时间片的概念，无法根本解决临界点问题。
· 漏桶限、令牌桶限流总结：
1.原理：
① 漏桶：通过设置一个固定容量的漏桶，按照固定速率流出水滴
② 令牌桶：是网络流量整形和速率限制中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送
2.特点：
① 漏桶：漏桶限制的是常量流出速率，所以最大的速率就是出水的速率，不能出现突发流量；漏桶具有固定容量，出水速率是固定常量（流出请求） ；如果桶是空的，则不需流出水滴； 可以以任意速率流入水滴到漏桶（流入请求） ；如果流入水滴超出了桶的容量，则流入的水滴溢出（新请求被拒绝）
② 限流桶：限制的是平均流入速率，允许突发请求，只要有令牌就可以处理，并允许一定程度突发流量；令牌按固定的速率被放入令牌桶中；桶中最多存放 B 个令牌，当桶满时，新添加的令牌被丢弃或拒绝；如果桶中的令牌不足 N 个，则不会删除令牌，且请求将被限流（丢弃或阻塞等待） 。展开赞过 评论1