唯手熟尔
获得徽章 1
- #青训营笔记创作活动#
1月30日 打卡day20
缓存的演化 从本地缓存到redis集中的分布式缓存到多级缓存结合起来
缓存使用场景 降低自身CPU消耗 减少对外IO交互 提升用户个性化体验(防止频繁登录)
业务与缓存的集成模式 旁路型缓存(自由决定未命中策略)、穿透型缓存与异步型缓存(只从缓存交互 ，异步执行操作mysql持久化)展开评论点赞 - #青训营笔记创作活动#
1月29日 打卡day19
都是redis的干货，其中我用到的很少，签到功能，了解了什么是脑裂问题，redis的两种持久化方式RDB&AOF，热点key问题，缓存击穿穿透雪崩问题，内存淘汰过期删除等，接触到的还是太少了，还需要多学习。展开评论点赞 - #青训营笔记创作活动#
1月28日 打卡day18
最近正好也再看redis的秒杀部分，总结一下解决并发的多个方式
1、页面静态化，减少前端再秒杀页面对服务端的请求降低并发
2、CDN加速 使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
3、秒杀按钮进行js限制，未到时间不许点，因为如果可以点的话那人们一点快到点就一直点，增加了不必要的请求
4、读多写少，我们可以将数据票量的多少等这些信息放入redis中直接判断，改用缓存就好了 将数据提前预热一下
5、缓存又要解决缓存击穿和缓存穿透问题
6、库存问题 对于有资格下单用户 我们生成订单id就可以返给客户端了 再开一个子线程去完成创建订单修改库存等操作，超卖采用乐观锁加一个库存>0的条件，保证原子性需要用到lua脚本配 保证原子性，
7、分布式锁，可以使用redis setnx但是存在不少问题 set加锁虽然可以加很多参数保证原子性 但是还有有问题
8、释放锁，释放锁的时候一定要判断删除的是自己的锁，可能存在锁超时释放然后删除了别人的锁，还要避免一个问题就是判断时候是自己的锁但是删除的时候过期了还是删除了别人的锁，可以使用lua脚本保证判断和删除是原子性 所以这种情况概率很低很低
9、自旋锁，当获取锁失败时候可以不用直接返回失败 可以进行等待一段时间后再进行尝试获取锁
10、MQ异步处理
消息丢失问题 使用加一张表，进行重试机制，有点像redis5.0更新的stream数据类型 有一个pending列表，是被消费的数据 需要ack确认才算真的消费成功 避免了消息丢失
延迟消费 对于有的场景存在15/30分钟未付款自动取消订单，直接使用延迟队列。我们都知道rocketmq，自带了延迟队列的功能
11、限流问题 1、可以使用nginx负载均衡限流 2、基于redis 也可以对同一个用户限流限制userid，ip限流，接口限流(但是不好，因为可能一个人去用软件请求导致达到的限制大部分都不能正常使用了)，加验证码也是限制最常用的 但是对于秒杀业务加验证码好像不是很好，有些麻烦 有的人验证慢好像也不公平了 最后一个提高业务门槛感觉这个不错哈哈，要求会员或者有消费过的用户等这样可以避免黄牛，也可以将秒杀周期变长 多增几个时间点。展开评论点赞 - #青训营笔记创作活动#
1月27日 打卡day17
维持的连接池一般mysql自己有一个维持线程复用，客户端有一个比如德鲁伊维持连接复用，执行一条sql语句需要经过sql接口，解析器，优化器，存储引擎，写操作与读操作主要是多了一个查看缓冲区是否有该表有的话会删除掉，因为现在写这个表的内容 缓存里的东西就是没有了一致性了，查询的返回是将结果陆续返回而非一下子都返回到sql接口，否则容易爆内存，然后最后都是通过mysql维护的那个连接的线程去通过tcp将结果返回给客户端展开评论点赞 - #青训营笔记创作活动#
1月23日 打卡day16
第一次了解到502，也通俗易懂的了解了一下nginx是干什么的，之前写项目时候遇到过，但是只知道启动就行了哈哈哈，下面是总结
HTTP状态码用来表示响应结果的状态，其中200是正常响应，4xx是客户端错误，5xx是服务端错误。
客户端和服务端之间加入nginx，可以起到反向代理和负载均衡的作用，客户端只管向nginx请求数据，并不关心这个请求具体由哪个服务器来处理。
后端服务端应用如果发生崩溃，nginx在访问服务端时会收到服务端返回的RST报文，然后给客户端返回502报错。502并不是服务端应用发出的，而是nginx发出的。因此发生502时，后端服务端很可能没有没有相关的502日志，需要在nginx侧才能看到这条502日志。
如果发现502，优先通过监控排查服务端应用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他原因导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将请求打到了某个不知名IP端口展开评论点赞 - #青训营笔记创作活动#
1月22日 打卡day15
确实很重要，注释，拆分目录结构，不在循环里远程调用、或者数据库操作，优先考虑批量进行。
封装方法形参，封装通用模板，封装复杂的逻辑判断条件，保持优化性能的嗅觉，可变参数的配置化处理
，会总结并使用工具，控制方法函数复杂度，在finally块中对资源进行释放，把日志打印好，考虑异常，处理好异常，考虑系统、接口的兼容性，代码采取措施避免运行时错误展开评论点赞 - #青训营笔记创作活动#
1月21日 打卡day14
主要说明了TCP/IP的四层网络模型 各司其职都做了什么 从http到物理层评论点赞 - #青训营笔记创作活动#
1月20日 打卡day13
mysql平常我们只用来crud 但是很少关注他的原理
mysql的架构主要是网络连接层、系统服务层、存储引擎层、以及文件系统层，
平常写的sql就是从左往右依次执行：
连接层：主要是指数据库连接池，会负责处理所有客户端接入的工作。
服务层：主要包含SQL接口、解析器、优化器以及缓存缓冲区四块区域。
存储引擎层：这里是指MySQL支持的各大存储引擎，如InnoDB、MyISAM等。
文件系统层：涵盖了所有的日志，以及数据、索引文件，位于系统硬盘上。展开评论点赞 - #青训营笔记创作活动#
1月19日 打卡day12
文章开头通过抓包baidu的数据包，展示了用wireshark抓包的简单操作流程。
HTTPS会对HTTP的URL和Request Body都进行加密，因此直接在filter栏进行过滤http.host == "baidu.com"会一无所获。
HTTPS握手的过程中会先通过非对称机密去交换各种信息，其中就包括3个随机数，再通过这三个随机数去生成对称机密的会话秘钥，后续使用这个会话秘钥去进行对称加密通信。如果能获得这三个随机数就能解密HTTPS的加密数据包。
三个随机数，分别是客户端随机数（client random），服务端随机数（server random）以及pre_master_key。前两个，是明文，第三个是被服务器公钥加密过的，在客户端侧需要通过SSLKEYLOGFILE去导出。
通过设置SSLKEYLOGFILE环境变量，再让curl或chrome会请求HTTPS域名，会让它们在调用TLS库的同时导出对应的sslkey文件。这个文件里包含了三列，其中最重要的是第二列的client random信息以及第三列的pre_master_key。第二列client random用于定位，第三列pre_master_key用于解密。展开评论点赞 - #青训营笔记创作活动#
1月14日 打卡day11
很全面总结 ，45个总结可以直接在打开的第一张图片就有，里面说的很多点我都是有在犯，平常注意不到，但是还是建议初学者先注重开发，后注重细节规范吧![[呲牙]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_2.cd1e2bd.png)
，一边开发一边留意就好了
评论点赞
![[呲牙]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_2.cd1e2bd.png)
，一边开发一边留意就好了