如何解决5万的并发量"/>
如何解决5万的并发量
模拟情景:
类似京东618秒杀活动,数据库中(mysql)只有一条数据,然后有5万并发量,页面要保证正常显示。
问题一:不用redis等分布式框架,就用传统的方法如何解决?如何保证数据库的稳定?
- 页面商品剩余数量的准确性
剩余数量的查询属于QPS,而且你这里假设只有一行数据,所以一台数据就算5W并发,查询再快,传输也有极限,而且这个假设在实际情况中几乎不存在只需要考虑数据库里面只有1行数据的并发,如果要提升mysql的查并发,可以多搞几台read从库,提供更多的查询性能,允许一部分实际的查询不精确,但是在下单写入的时候,确保TPS无误差 - 页面访问的流畅性
前提有几个,1:公司的带宽足够,2:问题1解决,3,在前台加一个nginx反向代理,把流量打到足够多的服务上去,把流量硬吃下来 - 商品交易数据的安全性
这个不属于性能问题的范畴,就算没有性能问题,也需要考虑逻辑上的安全性 - 防止数据库崩溃
如果不用redis,你需要估算出你每一台服务器大致能接受多少个并发,你的逻辑层的服务器有多少台(就是第2步里说的,被反向代理的服务器有多少台),你需要自己评估,然后再在内存里写一个linkedblockingqueue,设置,当这个queue接受的请求太多时,直接拒绝请求,提示稍后再试 - 用户参与后反馈的及时性
一般情况下,反馈及时性一点都不重要,如果有消息队列,就按照能处理的上限来处理好了,但是数据库最好分开,别用同一个mysql
问题二:使用redis等分布式框架如何解决呢?
- 页面商品剩余数量的准确性
用简单的方式,可以写个job,去写商品的库存,轮询的固定时间更新一下,从数据库里读内容。剩余数量没必要那么实时,一点必要都没有。或者在订单购买成功时候,再触发一下更新redis库存,秒杀情况下,update会非常频繁,所以不如轮询的每几秒更新一下来的划算 - 页面访问的流畅性
这点和不用redis的时候做法类似,只是在查询的时候,不是读mysql从库了,是读redis - 商品交易数据的安全性
略… - 防止数据库崩溃
这里和上面比,需要额外考虑的不仅仅是数据库崩溃,还得考虑redis不可用,最好的方案是你redis做高可用,如果redis不可用时,你加上了跳过redis,查询数据库的逻辑,则数据库崩的可能更快 - 用户参与后反馈的及时性
略…
原文出处:=1
更多推荐
如何解决5万的并发量
发布评论