如何解决5万的并发量

[午后慵懒咖啡]

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

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

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

个人没有接触过高并发，所以不太了解，希望各位说详细点，谢谢。

[zhangchao19890805]

只有一条数据是怎么回事？另外读写的业务情况怎么样？建议把业务说的详细些。 笼统的说一下：你可以试试 mycat 用读写分离。多个mysql部署在不同机器上分担压力。

[点滴寸土]

1.可以使用MQ队列，配合缓存，控制操作数据库的频率，减轻压力； 2.分布式架构后，入口数据分层，过滤，满足条件的走业务，其余的缓存处理，分别响应

[tianfang]

秒杀一定要异步处理，同步处理一定会被压垮 使用队列技术排队处理

[午后慵懒咖啡]

引用 1 楼 zhangchao19890805 的回复:

只有一条数据是怎么回事？另外读写的业务情况怎么样？建议把业务说的详细些。 笼统的说一下：你可以试试 mycat 用读写分离。多个mysql部署在不同机器上分担压力。

一条数据是指：在某个时间段开始最大5万并发的秒杀期间还没被抢的商品只剩下一个，需要处理： 1. 页面商品剩余数量的准确性 2. 页面访问的流畅性 3. 商品交易数据的安全性 4. 防止数据库崩溃 5. 用户参与后反馈的及时性

[tlzjff]

问题一：不用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. 用户参与后反馈的及时性 略...

[范翻番樊]

lllll;;l;l;;l'

[范翻番樊]

打错了不好意思！

[能源恒观]

5万不算并发吧，一条数据，数据库加锁就OK了