用户2587076366160
获得徽章 1
- #青训营笔记创作活动#
2023年2月22日晚 打卡day28 今天主要学习的内容是关于接口IP访问限制的问题。 一般向外暴露的接口，都需要加上一个访问限制，以防止有人恶意刷流量或者爆破，访问限制的做法有很多种，从控制粒度上来看可以分为：全局访问限制和接口访问限制，本文讲的是接口访问的限制。写法是基于 AOP + 自定义注解 + Redis，并且封装在一个单独的模块 common-web 下，需要使用的模块只需引入该包，并且给需要限制的方法添加注解即可。 步骤： 获取注解参数 获取当前请求的ip和请求的方法 生成key 获取redis中该key的访问次数 判断次数是否超过范围 若超出范围，则拒绝访问，返回提示，并将TTL重置为注解上的等待时间 若没有超过范围，则允许访问，并将访问次数+1 若查询不到该key，则往redis中进行添加，将值设置为1，将TTL设置为注解上的值展开评论点赞 - #青训营笔记创作活动#
2023年2月17日晚 打卡day28 今天主要学习的内容是关于接口IP访问限制的问题。 一般向外暴露的接口，都需要加上一个访问限制，以防止有人恶意刷流量或者爆破，访问限制的做法有很多种，从控制粒度上来看可以分为：全局访问限制和接口访问限制，本文讲的是接口访问的限制。写法是基于 AOP + 自定义注解 + Redis，并且封装在一个单独的模块 common-web 下，需要使用的模块只需引入该包，并且给需要限制的方法添加注解即可。 步骤： 获取注解参数 获取当前请求的ip和请求的方法 生成key 获取redis中该key的访问次数 判断次数是否超过范围 若超出范围，则拒绝访问，返回提示，并将TTL重置为注解上的等待时间 若没有超过范围，则允许访问，并将访问次数+1 若查询不到该key，则往redis中进行添加，将值设置为1，将TTL设置为注解上的值展开评论点赞 - #青训营笔记创作活动#
2023年2月15日晚 打卡day27 今天主要学习的内容是关于分库分表的问题。 分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。 分库分表是由分库和分表这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。 单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。 一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行分库分表。展开评论点赞 - #青训营笔记创作活动#
2023年2月14日上午 打卡day26 今天主要学习的内容是关于缓存和数据库不一致性问题。 数据库和缓存的数据不一致问题，大都是产生在更新数据时。 在更新的时候，操作缓存和数据库无疑就是以下四种可能之一： 1、先更新缓存，再更新数据库 2、先更新数据库，再更新缓存 3、先删除缓存，再更新数据库 4、先更新数据库，再删除缓存 现有的解决方案中，可以使用 alibaba 的开源组件 Canal，订阅数据库变更日志，当数据库发生变更时，我们可以拿到具体操作的数据，然后再去根据具体的数据，去删除对应的缓存。 当然Canal 也是要配合消息队列一起来使用的，因为其Canal本身是没有数据处理能力的。展开评论点赞 - #青训营笔记创作活动#
2023年2月13日上午 打卡day25 今天主要学习的内容是关于缓存的内容。 开发人员在项目中使用了基于接口维度的短期缓存，对每个接口的请求参数（帖子ID）与响应内容缓存一定的时间（比如1分钟），对于相同的请求，如果匹配到缓存则直接返回缓存的结果即可，不用再次去执行查询数据库以及业务维度的运算逻辑。 集中式缓存有很多，最出名的莫过于很多人都耳熟能详的Redis，或者是在各种面试中常常被拿来与Redis进行比较的Memcached。也正是由于它们出色的自身性能表现，在当前的各种分布式系统中，Redis近乎已经成为了一种标配，常常与MySQL等持久化数据库搭配使用，放在数据库前面进行扛压。 缓存除了在系统性能提升或系统可靠性兜底等场景发挥价值外，在APP或者web类用户侧产品中，还经常被用于存储一些临时非永久的个性化使用习惯配置或者身份数据，以提升用户的个性化使用体验。展开评论点赞 - #青训营笔记创作活动#
2023年2月12日上午 打卡day24 今天主要学习的内容是关于高并发下秒杀商品的内容。 1 瞬时高并发：正常情况下，大部分用户会收到商品已经抢完的提醒，收到该提醒后，他们大概率不会在那个活动页面停留了，如此一来，用户并发量又会急剧下降。所以这个峰值持续的时间其实是非常短的，这样就会出现瞬时高并发的情况。 2. 页面静态化：就需要使用CDN，它的全称是Content Delivery Network，即内容分发网络。使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。 3 秒杀按钮：大部分用户怕错过秒杀时间点，一般会提前进入活动页面。此时看到的秒杀按钮是置灰，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。 4 读多写少：由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。这是非常典型的：读多写少 的场景。 5 缓存问题：用户在点击秒杀按钮，请求秒杀接口的过程中，需要传入的商品id参数，然后服务端需要校验该商品是否合法。 6 库存问题：如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。 7 分布式锁：如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。 8 mq异步处理：所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成mq异步处理的。展开评论点赞 - #青训营笔记创作活动#
2023年2月11日下午 打卡day23 今天主要学习的内容是关于https的加密的内容。 加密就是将一个已知的数字根据一定的规则转换变成另一个数字，以前这些数字放在一起都可读，但是经过这么一转换，就变得不可读了。 HTTPS到底是对称加密还是非对称机密？都用到了。前期4次握手，本质上就是在利用非对称加密的特点，交换三个随机数。目的就是为了最后用这三个随机数生成对称加密的"会话秘钥"。后期就一直用对称机密的方式进行通信。 总结 大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定情况下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。 HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。 TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。 TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。展开评论点赞 - #青训营笔记创作活动#
2023年2月10日晚上 打卡day22 今天主要学习的内容是关于Redis的内容。 Redis（Remote Dictionary Server）是一个开源的、键值对型的数据存储系统。使用C语言编写，遵守BSD协议，可基于内存也可持久化的日志型数据库，提供了多种语言的API，被广泛用于数据库、缓存和消息中间件。并且支持多种类型的数据结构，用于应对各种不同场景。可以存储多种不同类型值之间的映射，支持事务，持久化，LUA 脚本以及多种集群方案等。 优点： 完全基于内存操作，性能极高，读写速度快，Redis 能够支持超过 100KB/s 的读写速率 支持高并发，支持10万级别的并发读写 支持主从模式，支持读写分离与分布式 具有丰富的数据类型与丰富的特性（发布订阅模式） 支持持久化操作，不会丢失数据 缺点： 数据库容量受到物理内存的限制，不能实现海量数据的高性能读写 相比关系型数据库，不支持复杂逻辑查询，且存储结构相对简单 虽然提供持久化能力，但实际更多是一个 disk-backed 功能，与传统意义上的持久化有所区别展开评论点赞 - #青训营笔记创作活动#
2023年2月9日晚上 打卡day21 今天主要学习的内容是关于数据库索引的内容。 下面我们就一起来看看建立索引时，需要遵守的一些原则： ①经常频繁用作查询条件的字段应酌情考虑为其创建索引。 ②表的主外键或连表字段，必须建立索引，因为能很大程度提升连表查询的性能。 ③建立索引的字段，一般值的区分性要足够高，这样才能提高索引的检索效率。 ④建立索引的字段，值不应该过长，如果较长的字段要建立索引，可以选择前缀索引。 ⑤建立联合索引，应当遵循最左前缀原则，将多个字段之间按优先级顺序组合。 ⑥经常根据范围取值、排序、分组的字段应建立索引，因为索引有序，能加快排序时间。 ⑦对于唯一索引，如果确认不会利用该字段排序，那可以将结构改为Hash结构。 ⑧尽量使用联合索引代替单值索引，联合索引比多个单值索引查询效率要高。 同时，除开上述一些建立索引的原则外，在建立索引时还需有些注意点： ❶值经常会增删改的字段，不合适建立索引，因为每次改变后需维护索引结构。 ❷一个字段存在大量的重复值时，不适合建立索引，比如之前举例的性别字段。 ❸索引不能参与计算，因此经常带函数查询的字段，并不适合建立索引。 ❹一张表中的索引数量并不是越多越好，一般控制在3，最多不能超过5。 ❺建立联合索引时，一定要考虑优先级，查询频率最高的字段应当放首位。 ❻当表的数据较少，不应当建立索引，因为数据量不大时，维护索引反而开销更大。 ❼索引的字段值无序时，不推荐建立索引，因为会造成页分裂，尤其是主键索引。展开评论点赞 - #青训营笔记创作活动#
2023年2月8日上午 打卡day20 今天主要学习的内容是关于数据库索引的内容。 引入索引机制后，能够给数据库带来的优势很明显： ①整个数据库中，数据表的查询速度直线提升，数据量越大时效果越明显。 ②通过创建唯一索引，可以确保数据表中的数据唯一性，无需额外建立唯一约束。 ③在使用分组和排序时，同样可以显著减少SQL查询的分组和排序的时间。 ④连表查询时，基于主外键字段上建立索引，可以带来十分明显的性能提升。 ⑤索引默认是B+Tree有序结构，基于索引字段做范围查询时，效率会明显提高。 ⑥从MySQL整体架构而言，减少了查询SQL的执行时间，提高了数据库整体吞吐量。 同时也会带来一系列弊端，如： ①建立索引会生成本地磁盘文件，需要额外的空间存储索引数据，磁盘占用率会变高。 ②写入数据时，需要额外维护索引结构，增、删、改数据时，都需要额外操作索引。 ③写入数据时维护索引需要额外的时间开销，执行写SQL时效率会降低，性能会下降。展开评论点赞