如何解决5万的并发量

如何解决5万的并发量"/>

如何解决5万的并发量

模拟情景：
类似京东618秒杀活动，数据库中（mysql）只有一条数据，然后有5万并发量，页面要保证正常显示。

问题一：不用redis等分布式框架，就用传统的方法如何解决？如何保证数据库的稳定？

1. 页面商品剩余数量的准确性
   剩余数量的查询属于QPS，而且你这里假设只有一行数据，所以一台数据就算5W并发，查询再快，传输也有极限,而且这个假设在实际情况中几乎不存在只需要考虑数据库里面只有1行数据的并发，如果要提升mysql的查并发，可以多搞几台read从库，提供更多的查询性能，允许一部分实际的查询不精确，但是在下单写入的时候，确保TPS无误差
2. 页面访问的流畅性
   前提有几个，1：公司的带宽足够，2:问题1解决，3，在前台加一个nginx反向代理，把流量打到足够多的服务上去，把流量硬吃下来
3. 商品交易数据的安全性
   这个不属于性能问题的范畴，就算没有性能问题，也需要考虑逻辑上的安全性
4. 防止数据库崩溃
   如果不用redis，你需要估算出你每一台服务器大致能接受多少个并发，你的逻辑层的服务器有多少台(就是第2步里说的，被反向代理的服务器有多少台)，你需要自己评估，然后再在内存里写一个linkedblockingqueue，设置，当这个queue接受的请求太多时，直接拒绝请求，提示稍后再试
5. 用户参与后反馈的及时性
   一般情况下，反馈及时性一点都不重要，如果有消息队列，就按照能处理的上限来处理好了，但是数据库最好分开，别用同一个mysql

问题二：使用redis等分布式框架如何解决呢？

1. 页面商品剩余数量的准确性
   用简单的方式，可以写个job，去写商品的库存，轮询的固定时间更新一下，从数据库里读内容。剩余数量没必要那么实时，一点必要都没有。或者在订单购买成功时候，再触发一下更新redis库存，秒杀情况下，update会非常频繁，所以不如轮询的每几秒更新一下来的划算
2. 页面访问的流畅性
   这点和不用redis的时候做法类似，只是在查询的时候，不是读mysql从库了，是读redis
3. 商品交易数据的安全性
   略…
4. 防止数据库崩溃
   这里和上面比，需要额外考虑的不仅仅是数据库崩溃，还得考虑redis不可用，最好的方案是你redis做高可用，如果redis不可用时，你加上了跳过redis，查询数据库的逻辑，则数据库崩的可能更快
5. 用户参与后反馈的及时性
   略…

原文出处：=1