高并发和消息队列面试常问
高并发三种解决方法？
高并发三种解决方法？
1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。
2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。
视频课程推荐→：《千万级数据并发解决方案（理论 实战）》
3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。
1秒1000并发，高并发需要什么样的服务器？
目前是用的MongoDB数据库，用了四台天互的豪华云主机才勉强达到一秒八九百并发。
硬件层面需要根据数据量，业务复杂度一起综合评估的，建议先买两台云主机（4核8g内存）搭建集群环境就行。后继再根据实际需要扩展。
软件层面：
一、如果是写入操作的，应该：
1.1 使用消息队列来异步处理（如activemq等），避免消息堵塞
1.2 使用MongoDB的批量写入功能，比如每1000条数据才写入一次
二、MongoDB部署为集群模式，可以分散压力
三、如果是读取操作，可以考虑加入redis，将热点数据进行一级缓存
1秒1000的并发不是太高，只要简单优化一下就行了，现在一般的服务器应该都能够支撑。首先看看线程池分配，看看linux系统的io数限制。
当然不建议让数据库去抗频繁的高并发，应该在整体架构上面作优化，在数据库上层是不是可以考虑架构缓存服务器，还有针对具体业务做些优化。
读多还是写多，索引建得如何？慢sql有哪些？单次访问数据量如何？
从正常角度讲，远远没有到数据库的性能瓶颈，具体问题要具体分析。
硬件看上去够用，程序优化比较重要
正常情况单机抗几千妥妥没问题，看你的情况问题可能出在两方面：web服务的io或DB。
web服务的性能关键因素是io和线程模型，如果采用epoll系列的nio的web框架（netty，mina等）性能相比bio会高很多。
其次就是DB，索引，os的页缓存等等。
一千块的程序员都能写一秒一千单的服务器
宽带肯定是要万兆的，硬件这块其实还好，现在可以用很廉价的pc来做分布式的架构，至于内存和硬盘的大小主要是根据数据量的大小和存储多少来决定的。希望我的回答能帮助到你！