YunShu
获得徽章 2
#青训营笔记创作活动#
2月18日 打卡day12
跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。
2月18日 打卡day12
跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。
展开
评论
点赞
#青训营笔记创作活动#
1月17日 打卡day11
分库分表要解决的是现存海量数据访问的性能瓶颈，对持续激增的数据量所做出的架构预见性。
是否分库分表的关键指标是数据量，我们以fire100.top这个网站的资源表 t_resource为例，系统在运行初始的时候，每天只有可怜的几十个资源上传，这时使用单库、单表的方式足以支持系统的存储，数据量小几乎没什么数据库性能瓶颈。
但某天开始一股神秘的流量进入，系统每日产生的资源数据量暴增至十万甚至上百万级别，这时资源表数据量到达千万级，查询响应变得缓慢，数据库的性能瓶颈逐渐显现。
以MySQL数据库为例，单表的数据量在达到亿条级别，通过加索引、SQL调优等传统优化策略，性能提升依旧微乎其微时，就可以考虑做分库分表了。
既然MySQL存储海量数据时会出现性能瓶颈，那么我们是不是可以考虑用其他方案替代它？比如高性能的非关系型数据库MongoDB？
可以，但要看存储的数据类型！
现在互联网上大部分公司的核心数据几乎是存储在关系型数据库（MySQL、Oracle等），因为它们有着NoSQL如法比拟的稳定性和可靠性，产品成熟生态系统完善，还有核心的事务功能特性，也是其他存储工具不具备的，而评论、点赞这些非核心数据还是可以考虑用MongoDB的。
1月17日 打卡day11
分库分表要解决的是现存海量数据访问的性能瓶颈，对持续激增的数据量所做出的架构预见性。
是否分库分表的关键指标是数据量，我们以fire100.top这个网站的资源表 t_resource为例，系统在运行初始的时候，每天只有可怜的几十个资源上传，这时使用单库、单表的方式足以支持系统的存储，数据量小几乎没什么数据库性能瓶颈。
但某天开始一股神秘的流量进入，系统每日产生的资源数据量暴增至十万甚至上百万级别，这时资源表数据量到达千万级，查询响应变得缓慢，数据库的性能瓶颈逐渐显现。
以MySQL数据库为例，单表的数据量在达到亿条级别，通过加索引、SQL调优等传统优化策略，性能提升依旧微乎其微时，就可以考虑做分库分表了。
既然MySQL存储海量数据时会出现性能瓶颈，那么我们是不是可以考虑用其他方案替代它？比如高性能的非关系型数据库MongoDB？
可以，但要看存储的数据类型！
现在互联网上大部分公司的核心数据几乎是存储在关系型数据库（MySQL、Oracle等），因为它们有着NoSQL如法比拟的稳定性和可靠性，产品成熟生态系统完善，还有核心的事务功能特性，也是其他存储工具不具备的，而评论、点赞这些非核心数据还是可以考虑用MongoDB的。
展开
评论
点赞
#青训营笔记创作活动#
2月16日 打卡day10
实际使用场景中，对于一致性要求不是特别高、且并发量不是特别大的场景，可以选择基于数据库事务保证的先更新数据库再更新/删除缓存。而对于并发要求较高、且数据一致性要求较好的时候，推荐选择先更新数据库，再删除缓存，并结合删除重试 + 补偿逻辑 + 缓存过期TTL等综合手段
2月16日 打卡day10
实际使用场景中，对于一致性要求不是特别高、且并发量不是特别大的场景，可以选择基于数据库事务保证的先更新数据库再更新/删除缓存。而对于并发要求较高、且数据一致性要求较好的时候，推荐选择先更新数据库，再删除缓存，并结合删除重试 + 补偿逻辑 + 缓存过期TTL等综合手段
展开
评论
点赞
#青训营笔记创作活动#
2月14日 打卡day9
优秀的后端开发，应当考虑到异常，并做好异常处理。
- 尽量不要使用e.printStackTrace(),而是使用log打印。因为e.printStackTrace()语句可能会导致内存占满。
- catch住异常时，建议打印出具体的exception，利于更好定位问题
- 不要用一个Exception捕捉所有可能的异常
- 记得使用finally关闭流资源或者直接使用try-with-resource。
- 捕获异常与抛出异常必须是完全匹配，或者捕获异常是抛异常的父类
- 捕获到的异常，不能忽略它，至少打点日志吧
- 注意异常对你的代码层次结构的侵染
- 自定义封装异常，不要丢弃原始异常的信息Throwable cause
- 运行时异常RuntimeException ，不应该通过catch的方式来处理，而是先预检查，比如：NullPointerException处理
- 注意异常匹配的顺序，优先捕获具体的异常
2月14日 打卡day9
优秀的后端开发，应当考虑到异常，并做好异常处理。
- 尽量不要使用e.printStackTrace(),而是使用log打印。因为e.printStackTrace()语句可能会导致内存占满。
- catch住异常时，建议打印出具体的exception，利于更好定位问题
- 不要用一个Exception捕捉所有可能的异常
- 记得使用finally关闭流资源或者直接使用try-with-resource。
- 捕获异常与抛出异常必须是完全匹配，或者捕获异常是抛异常的父类
- 捕获到的异常，不能忽略它，至少打点日志吧
- 注意异常对你的代码层次结构的侵染
- 自定义封装异常，不要丢弃原始异常的信息Throwable cause
- 运行时异常RuntimeException ，不应该通过catch的方式来处理，而是先预检查，比如：NullPointerException处理
- 注意异常匹配的顺序，优先捕获具体的异常
展开
评论
点赞
#青训营笔记创作活动#
1月20日 打卡day8
个人区域网（PAN）
个人区域网PAN（Personal Area Network），顾名思义可以是个人使用区域范围内的电脑等设备，用无线连接起来的网络。所以范围相对很小。
局域网（LAN）
局域网LAN（Local Area Network），在地理上局限的范围，如1km左右。但可以将多个互连的局域网，来覆盖校园或者企业中。所以局域网也被称为校园网或企业网。
城域网（MAN）
城域网MAN（Metropolitan Area Network），城域网的作用范围可跨越几个街区甚至整个城市，距离约也可以为5到50km，所以一般也是一个城市。
广域网（WAN）
广域网WAN（Wide Area Network）范围通常为几十到几千公里，可以通过长距离运送主机所发送的数据，所以可以跨越不同国家，也是互联网的核心部分。
互联网
当你蓦然回首，把许多计算机连接在一起形成了计算机网络，而把许多网络连接在一起就构成了互联网；一个覆盖范围更大的计算机网络，覆盖范围可以是全球。
1月20日 打卡day8
个人区域网（PAN）
个人区域网PAN（Personal Area Network），顾名思义可以是个人使用区域范围内的电脑等设备，用无线连接起来的网络。所以范围相对很小。
局域网（LAN）
局域网LAN（Local Area Network），在地理上局限的范围，如1km左右。但可以将多个互连的局域网，来覆盖校园或者企业中。所以局域网也被称为校园网或企业网。
城域网（MAN）
城域网MAN（Metropolitan Area Network），城域网的作用范围可跨越几个街区甚至整个城市，距离约也可以为5到50km，所以一般也是一个城市。
广域网（WAN）
广域网WAN（Wide Area Network）范围通常为几十到几千公里，可以通过长距离运送主机所发送的数据，所以可以跨越不同国家，也是互联网的核心部分。
互联网
当你蓦然回首，把许多计算机连接在一起形成了计算机网络，而把许多网络连接在一起就构成了互联网；一个覆盖范围更大的计算机网络，覆盖范围可以是全球。
展开
评论
点赞
#青训营笔记创作活动#
1月18日 打卡day7
大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。
1月18日 打卡day7
大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。
展开
评论
点赞
#青训营笔记创作活动#
1月17日 打卡day6
HTTP状态码用来表示响应结果的状态，其中200是正常响应，4xx是客户端错误，5xx是服务端错误。
客户端和服务端之间加入nginx，可以起到反向代理和负载均衡的作用，客户端只管向nginx请求数据，并不关心这个请求具体由哪个服务器来处理。
后端服务端应用如果发生崩溃，nginx在访问服务端时会收到服务端返回的RST报文，然后给客户端返回502报错。502并不是服务端应用发出的，而是nginx发出的。因此发生502时，后端服务端很可能没有没有相关的502日志，需要在nginx侧才能看到这条502日志。
如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。
1月17日 打卡day6
HTTP状态码用来表示响应结果的状态，其中200是正常响应，4xx是客户端错误，5xx是服务端错误。
客户端和服务端之间加入nginx，可以起到反向代理和负载均衡的作用，客户端只管向nginx请求数据，并不关心这个请求具体由哪个服务器来处理。
后端服务端应用如果发生崩溃，nginx在访问服务端时会收到服务端返回的RST报文，然后给客户端返回502报错。502并不是服务端应用发出的，而是nginx发出的。因此发生502时，后端服务端很可能没有没有相关的502日志，需要在nginx侧才能看到这条502日志。
如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口上。
展开
评论
点赞
#青训营笔记创作活动#
1月16日 打卡day5
1.注释尽可能全面,写有意义的方法注释
2.项目拆分合理的目录结构
3. 不在循环里远程调用、或者数据库操作，优先考虑批量进行
4. 封装方法形参，如果你的方法参数过多，要封装一个对象出来
5. 封装通用模板
6. 封装复杂的逻辑判断条件
7. 保持优化性能的嗅觉
8. 可变参数的配置化处理
9. 会总结并使用工具类
10. 控制方法函数复杂度
11. 在finally块中对资源进行释放
12.把日志打印好
13. 考虑异常，处理好异常
14. 考虑系统、接口的兼容性
15. 代码采取措施避免运行时错误
1月16日 打卡day5
1.注释尽可能全面,写有意义的方法注释
2.项目拆分合理的目录结构
3. 不在循环里远程调用、或者数据库操作，优先考虑批量进行
4. 封装方法形参，如果你的方法参数过多，要封装一个对象出来
5. 封装通用模板
6. 封装复杂的逻辑判断条件
7. 保持优化性能的嗅觉
8. 可变参数的配置化处理
9. 会总结并使用工具类
10. 控制方法函数复杂度
11. 在finally块中对资源进行释放
12.把日志打印好
13. 考虑异常，处理好异常
14. 考虑系统、接口的兼容性
15. 代码采取措施避免运行时错误
展开
评论
点赞
#青训营笔记创作活动#
1月15日 打卡day4
TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。
websocket和socket几乎没有任何关系，只是叫法相似。
正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
1月15日 打卡day4
TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。
websocket和socket几乎没有任何关系，只是叫法相似。
正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
展开
评论
点赞
#青训营笔记创作活动#
1月14日 打卡day3
在TCP里，它内部会根据MSS的大小分段，这时候进入到IP层之后，每个包大小都不会超过MTU，因此IP层一般不会再进行分片。这时候发生丢包了，只需要重传每个MSS分段就够了。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
此时UDP比TCP更慢
1月14日 打卡day3
在TCP里，它内部会根据MSS的大小分段，这时候进入到IP层之后，每个包大小都不会超过MTU，因此IP层一般不会再进行分片。这时候发生丢包了，只需要重传每个MSS分段就够了。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
此时UDP比TCP更慢
展开
评论
点赞
#青训营笔记创作活动#
1月13日 打卡day2
Key Promoter X
帮助学习IDEA快捷键
RestfulFastRequest
IDEA中的postman
PlantUML
绘制流程图
SequenceDiagram
绘制时序图
GsonFormatPlus
JSON生成实体
Translation
翻译插件
Statistic
代码统计
1月13日 打卡day2
Key Promoter X
帮助学习IDEA快捷键
RestfulFastRequest
IDEA中的postman
PlantUML
绘制流程图
SequenceDiagram
绘制时序图
GsonFormatPlus
JSON生成实体
Translation
翻译插件
Statistic
代码统计
展开
评论
点赞
#青训营笔记创作活动#
1月12日 打卡day1
计数器：
优点：固定时间段计数，实现简单，适用不太精准的场景；
缺点：对边界没有很好处理，导致限流不能精准控制。
滑动窗口：
优点：将固定时间段分块，时间比“计数器”复杂，适用于稍微精准的场景；
缺点：实现稍微复杂，还是不能彻底解决“计数器”存在的边界问题。
漏桶：
优点：可以很好的控制消费频率；
缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
令牌桶：
优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
缺点：实现稍微复杂，其它缺点没有想到。
Redis + Lua 分布式限流：
优点：支持分布式限流，有效保护下游依赖的服务资源；
缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。
1月12日 打卡day1
计数器：
优点：固定时间段计数，实现简单，适用不太精准的场景；
缺点：对边界没有很好处理，导致限流不能精准控制。
滑动窗口：
优点：将固定时间段分块，时间比“计数器”复杂，适用于稍微精准的场景；
缺点：实现稍微复杂，还是不能彻底解决“计数器”存在的边界问题。
漏桶：
优点：可以很好的控制消费频率；
缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
令牌桶：
优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
缺点：实现稍微复杂，其它缺点没有想到。
Redis + Lua 分布式限流：
优点：支持分布式限流，有效保护下游依赖的服务资源；
缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。
展开
评论
点赞
关注了标签 
Linux
Linux
关注了标签 
Android
Android
关注了标签 
Java
Java