赞
踩
对做完的火车卖票系统项目的学习汇总
如果并发量巨大的情况下如何保证系统的稳定
服务拆分 负载均衡 限流熔断降级 缓存 使用令牌 异步处理
数据库方面 我只想得到分库分表 读写分离以及对经常进行查询的字段添加索引提高查询速度,对字段的类型长度设置一个合适的值
缓存:
接口查询多修改少挺适合做缓存的 例如:车票查询(测试了一下myabtis一级二级缓存感觉并不 好用还得是redis)
缓存穿透:允许缓存为null,请求进来的时候查询缓存如果是空列表则说明数据库没有数据直 接返回给前端,如果是null则说明没有这个缓存则去数据库查询数据。
缓存击穿:使用定时任务 30s访问一次该接口然后生成缓存,如果缓存机器失效,我想只能使 用分布式锁了。
缓存雪崩:在原有做了redis缓存接口的基础上做一个定时任务,每30s生成热点的key同时进行限流。那么分 布式锁有没有用呢?我不禁产生这个疑问,但只能限制热点的key,此时大量请求进入数据库 无法限制流量的进入。好像并没有作用 如果实在不行也就只能进行熔断了暂停服务
解决超卖问题:
一 使用synchronized但经过测试会导致两个问题
1 堵塞线程太慢了 ,售卖效率不高并且性能不好
2 如果是多节点那么没用还是会导致超卖
二 可以使用数据库加锁解决超卖问题 缺点性能不高
三 使用redis设置分布式锁,把火车编号和时间作为key以此判断是否是购买相同的票
如果线程还在执行超时了怎么办?当时的想法是得弄个监控分布式锁的过期时间如果过 期则进行刷新,经过百度发现Redisson看门狗方案,会生成一个守护线程一直刷新锁的 时间。但如果redis宕机了,那只能使用redis集群了吧,红锁:只有拿到半数以上节点的 锁才能视为拿到锁
常见限流算法:
静态窗口限流 动态窗口限流 漏桶限流(一个队列一边进一边出)
令牌桶限流(一边产生令牌一边取令牌) 令牌大闸
令牌大闸:1.使用令牌锁解决机器人刷票问题 2.如果没有余票不如直接查询令牌余量节省性能
令牌大闸方案:
添加一个令牌锁(不进行解锁等待过期防止机器人进行抢票) 如果取到令牌锁则去对缓存内对令牌数量进行更改,为了防止经常查询数据库每减少一定的令牌则对数据库进行一次更改操作
购票流程:
RocketMQ:进行异步削峰+排队机制改进用户体验将购票流程一分为二(购票请求(拿到令牌锁 发送消息)和出票动作(拿到分布式锁 处理订单)分为两个模块)
购票请求(拿到令牌之后传递消息给消费者端),出票动作(使用排队机制防止因为没拿到购票 的分布式锁快速失败,白白消耗令牌),前端轮询购票结果
排队机制:拿到分布式锁 使用wile(true) 每次查出一定的条数去进行出票的操作,如果没有票 了则break
购票请求:拿到令牌锁然后去把订单写入数据库对缓存内的令牌数量进行减一操作
然后发送MQ消息,把订单ID返回前端
出票动作:先对订单更改为处理中然后一个车箱一个车箱的获取座位数据判断订单内的列号 以及是否售出
车票: ABCDE 5个站 0000(未售出) 1111(售出) 例如 AB 1000 AC 1100 BC 0100 BD 0110
最后进行压力测试 1000线程/S
最后我发现不管使用异步注解还是修改JVM内存都并不影响最终的测试结果都是400多吞吐
记录一个遇到的问题:
RockMQTemplate无法创建bean,原来springboot3中spring.factories功能被移除所以 rocketmqTemplate注入失败:
解决方法:resources下创建一个META-INF.spring
创建org.springframework.boot.autoconfigure.AutoConfiguration.imports
放入org.apache.rocketmq.spring.autoconfigure.RocketMQAutoConfiguration
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。