获得徽章 1
- #青训营笔记创作活动#
2月2日 day8
瞬间高并发场景下的设计:
1、页面静态化,避免突发流量都直接访问服务器。只有点了秒杀按钮,才会访问服务端。
2、js文件控制秒杀按钮是否可用
3、秒杀场景下读多写少,加入redis缓存
4、缓存预热,将数据库数据事先加载到缓存
5、在高并发下,有大量的请求都去查一个缓存中不存在的商品,这些请求都会直接打到数据库。数据库由于承受不住压力,而直接挂掉。这就需要用redis分布式锁了展开评论点赞 - #青训营笔记创作活动#
2月1日 day7
学到了新的良好开发习惯:1、打印日志要打印入参和出参,异常时也要打印 2、不要在循环里数据库操作,优先考虑批量处理 3、要有优化意识,能并行处理的就并行处理 4、可变参数做配置化处理 5、资源流及时释放展开评论点赞 - #青训营笔记创作活动#
1月20日 day6
Redis限流:固定窗口计数(存在临界窗口问题:比如用户可以在【1.5-2】这段区间访问10次,【2-2.5】这段区间也访问10次,这样就变成了1min内其实可以访问20次!)、滑动窗口计数、漏桶算法(无法应对突发流量:不限制流入速率,限制了流出速率)、令牌桶算法展开评论点赞 - #第五届青训营阅读打卡#
1月19日 打卡day5
跨域三种情况:协议不同、端口不同、域名不同
跨域解决原理:在返回头中设置“Access-Control-Allow-Origin”参数即可解决跨域问题,此参数就是用来表示允许跨域访问的原始域名的,当设置为“*”时,表示允许所有站点跨域访问展开评论点赞 - #青训营笔记创作活动#
1月18日 打卡day4
Kafka是一种高吞吐量的 分布式 发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。Kafka体系引入三个术语:Producer(生产者),就是发送消息的一方;Consumer(消费者),就是接收数据的一方,消费者连接到Kafka接收消息进行相应的业务操作;Broker(服务器代理节点),大部分情况可以把broker看作Kafka服务器展开评论点赞 - #青训营笔记创作活动#
1月16日 打卡day3
在http协议,只有客户端主动向服务器发请求,没有服务器主动向客户端发数据,这就无法应对需要双向通信的场景。对此,http其实可以通过短轮询和长轮询的方式应对些对实时性要求不高的场景,但是还有更好的解决方案:websocket(跟socket没半毛钱关系)展开评论点赞 - #青训营笔记创作活动#
1月15日 打卡day2
为什么查询会遵循最左原则呢?创建索引前会先对数据排序,排序的标准就是最左的字段,在此基础上再对第二个字段排序。
由最左前缀法则还可知:建立索引不推荐使用经常改变的字段,这样会造成索引结构的经常变动,耗费性能。
当联合索引的第一个字段的唯一值比较少时,查询也可以用到联合索引展开评论点赞 - #青训营笔记创作活动#
1月13日 day1
数据量对性能的影响
InnoDB得存储结构时B+树,表的数据量对性能得影响(阿里开发手册建议500万行或2GB),不能只看数量,其本质是数据量过大时,使B+树超过三层,查询就需要进行4次磁盘io,从而使性能下降。
InnoDB节点的存储内容
每个节点(页)默认大小16kb,其中包括页格式、行格式的信息,每个页可以存多条数据。
溢出页(外部页)的存储:当使用 DYNAMIC 创建表时,InnoDB 会将较长的可变长度列(比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型)的值剥离出来,存储到一个溢出页上。优点:避免了大量数据填充B+树,导致列过长。展开评论点赞