获得徽章 1
赞了这篇文章
赞了这篇文章
关注了标签 
青训营笔记
赞了这篇文章
#青训营笔记创作活动#
1月13日 Day5
服务器如何主动向客户端推送数据
1. 使用http轮询
常见应用：扫码登录，浏览器不断发送http轮询用户登录状态，这实际上是一种伪服务器推送，这种方式会占用一定的带宽，增加服务器压力，同时登录时也会有一定的延迟。
2. 长轮询
一般http请求会设置超时时间，规定时间内服务器未响应就会返回。在扫码登录场景中，如果将超时时间设置的很大比如30s，在这段时间内如果用户登录了就返回，如果没有就立马发送下一个请求。
这种方式虽然能解决扫码登录的场景，但本质上还是客户端主动获取数据。
WebSocket
1. 是什么
Http1.1是半双工，同时只能有一方发送数据，在游戏场景中，双方都需要同时发送大量数据，http就不适用了，于是一个全双工的WebSocket协议就被设计出来了。
2. 连接过程
http中带上特殊的header升级协议，服务器支持升级的话将转换为WebSocket协议通信。
3. 应用场景
适用于服务器和客户端频繁交互的场景，比如网页/小程序游戏，网页聊天室。
1月13日 Day5
服务器如何主动向客户端推送数据
1. 使用http轮询
常见应用：扫码登录，浏览器不断发送http轮询用户登录状态，这实际上是一种伪服务器推送，这种方式会占用一定的带宽，增加服务器压力，同时登录时也会有一定的延迟。
2. 长轮询
一般http请求会设置超时时间，规定时间内服务器未响应就会返回。在扫码登录场景中，如果将超时时间设置的很大比如30s，在这段时间内如果用户登录了就返回，如果没有就立马发送下一个请求。
这种方式虽然能解决扫码登录的场景，但本质上还是客户端主动获取数据。
WebSocket
1. 是什么
Http1.1是半双工，同时只能有一方发送数据，在游戏场景中，双方都需要同时发送大量数据，http就不适用了，于是一个全双工的WebSocket协议就被设计出来了。
2. 连接过程
http中带上特殊的header升级协议，服务器支持升级的话将转换为WebSocket协议通信。
3. 应用场景
适用于服务器和客户端频繁交互的场景，比如网页/小程序游戏，网页聊天室。
展开
评论
1
赞了这篇文章
#青训营笔记创作活动#
1月11日 Day4
1. 最左匹配原则并不一定遵循
MySQL8.0.13新增了索引跳跃扫描的功能
2. 为什么不推荐使用select *
a. 增加查询分析器解析成本
b. 增减字段容易与resultMap配置不一致
c. 无用字段增加网络传输消耗，尤其是text类型字段
d. 会增加回表查询消耗
3. where范围大可能导致索引失效
4. MySQL8.0增加了函数索引，可以根据函数计算后的值来建立索引
5. where a = 6 - 1会走索引，但是where a + 1 = 6不会走索引
6. 使用like通配符，左不走右走
7. in中的元素大于一定比例（30%？）索引会失效，优化器认为此时回表查询效率小于全表扫描
8. where a order by b，即使a、b列都有索引，优化器也会选择全表扫描
1月11日 Day4
1. 最左匹配原则并不一定遵循
MySQL8.0.13新增了索引跳跃扫描的功能
2. 为什么不推荐使用select *
a. 增加查询分析器解析成本
b. 增减字段容易与resultMap配置不一致
c. 无用字段增加网络传输消耗，尤其是text类型字段
d. 会增加回表查询消耗
3. where范围大可能导致索引失效
4. MySQL8.0增加了函数索引，可以根据函数计算后的值来建立索引
5. where a = 6 - 1会走索引，但是where a + 1 = 6不会走索引
6. 使用like通配符，左不走右走
7. in中的元素大于一定比例（30%？）索引会失效，优化器认为此时回表查询效率小于全表扫描
8. where a order by b，即使a、b列都有索引，优化器也会选择全表扫描
展开
评论
1
#青训营笔记创作活动#
1月4日 Day3
“三刷”高效学习一门编程语言：
1. 1刷从头看到尾，扫清知识盲点，搞清楚概念；
2. 2刷必须手敲，而且要写注释和总结；
3. 3刷先只写注释，不看文档实现功能，遇到问题再和文档比较，加深理解。如果还有余力，就整理成文章，分享出来帮助大家学习，回馈社区。
软件架构演进史：
1. 单机架构，这个阶段通常采用面向过程的设计方法。
2. 集中式架构，这个阶段通常采用面向对象的设计方法。
3. 分布式微服务架构，微服务架构可以实现业务和应用之间的解耦。
那么如何才能更好的从单体架构和集中式架构转型到分布式微服务架构呢？答案就是：DDD(Domain Driven Design)：领域驱动设计
1. 核心思想：
a. DDD的核心思想就是避免业务逻辑的复杂性和技术实现的复杂性耦合在一起。
b. 明确业务复杂性和技术复杂性的边界，隔离双方的复杂性，站在更高的角度实现解耦。
2. 最大价值：DDD最大的价值就是梳理业务需求，抽象出一个个“领域”，并形成各个领域之间的接口交互，方便团队协作，推进项目前进。
1月4日 Day3
“三刷”高效学习一门编程语言：
1. 1刷从头看到尾，扫清知识盲点，搞清楚概念；
2. 2刷必须手敲，而且要写注释和总结；
3. 3刷先只写注释，不看文档实现功能，遇到问题再和文档比较，加深理解。如果还有余力，就整理成文章，分享出来帮助大家学习，回馈社区。
软件架构演进史：
1. 单机架构，这个阶段通常采用面向过程的设计方法。
2. 集中式架构，这个阶段通常采用面向对象的设计方法。
3. 分布式微服务架构，微服务架构可以实现业务和应用之间的解耦。
那么如何才能更好的从单体架构和集中式架构转型到分布式微服务架构呢？答案就是：DDD(Domain Driven Design)：领域驱动设计
1. 核心思想：
a. DDD的核心思想就是避免业务逻辑的复杂性和技术实现的复杂性耦合在一起。
b. 明确业务复杂性和技术复杂性的边界，隔离双方的复杂性，站在更高的角度实现解耦。
2. 最大价值：DDD最大的价值就是梳理业务需求，抽象出一个个“领域”，并形成各个领域之间的接口交互，方便团队协作，推进项目前进。
展开
评论
1
赞了这篇文章
#青训营笔记创作活动#
1月2日 打卡day2
1. 计算每张表能存储的行数的基本理论：InnoDB中B+树的高度保持在三层以内
2. MySQL每页的大小默认是16KB，最大64KB，最小4KB
3. 每页需要存储页格式与行格式信息
4. 当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。
5. 当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个溢出页上，只在该列上保留一个 20 字节的指针指向溢出页。
6. 最大行长度略小于数据库页面的一半，之所以是略小于一半，是由于每个页面还留了点空间给页格式 的其他内容，所以我们可以认为每个页面最少能放两条数据。
7. 三层B+树的存储范围差异很大，从一百二十多万到近五亿，所以在考虑分表时需要根据实际情况。1. 计算每张表能存储的行数的基本理论：InnoDB中B+树的高度保持在三层以内
2. MySQL每页的大小默认是16KB，最大64KB，最小4KB
3. 每页需要存储页格式与行格式信息
4. 当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。
5. 当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个溢出页上，只在该列上保留一个 20 字节的指针指向溢出页。
6. 最大行长度略小于数据库页面的一半，之所以是略小于一半，是由于每个页面还留了点空间给页格式 的其他内容，所以我们可以认为每个页面最少能放两条数据。
7. 三层B+树的存储范围差异很大，从一百二十多万到近五亿，所以在考虑分表时需要根据实际情况。
1月2日 打卡day2
1. 计算每张表能存储的行数的基本理论：InnoDB中B+树的高度保持在三层以内
2. MySQL每页的大小默认是16KB，最大64KB，最小4KB
3. 每页需要存储页格式与行格式信息
4. 当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。
5. 当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个溢出页上，只在该列上保留一个 20 字节的指针指向溢出页。
6. 最大行长度略小于数据库页面的一半，之所以是略小于一半，是由于每个页面还留了点空间给页格式 的其他内容，所以我们可以认为每个页面最少能放两条数据。
7. 三层B+树的存储范围差异很大，从一百二十多万到近五亿，所以在考虑分表时需要根据实际情况。1. 计算每张表能存储的行数的基本理论：InnoDB中B+树的高度保持在三层以内
2. MySQL每页的大小默认是16KB，最大64KB，最小4KB
3. 每页需要存储页格式与行格式信息
4. 当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。
5. 当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个溢出页上，只在该列上保留一个 20 字节的指针指向溢出页。
6. 最大行长度略小于数据库页面的一半，之所以是略小于一半，是由于每个页面还留了点空间给页格式 的其他内容，所以我们可以认为每个页面最少能放两条数据。
7. 三层B+树的存储范围差异很大，从一百二十多万到近五亿，所以在考虑分表时需要根据实际情况。
展开
评论
1