yeyr2
获得徽章 1
- #青训营笔记创作活动#
2月17日 day13
今天再次学习了redis,redis 是一款优秀的缓存中间件,在企业级架构中占有重要的地位.
学习了redis的优缺点,数据类型,内存优化,分布式锁,缓存,哨兵,事务的实现等等went展开评论点赞 - #青训营笔记创作活动#
2月16日 day12
1.在InnoDB中，如果一条SQL语句能命中索引执行，那就会加行锁，但如果无法命中索引加的就是表锁。
2.死锁解决方案：
2.1 锁超时机制：事务/线程在等待锁时，超出一定时间后自动放弃等待并返回。
2.2 外力介入打破僵局：第三者介入，将死锁情况中的某个事务/线程强制结束，让其他事务继续执行。
3.死锁检测算法 - wait-for graph :
3.1 锁的信息链表：目前持有每个锁的事务是谁。
3.2 事务等待链表：阻塞的事务要等待的锁是谁。
3.3 通过innodb_deadlock_detect=on|off这个参数，来控制是否开启死锁检测机制
3.4 该算法通过查找是否闭环判断是否死锁
4.在业务允许的情况下，尽量缩短一个事务持有锁的时间、减小锁的粒度以及锁的数量。检查sql逻辑.
5. 锁的底层实现展开评论点赞 - #青训营笔记创作活动#
2月15日 day11
对应这种瞬时高并发的场景，可以使用：
页面静态化：对活动页面做静态化处理，只有点击按钮才会访问服务器
CDN加速：使用cdn使全国各地的用户就近获取所需内容，降低网络拥堵，提高用户访问响应速度和命中率
按钮：使用js文件控制秒杀按钮，只在秒杀时间点时才点亮，一般为了性能考虑，将css、js和图片等静态资源文件提前缓存到CDN上
缓存：使用缓存redis，部署多个节点，而不是直接连接mysql数据库，使用分布式锁和布隆过滤器
mq异步处理：将秒杀和下单分开，因为只有秒杀并发量大，使用秒杀给mq服务器发送mq消息
限流：基于nginx限流
基于redis限流
对同一用户限流，对同一ip限流，加验证码等方法
分布式锁展开评论点赞 - #青训营笔记创作活动#
2月14日 day10
这是Hertz框架的中间件，它使用 jwt-go 来提供 jwt 身份验证中间件。
学习了Hertz-JWT的使用，实现了一个用户登录得到demo来测试hertz-jwt。展开评论点赞 - #青训营笔记创作活动#
2月13日 day9
1.在 Hertz 中使用反向代理需要拉取社区提供的 reverseproxy 拓展。
2.拓展不只是能够实现简单的反向代理，在 reverseproxy 拓展中提供了许多可以自定义的可选项。
3.方法:
通过 NewSingleHostReverseProxy 函数设置反向代理的目标路径 /proxy 。接下来注册路由的路径为反向代理目标路径的子路径 /proxy/backend ，最后通过注册 /backend 映射反向代理服务 proxy.ServeHTTP 。这样我们通过 GET 方法访问 /backend 时就会访问到 /proxy/backend 中的内容。展开评论点赞 - #青训营笔记创作活动#
2月7日 打卡day8
1.注释尽可能全面,写有意义的方法注释
2.项目拆分合理的目录结构,根据不同的业务进行划分
3. 不在循环里远程调用、或者数据库操作，优先考虑批量进行。
4. 封装方法形参
5. 具备封装通用模板的编码能力
6.避免创建比必要的对象、异步处理、使用缓冲流，减少IO操作等
8. 可变参数的配置化处理
9. 会总结并使用工具类
10. 控制方法函数复杂度
...展开评论点赞 - #青训营笔记创作活动#
1月31日 打卡day7
1. TCP是基于字节流的,要确定连接对象,对象是否会收到消息;UDP是基于数据报,且不管是否对象是否会收到消息.所以一般情况UDP会比TCP快,因为它干的少.
2. TCP会确认对方是否收到,有多种机制:
2.1 重传机制 : 它会给发出的消息打上一个编号（sequence），接收方收到后回一个确认(ack)。如果长时间没有ack,就会重新发送一次.
2.2 流量控制机制 : 因为重传很影响性能,所以TCP想了其他办法,数据发送方和接收方处理数据能力可能不同，因此如果可以根据双方的能力去调整发送的数据量,控制发送信息和接受信息的多少,即发送和接收窗口.
2.3 滑动窗口机制 : 动态的去调节这个接收窗口的大小,通过滑动窗口实现流量控制.
2.4 拥塞控制机制 : 防止因为网络环境产生丢包,TCP会从小到大发送数据,慢慢增加,直到出现丢包.
流量控制针对的是单个连接数据处理能力的控制，拥塞控制针对的是整个网络环境数据处理能力的控制
2.5 分段机制 : 降低重传带来的影响,将大数据包分成一段段小数据包.
这个所谓的一小段的长度，在传输层叫MSS,在应用层大数据包分成小数据包到传输层,而在网络层，如果数据包还大于MTU,那还会继续分包。
一般情况下，MSS=MTU-40Byte(20byte的tcp头部和20byte的ip头部)，所以TCP分段后，到了IP层大概率就不会再分片了。
2.6 乱序重排机制 : 依靠数据包的sequence，接收方就能知道数据包的先后顺序,并排序.
2.7 连接机制 : 为了实现上面的机制,需要一个个数据结构,而数据结构需要操作系统内核在两端代码里维护一套复杂的状态机(三次握手，四次挥手，RST，closing等异常处理机)，这套状态机其实就是所谓的"连接"。
3. 在丢包需要重传时,TCP的分段机制就保证它比UDP快了,但使用UDP通常也会在应用层上做一些重传机制,也可能实现分段机制.展开评论点赞 - #青训营笔记创作活动#
1月29日 day6
在HTTPS协议下的baidu.com,HTTP协议里的Host和实际发送的request body都会被加密。
HTTPS握手中的Client Hello阶段，里面有个扩展server_name，会记录你想访问的是哪个网站
通过tls.handshake.extensions_server_name == "baidu.com"筛选,选中其中一个包，点击右键，选中Follow-TCP Stream,这个TCP连接的其他相关报文全都能被展示出来,就可以看到加密后的信息了.展开评论点赞 - #青训营笔记创作活动#
1月28日 day5
以一种规则进行加密方法，其实就是所谓的秘钥。而这种加密和解密用的都是同一个秘钥的加密形式，就叫对称加密。
非对称加密，加密和解密用到的不是同一个秘钥，而是两个不一样的秘钥，分别是公钥和私钥。
公钥负责加密，私钥负责解密。公钥人人可得，私钥永远不泄露。
例如,取模,通常是不可逆的,但是结合欧拉定理却可以达到可逆的效果,经过适当的效果就能达到密文解密为原文,原文加密为密文的效果,且加密和解密方法不同,也就是公钥和私钥了.
例如:
原文^(p) mod N = 密文
密文^(q) mod N = 原文
用公钥加密过的密文只有用私钥才能解密。
HTTPS的加密,http消息收发为原文,为了安全,我们需要在HTTP层之上再加一层TLS层，做个加密,就是https了,
HTTPS握手过程:
1. 第一阶段是TLS四次握手，这一阶段主要是利用非对称加密的特性各种交换信息，最后得到一个"会话秘钥"。
握手阶段:
客户端告诉服务器用什么协议
-> 服务器告诉客户端,服务器随机数 + 服务器证书 + 确定的加密协议版本
-> 客户端再生成一个随机数,用公钥加密发送给服务器,客户端随机数，服务器随机数和pre_master_key，用这三个随机数进行计算得到一个"会话秘钥"。此时客户端通知服务端，后面会用这个会话秘钥进行对称机密通信,客户端会把迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给服务器做校验，此时客户端这边的握手流程就结束了，因此也叫Finished报文。
-> 服务端集齐三个随机数，跟客户端一样，用这三个随机数通过同样的算法获得一个"会话秘钥",将迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给客户端做校验，到这里，服务端的握手流程也结束了，因此这也叫Finished报文。
2. 第二阶段是则是在第一阶段的"会话秘钥"基础上，进行对称加密通信。
即https先用非对称加密得到对称加密密钥,然后用对称加密密钥进行通讯,因为对称加密相对来说快一些。
服务器证书，本质上是，被CA的私钥加密过的服务器公钥。
第三和第四次握手都有个 Finished报文，里面是个摘要,是为了进行hash操作。目的是为了确认通信过程中数据没被篡改过。展开评论点赞 - #青训营笔记创作活动#
1月23日 day4
学习多线程如何使用map
1.直接在多个线程使用map会报错fatal
2.使用sync.Mutex互斥锁，但会极大限制性能
3.使用sync.RWMutex读写锁，可以并发读，但是写的时候不能进行其他读或者写。
gin 框架里面就使用了 sync.RWMutex 来保证 Keys 读写操作的并发安全。
4.使用sync.Map使用原子操作替代读锁，
sync.Map 里面相比 sync.RWMutex，性能更好的原因就是使用了原子操作，并且实现类似读写分离的操作。 在我们从 sync.Map 里面读取数据的时候，会先使用一个原子 Load 操作来读取 sync.Map 里面的 key（从 read 中读取）。这里拿到的是 key 的一份快照，我们对其进行读操作的时候也可以同时往 sync.Map 中写入新的 key。
5.sync.Map是类似于map[any]any，可以存储任何类型。展开评论点赞