Question

如何处理高并发

Answer 1

处理高并发的六种方法

1：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，这样就可以抗高并发。

2：缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考的虑考虑你的项目里，那些承载主要请求读场景，怎么用缓存来抗高并发。

3：MQ(消息队列)，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，人家是缓存你要是用redis来承载写那肯定不行，数据随时就被LRU(淘汰掉最不经常使用的)了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的。

4：分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

5：读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6：solrCloud:
SolrCloud(solr 云)是Solr提供的分布式搜索方案，可以解决海量数据的 分布式全文检索，因为搭建了集群，因此具备高可用的特性，同时对数据进行主从备份，避免了单点故障问题。可以做到数据的快速恢复。并且可以动态的添加新的节点，再对数据进行平衡,可以做到负载均衡：

Answer 2

高并发的解决方案

其实这个问题必须结合上面的海量数据来讨论，什么情况下会出现高并发呢？一定是平时访问量就比较大的情况，那么平时访问量比较大相应的数据存储也就越来越多，这都是相辅相成的，当然也有个例，比如刚需，比如12306，这里的高并发相比于它的数据来说已经不算海量了。那么平时访问量大如何解决呢？因为这里牵扯到服务器和数据库的问题，所以要从这两方面来进行优化

1 增加web服务器数量，也就是做集群，做负载均衡。既然一台服务器无法完成任务，那就多用几台，几台不够用机房

在通向第二种解决方法之前，还有没有除了数据库服务器之外能做的一些优化手段呢？当然有

1.1 页面缓存

1.2 cdn

1.3 反向代理

1.4 应用程序和静态资源分离（比如专供下载的资源单独放在一起，给这台服务器提供很高的带宽资源）

2 增加数据库服务器数量，同样做集群，做负载均衡。

海量数据的解决方案

1 使用缓存

好多事情都是相辅相成的，相比来说使用缓存更多是用来解决高并发问题的，因为海量数据导致了访问的缓慢，容易造成高并发问题的严重性，又因为数据库一般是web访问的瓶颈，所以我们在业务逻辑允许的情况下尽量先避免操作数据库，于是，就有了缓存。将必要的数据存放在内存中，而不必每次都去数据库中读取造成不必要的性能浪费和加快访问速度---这就是缓存带来的好处。那使用缓存以及选用管理缓存软件时应该注意些什么东西呢？

2 页面静态化---不想解释，还有什么值得去解释呢？

3 数据库优化

3.1 数据库表结构涉及

3.2 数据类型的选用

3.3 sql优化

3.4 索引优化

3.5 配置优化

需要注意的地方实在太多，应该作为单独的一章拿出来讲

4 分离数据库中的活跃数据

为什么要分离呢？说一个我实际环境中遇到的问题吧！有一个表只有10几个字段，表有130万条数据，但大小已经到了5G的数据，这本身是不太合理的，这么少的数据占用了太多的数据，说明其中有些字段存储了大量的字符串（比如说文章内容等），每次检索这个表时大部分是用不到这些大字段内容的，但却需要耗时比较长，产生很多的慢日志。这时我们可以考虑将表进行垂直切分，将活跃数据分离开来，这样能大大加快访问速度

5 读写分离