YunShu
获得徽章 2
- #青训营笔记创作活动#
2月18日 打卡day12
跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。展开评论点赞 - #青训营笔记创作活动#
1月17日 打卡day11
分库分表要解决的是现存海量数据访问的性能瓶颈，对持续激增的数据量所做出的架构预见性。
是否分库分表的关键指标是数据量，我们以fire100.top这个网站的资源表 t_resource为例，系统在运行初始的时候，每天只有可怜的几十个资源上传，这时使用单库、单表的方式足以支持系统的存储，数据量小几乎没什么数据库性能瓶颈。
但某天开始一股神秘的流量进入，系统每日产生的资源数据量暴增至十万甚至上百万级别，这时资源表数据量到达千万级，查询响应变得缓慢，数据库的性能瓶颈逐渐显现。
以MySQL数据库为例，单表的数据量在达到亿条级别，通过加索引、SQL调优等传统优化策略，性能提升依旧微乎其微时，就可以考虑做分库分表了。
既然MySQL存储海量数据时会出现性能瓶颈，那么我们是不是可以考虑用其他方案替代它？比如高性能的非关系型数据库MongoDB？
可以，但要看存储的数据类型！
现在互联网上大部分公司的核心数据几乎是存储在关系型数据库（MySQL、Oracle等），因为它们有着NoSQL如法比拟的稳定性和可靠性，产品成熟生态系统完善，还有核心的事务功能特性，也是其他存储工具不具备的，而评论、点赞这些非核心数据还是可以考虑用MongoDB的。展开评论点赞 - #青训营笔记创作活动#
2月16日 打卡day10
实际使用场景中，对于一致性要求不是特别高、且并发量不是特别大的场景，可以选择基于数据库事务保证的先更新数据库再更新/删除缓存。而对于并发要求较高、且数据一致性要求较好的时候，推荐选择先更新数据库，再删除缓存，并结合删除重试 + 补偿逻辑 + 缓存过期TTL等综合手段展开评论点赞 - #青训营笔记创作活动#
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月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月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月14日 打卡day3
在TCP里，它内部会根据MSS的大小分段，这时候进入到IP层之后，每个包大小都不会超过MTU，因此IP层一般不会再进行分片。这时候发生丢包了，只需要重传每个MSS分段就够了。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
此时UDP比TCP更慢展开评论点赞