yiyiCat
ICPC区域赛银牌
获得徽章 1
- #青训营笔记创作活动#
1月20日 打卡day8
今日学习
Kafka 的一些基本知识，包含 Topic、Partition、消费者、生产者、副本等基本概念，同时也学习了 Kafka 的版本变迁以及应用实战所必备的知识点，加深对 Kafka 的理解。展开评论点赞 - #青训营笔记创作活动#
1月19日 打卡day7
今日学习
怎么样才能在用户不做任何操作的情况下，网页能收到消息并发生变
更。
最常见的解决方案是，网页的前端代码里不断定时发HTTP请求到服务器，服务器收到请求后给客户端响应消息。
长轮询
如果我们的HTTP请求将超时设置的很大，比如30s，在这30s内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。
websocket
websocket和HTTP一样都是基于TCP的协议。经历了三次TCP握手之后，利用HTTP协议升级为websocket协议。
websocket完美继承了TCP协议的全双工能力，并且还贴心的提供了解决粘包的方案。它适用于需要服务器和客户端（浏览器）频繁交互的大部分场景。比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。展开评论点赞 - #青训营笔记创作活动#
1月18日 打卡day6
插上网线之后，获得IP的方式主要有两种。
第一种是，自己手动在电脑里配。像下图那样，是macOS的一个截图，在选择手动配置之后，除了IP地址还需要配上子网掩码和路由器的地址。
第二种获取IP的方式，DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）。通过DHCP，在联网之后可以自动获取到本机需要的IP地址，子网掩码还有路由器地址。
因此本地网段内IP必须唯一。展开评论点赞 - #青训营笔记创作活动#
1月17日 打卡day5
最左匹配原则顾名思义：最左优先，以最左边的为起点任何连续的
索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配。
不带范围查询 索引使用类型 ref
带范围使用类型 range
不推荐使用select *
解释
增加查询分析器解析成本。
增减字段容易与 resultMap 配置不一致。
无用字段增加网络 消耗，尤其是 text 类型的字段。
在阿里的开发手册中，大面的概括了上面几点。
使用函数
使用在Select 后面使用函数可以使用索引 但是下面这种做法就不能
因为索引保存的是索引字段的原始值，而不是经过函数计算后的值，自然就没办法走索引了。
计算操作
这个情况和上面一样 之所以会导致索引失效是因为改变了索引原来的值 在树中找不到对应的数据只能全表扫描
因为索引保存的是索引字段的原始值，而不是 b - 1 表达式计算后的值，所以无法走索引，只能通过把索引字段的取值都取出来，然后依次进行表达式的计算来进行条件判断，因此采用的就是全表扫描的方式。
Like %
%百分号通配符: 表示任何字符出现任意次数(可以是0次).
_下划线通配符: 表示只能匹配单个字符,不能多也不能少,就是一个字符.
like操作符: LIKE作用是指示mysql后面的搜索模式是利用通配符而不是直接相等匹配进行比较.
注意: 如果在使用like操作符时,后面的没有使用通用匹配符效果是和=一致的,
在左不走 在右走
使用Or导致索引失效
在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效 举个例子，比如下面的查询语句，b 是主键，e 是普通列，从执行计划的结果看，是走了全表扫描。
in使用不当
首先使用In 不是一定会造成全表扫描的 IN肯定会走索引，但是当IN的取值范围较大时会导致索引失效，走全表扫描
in 在结果集 大于30%的时候索引失效
not in 和 In的失效场景相同
order By
这一个主要是Mysql 自身优化的问题展开评论点赞 - #青训营笔记创作活动#
1月16日 打卡day4
客户端转服务端，最大的挑战不是学一门新语言，而是编程思维的改变；
“三刷”官方文档是我高效学习一门新的编程语言的制胜法宝：
1刷从头看到尾，扫清知识盲点，搞清楚概念；
2刷必须手敲，而且要写注释和总结；
3刷先只写注释，不看文档实现功能，遇到问题再和文档比较，加深理解。如果还有余力，就和我一样整理成文章，分享出来帮助大家学习，回馈社区。 在掌握Go基础之后，也可以通过“三刷”的方式掌握SQL,Redis,Linux，Nginx的基础知识点，这样就有能力开发Web项目了。展开评论点赞 - #青训营笔记创作活动#
1月15日 打卡day3
三层B+树可以存放的最大数据量就是 约一千万条数据。
InnoDB三层B+树情况下的数据存储量范围为 一百二十多万条 到 将近5亿条，这个跨度还是非常大的
我们在做项目考虑分表的时候还是得多关注一下表的实际情况，而不是盲目的认为两千万数据就是那个临界点。展开评论点赞 - #青训营笔记创作活动#
1月14日 打卡day2
今天了解了20款IDEA插件，涵盖了大部分应用场景，平时开发的时候基本上也够用了。不过IDEA插件虽然能增强它的功能，给我们提供一站式的开发体验，但是也不要安装过多，太多了容易卡！展开评论点赞 - #青训营笔记创作活动#
1月13日 打卡day1
今日学习：
计数器：
优点：固定时间段计数，实现简单，适用不太精准的场景；
缺点：对边界没有很好处理，导致限流不能精准控制。
滑动窗口：
优点：将固定时间段分块，时间比“计数器”复杂，适用于稍微精准的场景；
缺点：实现稍微复杂，还是不能彻底解决“计数器”存在的边界问题。
漏桶：
优点：可以很好的控制消费频率；
缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
令牌桶：
优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
缺点：实现稍微复杂，其它缺点没有想到。
Redis + Lua 分布式限流：
优点：支持分布式限流，有效保护下游依赖的服务资源；
缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。
综上所述，我们用令牌桶算法![[调皮]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_13.aaa8265.png)
展开评论点赞
![[调皮]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_13.aaa8265.png)