使用的IDE是IDEA ，项目是springboot框架的项目
最近一直在处理高并发的问题，大致情况是这样的：大概有五六千人会在中午十二点同时访问网站，操作数据库，导致服务器崩溃。对于频繁修改数据的这种情况，例如：用户要抢商品，且抢完后要刷新看自己抢的商品，这会造成频繁的修改数据库和查询数据库，所以对于用数据库读写分离来说并不高效，因为这涉及到频繁的查询和修改数据库，而数据库的读写分离它需要一个数据共享的过程，比如说一个数据库用来读，一个数据库用来写，但是，用户登陆进去后，要抢商品，那就要写数据，写完后还要将写完的数据共享到读的那个数据库中去，这样用户返回刷新才能看到，这样就多此一举了，而且数据共享还需要一定的时间，这样就会导致用户刷新页面后看到自己还没有抢单成功，用户体验极不好，也会让用户产生怀疑。
这个时候加redis缓存会更效，为什么这么说呢？用户登录进来后抢单，将数据写入缓存和数据库，当用户再刷新时，用户访问的就是redis缓存里的数据了，不用再去查数据库，这样就减少了数据库的连接，减轻了数据库的负担。
最头疼的是，加了缓存后，还是一样的崩溃。这不由得让我想起mysql数据库连接数的问题。当产生高并发时，数据库的连接数是有限的，在使用了阿里的druid连接池后，也是一样的卡死，我先说我的解决方法：
解决方法很简单，就是修改druid的活跃连接数，我之前设置的是20，改成8后，解决了高并发的问题。
这是什么原因呢？ 通过压力测试后，发现一个规律：连接池的最大活跃连接数是根据你的服务器的配置来确定的。我一台服务器是四核的，一台是单核的，当我在双核的服务器上项目里设置的活跃连接数是20时，高并发并没有问题，但是在单核的服务器上项目里设置活跃连接数20时就会崩溃。
由此得出结论：你设置的连接池的活跃连接数是由你的服务器配置决定的。
也通过实验，当你的并发量很高时，连接数越小，吞吐量就越高。
我解决五六千的并发量就是这么解决的，并发量再往上如上万上百万千万的，那就需要用到集群分布式等技术了，但对于这种小并发量的操作没有必要用到这些技术，也会增加成本。配置连接池的maxActive，并不是这个数量越大越好，相反是越小越好，最好是根据你的服务器配置来。
我的连接池配置如下（.yml文件）：
datasource:
url: jdbc:mysql://localhost:3306/cgcx?useUnicode=true&characterEncoding=utf-8&&autoReconnect=true&failOverReadOnly=false&useSSL=false
username: root
password: 123456
driver-class-name: com.mysql.jdbc.Driver
platform: mysql
type: com.alibaba.druid.pool.DruidDataSource
# 下面为连接池的补充设置，应用到上面所有数据源中
# 初始化大小，最小，最大
initialSize: 1
minIdle: 2
maxActive: 8
# 配置获取连接等待超时的时间
maxWait: 60000
# 配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒
timeBetweenEvictionRunsMillis: 30000
# 配置一个连接在池中最小生存的时间，单位是毫秒
minEvictableIdleTimeMillis: 30000
validationQuery: select 'x'
testWhileIdle: true
testOnBorrow: false
testOnReturn: false
# 打开PSCache，并且指定每个连接上PSCache的大小
poolPreparedStatements: false
maxPoolPreparedStatementPerConnectionSize: 20
# 配置监控统计拦截的filters，去掉后监控界面sql无法统计，'wall'用于防火墙
filters: stat,wall,slf4j
# 通过connectProperties属性来打开mergeSql功能；慢SQL记录
connectionProperties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000
其实高并发这个问题还没有完全的解决方案，就连伟大的阿里巴巴淘宝也没有完全的解决，我们在双十一或双十二的时候，你花了好几天精心挑选的宝贝放在购物车里，到晚上十二点抢着付款那个时候，是不是点不动啊？哈哈哈哈！！！！
所以这个问题目前只能是尽量避免。并没有完全的解决方案。
希望能帮助到各位。
