高并发方案部分心得

高并发解决思路

 

一 多读场景（读多，修改少，新增少）

 

读的慢有很多原因：

业务问题：代码长期积累，业务复杂未及时维护优化，表设计不合理，没跟的上需求进度

数据库问题：数据库瓶颈，单表过大，无索引或者索引不合适以及该表不适合建立索引等

 

具体需求场景 有以下：红包表单表过大，用户表单表过大等，报表统计过慢等

 

解决方案：

1.业务优化，删掉无用代码，拿到应该合理执行的sql

2.对sql分析，进行相关索引添加，进行模拟多请求场景测试；

以上不行的话

1.考虑项目调整时间及人力以及可操作性 ，进行 缓存如redis 添加 ，做热点数据加载到缓存中（冷热隔离）

2. 根据业务拆表 ，把单表压力分担到各个表上

第一种 好处

热点数据的获取比较快

坏处

其他数据获取比较慢，而且 更新时还要做到缓存及数据库一致性

 

第二种 好处 单表不存在压力

坏处 可能数据库压力过大，io瓶颈，分表仍需分库，改动时间过久， 代码调整为 从多库多表进行查询

 

二 多写 场景 （疯狂的insert ）

业务场景分析：

该表多见于流水表（资金流水），日志表（第三方请求日志），以及一些特殊场景 红包表

 

问题分析：

数据库io瓶颈

 

解决方案：（缓解数据库压力）

数据库层面解决，

1.不使用关系型数据库，使用manggodb 等

2.多库多表 比如 用户 id1-1w 为一个库

代码层面减少数据库压力

.在不要求实时性的前提下，把请求积累下来，异步入库，降低数据库压力，可以使用消息队列，可以使用redis 存放，异步刷新入库等

 

三 多更改场景 （该表每条记录 变动都极其频繁（非删除新增））

需求 公司账号频繁转出帐，点赞，减库存

问题分析：

过多的update 语句 ，对数据库造成很大的压力；代码层面不保证串行化的前提下，很容易出现读取数据及计算与库内不一致问题；加锁又极度影响性能

 

解决方案：

数据库层面

该值拆分为多个字段，共同组成，通过乐观锁进行重试，业务层面更改不同的值，最后合计；坏处，记录不清晰很难维护，io瓶颈依然存在

 

缓存

保证缓存的准确性，通过消息队列推送或定时任务拉取等多个方案，让数据库最终与缓存一致

 

 

四 读写混合场景（该表查询及新增过多）

需求场景：红包发放 红包单表

 

解决方案：

1.业务层面优化

2.热点数据做缓存

3.代码层面 mq 做异步入库

4.分库分表 分压力

 

 

总结：

上述方案只是大致思路，真实场景下，高并发引起的问题根本也是单库的单表压力过大，解决方案缓存，进行冷热分离，多库多表等 代码层面的技术选择需要根据业务进行不同的选型去定位，甚至定制