用户2587076366160
获得徽章 1
关注了标签 
Rust
Rust
赞了这篇文章
赞了这篇文章
赞了这篇文章
赞了这篇文章
赞了这篇文章
赞了这篇文章
赞了这篇文章
赞了这篇文章
#青训营笔记创作活动#
2023年2月22日晚 打卡day28 今天主要学习的内容是关于接口IP访问限制的问题。 一般向外暴露的接口，都需要加上一个访问限制，以防止有人恶意刷流量或者爆破，访问限制的做法有很多种，从控制粒度上来看可以分为：全局访问限制和接口访问限制，本文讲的是接口访问的限制。写法是基于 AOP + 自定义注解 + Redis，并且封装在一个单独的模块 common-web 下，需要使用的模块只需引入该包，并且给需要限制的方法添加注解即可。 步骤： 获取注解参数 获取当前请求的ip和请求的方法 生成key 获取redis中该key的访问次数 判断次数是否超过范围 若超出范围，则拒绝访问，返回提示，并将TTL重置为注解上的等待时间 若没有超过范围，则允许访问，并将访问次数+1 若查询不到该key，则往redis中进行添加，将值设置为1，将TTL设置为注解上的值
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月17日晚 打卡day28 今天主要学习的内容是关于接口IP访问限制的问题。 一般向外暴露的接口，都需要加上一个访问限制，以防止有人恶意刷流量或者爆破，访问限制的做法有很多种，从控制粒度上来看可以分为：全局访问限制和接口访问限制，本文讲的是接口访问的限制。写法是基于 AOP + 自定义注解 + Redis，并且封装在一个单独的模块 common-web 下，需要使用的模块只需引入该包，并且给需要限制的方法添加注解即可。 步骤： 获取注解参数 获取当前请求的ip和请求的方法 生成key 获取redis中该key的访问次数 判断次数是否超过范围 若超出范围，则拒绝访问，返回提示，并将TTL重置为注解上的等待时间 若没有超过范围，则允许访问，并将访问次数+1 若查询不到该key，则往redis中进行添加，将值设置为1，将TTL设置为注解上的值
展开
评论
点赞
#青训营笔记创作活动#
2023年2月15日晚 打卡day27 今天主要学习的内容是关于分库分表的问题。 分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。 分库分表是由分库和分表这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。 单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。 一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行分库分表。
2023年2月15日晚 打卡day27 今天主要学习的内容是关于分库分表的问题。 分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。 分库分表是由分库和分表这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。 单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。 一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行分库分表。
展开
评论
点赞
#青训营笔记创作活动#
2023年2月14日上午 打卡day26 今天主要学习的内容是关于缓存和数据库不一致性问题。 数据库和缓存的数据不一致问题，大都是产生在更新数据时。 在更新的时候，操作缓存和数据库无疑就是以下四种可能之一： 1、先更新缓存，再更新数据库 2、先更新数据库，再更新缓存 3、先删除缓存，再更新数据库 4、先更新数据库，再删除缓存 现有的解决方案中，可以使用 alibaba 的开源组件 Canal，订阅数据库变更日志，当数据库发生变更时，我们可以拿到具体操作的数据，然后再去根据具体的数据，去删除对应的缓存。 当然Canal 也是要配合消息队列一起来使用的，因为其Canal本身是没有数据处理能力的。
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月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月12日上午 打卡day24 今天主要学习的内容是关于高并发下秒杀商品的内容。 1 瞬时高并发：正常情况下，大部分用户会收到商品已经抢完的提醒，收到该提醒后，他们大概率不会在那个活动页面停留了，如此一来，用户并发量又会急剧下降。所以这个峰值持续的时间其实是非常短的，这样就会出现瞬时高并发的情况。 2. 页面静态化：就需要使用CDN，它的全称是Content Delivery Network，即内容分发网络。使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。 3 秒杀按钮：大部分用户怕错过秒杀时间点，一般会提前进入活动页面。此时看到的秒杀按钮是置灰，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。 4 读多写少：由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。这是非常典型的：读多写少 的场景。 5 缓存问题：用户在点击秒杀按钮，请求秒杀接口的过程中，需要传入的商品id参数，然后服务端需要校验该商品是否合法。 6 库存问题：如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。 7 分布式锁：如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。 8 mq异步处理：所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成mq异步处理的。
展开
评论
点赞