高并发和分布式,15讲,8月14日

某网友:高并发:使用场景少,价格高昂,好比屠龙之技,龙就那么几条,还都差不多被砍死了。

随着相关资料的泛滥,将来它会是一门“出入江湖必备的手艺”,如太祖长拳一般的泛滥,不值一文。

 

1、mysql

1)1主多从,多主多从

2)sql优化:explain

3)谢绝join语句

某研发,执行1个select联表查询,cpu卡了2秒,线上报警

 

2、缓存

1)本地cache

2)缓存:redis

3)es集群

有点缓存的意思~

搜索,排序,计算

4)预加载数据

 

3、mq消息队列

 

1)削峰填谷,充分利用

2)异步处理

3)拒绝分布式事务,也不太可能强一致性分布式事务

4)业务模式的优化:业务逻辑梳理

5)本地事务+mq

try{

 

        makeOrder();

 

        sendMq();

 

   }catch(Exception e){

 

      ...

 

   }

 

  mq是一个服务,也可能挂掉。

 

try{

 

        makeOrder();

 

        saveLocalLog();

 

   }catch(Exception e){

 

      ...

 

   }

 

 

 

   for(Log log : logList){

 

       sendMq();

 

  }

 

 

4、RPC接口:响应时间,很快,100ms以内,20ms以内

 

多线程:同时查询多个rpc

多个业务包装到1个rpc返回,而不是分多次查询

RPC接口,要合理拆分,订单-支付紧密放在一起;商品-广告等展示的放一起。

 

5、避免查询时计算

1个商品,多少人评价

 

6、批量查询

谢绝for循环查询,redis批量查询,mget

 

7、开关,降级

618各种开关,缓存,永久缓存

 

8、堆机器,32台机器

几百万用户,几十万用户,并发访问

 

扩容,缩容

 

9、只查询必要的字段,只返回必要的字段

 

10、代码本身的优化

工具代码,选择性能好的,Fastjson...

 

11、部署在相同的机房

同1个人的请求,映射到同1个机器~

 

12、批量查询 替代 单个查询

for循环+单个查询,禁止

redis,mget批量查询

 

13、重复点击

前端 按钮禁止,后端 防重?表单提交,带token

 

14、业务流程拆分,简化。

用户操作,简化。

比如,员工花名册,全部资料批量保存。改为 1个模块,单独保存。甚至1个模块的,学习经历,分条操作。

转账处理,给个 loading提示~支付,用户手动点击 "已支付"

 

100、几千万上亿用户

套路完全一样吗?还需要做更多的技术优化吗,除了堆机器。。。

©️2020 CSDN 皮肤主题: 猿与汪的秘密 设计师:上身试试 返回首页