获得徽章 1
- #青训营笔记创作活动#
1月20号 打卡Day6
文章讲了IP是如何获取的，主要讲了DHCP。
四个阶段中，第二次进行连接只需第三第四个阶段。
讲的内容也解答平时对于手机联网猜想和疑问。评论点赞 - #青训营笔记创作活动#
1月18日 打卡Day5
学习了一些关于索引的比较细的知识，补充了一些之前看MySQL时没有关注或者印象不深的地方，包括最左前缀等等评论点赞 - #青训营笔记创作活动#
1月17日 打卡Day4
文章主要说的是InnoDB中高度为3的B+树最多可以存多少数据。所以分库分表的条件不应该是笼统的几千万条，应该按实际情况去计算，b＋树满三层就可以考虑分表了。评论点赞 - #青训营笔记创作活动#
1月16日 打卡Day3
看到了作者的"三刷"，发觉自己似乎在哪看过作者的这个说法，确实是很有用处的方法。文章主要是服务端开发思维的讲述，目前对我来说确实有点难理解，希望会逐渐明白！评论点赞 - #青训营笔记创作活动#
1月15日 打卡Day2
文章介绍了20个IDEA，一个一个看下来，功能很多很齐全。由于只前并没有使用IDEA，或许会试着使用一下，或者直接转到IDEA上。评论点赞 - #青训营笔记创作活动#
1月14日 打卡day1
文章讲述了各种限流方法：
1.计数法是很直接简单的方法，在一段时间间隔内对请求进行计数，超过阈值则进行限制，但方法也很粗糙，若在前一段计数时间的末尾，与后一段计数时间的开头进行临近阈值的请求，会被计数器认为可行，但实际上是超过了限制的，服务器可能会崩掉
2.滑动窗口是计数法改进，可以认为是计数的时间间隔不是分开的，是滑动的，会与上一段重叠一部分，文章已经很清楚了。由于同样是时间片，与计数器存在同样的安全问题。
3.漏桶算法，即限定一个容器大小，以一定速度输出流量，由于是固定速率输出，则不会出现突发流量问题，但文章没有讲到其缺陷，我认为缺陷在于它服务器的利用率，假设系统1分钟可处理的请求为6000，在一个暂时没有处理请求的系统中突然输入6000个请求，这是被允许处理的，但是它依然会按照每秒100次的速度输出，效率不高。
4.令牌法 具体可看文章解释，控制的是流入的速度，避免了漏桶的问题，没有想到有什么缺点与漏洞。被广泛使用。
除了以上单机限流，还有分布式限流，以集群为维度，可以方便的控制这个集群的请求限制，从而保护下游依赖的各种服务资源。如redis＋Lua分布式限流，文章没有讲更多的分布式限流方法。
展开评论点赞