Katashi的博客

为了融入公司而学Spring…IOC 概念 控制反转IoC(Inversion of Control)是一个概念，是一种思想。 由Spring容器进行对象的创建和依赖注入，程序员在使用时直接取出使用。 和正转概念中，由程序员说了算不同。 项目搭建 Maven->quickstart resources新建，修改专有属性,删掉启动文件 pom里maven.compiler.source,maven.compiler.target改成1.8 添加spring依赖 12345<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.2.5.RELEASE</version></dependency> build里删除 加上 12345678910111213141516<resources> & ...

银行秒杀系统优化方案整理高并发 静态化与缓存 静态化 项目前后端分离，页面资源全部以静态化形式存储在服务器本地，不向服务端请求。 缓存 数据库中商品库存全部存储在Redis中，秒杀的时候进行库存预减，再搭配队列，减少对数据库的并发写操作。 图片与服务器分离 图片资源利用腾讯云对象存储技术，全部以url形式存储在数据库中，对图片的请求转发到腾讯云官方，减少服务器的压力。 Nginx反向代理、负载均衡 项目同时部署在两台服务器上，搭配Nginx进行反向代理与负载均衡，分流请求到不同服务器上。性能高的服务器权重高，另一台权重较低，分担了流量，减轻接口压力。 限流 前端限流 秒杀抢购按钮采用节流技术，限制用户点击次数。 Nginx限流 设置通过请求数进行限流，平均每秒允许不超过1000个请求，突发不超过2000个请求，并且处理突发2000个请求的时候，没有延迟，等到完成之后，按照正常的速率处理。在请求进入项目前就先进行一次流量削减，减少压力。 接口限流 在请求进入接口时再利用令牌桶技术进行进一步限流，再度减轻后端处理业务的压力。 消息队列 利用RabbitM ...

订单超时处理 需求 超时未支付的订单需要进行状态修改，改成已结束，并回滚库存数。 实现思路 使用延迟消息队列(死信队列)实现 在订单创建时发送一个延迟消息，内容为订单号，系统会在限定时间之后取出这个消息然后查询这个消息的支付状态，根据结果做出相应处理。 消息的TTL(Time To Live) 消息存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的情况下的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间就认为消息死了，成为死信。 业务逻辑 使用死信队列监听，超时后根据订单ID查询数据库中的订单信息，判断订单是否存在以及查看支付情况。 已支付 进行订单状态修改(三湘项目应该不需要) 未支付 关闭订单，修改状态为未支付但已结束，回滚库存 操作步骤 建立死信交换机orderTimeOutExchange 创建队列orderTimeOutQueue 绑定交换机与队列 创建队列orderCreateQueue，设置TTL，绑定死信交换机

高并发秒杀优化操作1. 减少数据库的操作 判断是否重复抢购这个操作可以优化，大致思路是把用户订单放到Redis里，键中加上用户，抢购时判断是否已存在信息。来代替查询数据库 具体操作 123//生成订单时redisTemplate.opsForValue().set("order:" + user.getId() + ":" + goods.getId(), JsonUtil.object2JsonStr(seckillOrder)); 1234567//秒杀操作前SeckillOrder seckillOrder = (SeckillOrder) redisTemplate.opsForValue().get("order:" +user.getId() + ":" + goodsId);//如果取出 ...

RabbitMQ交换机模式配置Fanout模式(广播模式) 简单理解 一个消息能被多个队列接受，多个队列接受的是同一个生产者的消息。转发消息最快，不处理路由键。 核心代码 Config里准备队列和交换机 Config里绑定交换机 配置发送和接收部分 配置Controller层 Direct模式 通过绑定交换件的方式让交换机指定转发到某个队列上 所有发送到Direct Exchange的消息被转发到RouteKey中指定的Queue 注意：Direct模式可以使用RabbitMQ自带的Exchange：default Exchange,所以不需要将 Exchange进行任何绑定(binding)操作，消息传递时，RouteKey必须完全匹配才会被队列接收，否则该消息会被抛弃。 重点：routing key与队列queues 的key保持一致，即可以路由到对应的queue中。 核心代码 Config配置类 MQSender配置 MQReceiver配置 Controller配置，记得注入 路由键若匹配不到，默认情况会丢失，但是可以通过对应的配置 ...

令牌桶限流算法 令牌桶原理 最初来源于计算机网络。在网络传输数据时，为了防止网络拥塞，需限制流出网络的流量，使流量以比较均匀的速度向外发送。 牌桶算法就实现了这个功能，可控制发送到网络上数据的数目，并允许突发数据的发送。大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。最后桶中可以保存的最大令牌数永远不会超过桶的大小。这意味，面对瞬时大流量，该算法可以在短时间内请求拿到大量令牌，而且拿令牌的过程并不是消耗很大的事情。 后端操作步骤 引入依赖 12345<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>28.2-jre</version></dependency> 基本使用 1234567891011121314151617/ ...

秒杀接口隐藏 思路 秒杀开始后，点击秒杀按钮不是直接进行秒杀，而是获取秒杀的接口地址。 每个人获得的秒杀地址都不一样。 获取到秒杀接口地址后，在进行秒杀操作 这种操作如何防止脚本？ 秒杀的接口并不是真正的秒杀接口，即使脚本知道这个秒杀接口也无法进行秒杀，时间到了才能获取到地址，并且地址具有一分钟的失效时间，等获取到了这个地址，添加进脚本的时候，已经被抢光了。 优化前 秒杀接口->秒杀操作 优化后 秒杀接口->获取唯一秒杀地址->秒杀地址拼接->秒杀请求发送->秒杀操作 能防止一部分脚本，但是有些能自动拼接的脚本比较麻烦，可以使用验证码。 前端操作 秒杀按钮点击调用获取秒杀路径的接口path 将获取到的path拼接到请求中 后端操作 Controller层 12345678910@GetMapping(value = "/path")@ResponseBodypublic RespBean getPath(TUser tuser, Long goodsId) { if (tuser == null) ...

Spring boot学习打包时遇到的问题以及对应的解决方案 原帖地址来自CSDN https://blog.csdn.net/weixin_43895254/article/details/114594201 一番操作过后发现仍然报错，似乎不是版本号的问题是在对settings.xml添加镜像时未在指定区域添加，以及添加过后未对应上下代码例如对应 结尾，但是复制进来的代码中也有一个 提前对应掉了

欢迎来到Katashi的博客 今天创建博客和通过git部署博客格外的顺利一路没有什么困难就成功了接下来就用这个博客记录学习点滴 以此勉励自己吧 2021/8/16 13:26