步骤流程:线程组--->Http请求--->查看结果树--->聚合报告
tips:host的文件--->优先调用映射,减少DNS的时间
默认内嵌Tomcat配置---->参数调优
server.tomcat.accept-count:等待队列长度,默认100
server.tomcat.max-connections:最大可被连接数,默认10000
server.tomcat.max-threads:最大工作线程数,默认200
server.tomcat.min-spare-threads:最小工作线程数,默认10
默认配置下,连接超过10000后出现拒绝连接情况
默认配置下,触发的请求超过200+100后拒绝处理
定制化内嵌Tomcat开发--->keepalive
keepAliveTimeOut:多少毫秒后不响应的断开keepalive
maxKeepAliveRequests:多少次请求后keepalive断开失效
使用WebServerFactoryCustomizer定制化内嵌tomcat配置
MySQL数据库QPS容量问题
◆主键查询:千万级别数据=1-10毫秒
◆唯一索引查询:千万级别数据=10-100毫秒
◆非唯一索引查询:千万级别数据=100-1000毫秒
◆无索引:百万条数据=1000毫秒+
使用Nginx做为静态资源服务器+nginx反向代理负载均衡
Nginx的高性能原因:
传统的会话管理
基于cookie传输sessionid:JAVA tomcat容器session实现
基于token传输类似sessionid:java代码session实现
使用redis实现分布式会话存储
基于cookie传输sessionid:java tomcat容器session实现迁移到redis
基于token传输类似sessionid:java代码session实现迁移到redis
缓存设计
用快速存取设备
用内存将缓存推到离用户最近的地方
脏缓存清理
1.redis缓存:单机、哨兵、集群----(注意序列化问题)
2.热点内存本地缓存--Guava cache
3.nginx proxy cache缓存--实际效果还不如本地缓存 ,可以用shared dic (2000)
4.nginx lua缓存
shared dic:共享内存字典,所有worker进程可见,Iru淘汰 ---更新操作不强 (3500)
使用openresty对redis支持,可以连接到从机,只读不写。(3500)
1.DNS用CNAME解析到源站
2.回源缓存设置
cache control响应头
有效性验证
三种刷新方式
CDN自定义缓存策略
css,js,img等元素使用带版本号部署,例如a.js?v=1.0不便利且维护困难
css,js,img等元素使用带摘要部署,例如a.js?v=45edw存在先部署html还是先部署资源的覆盖问题(先后问题)
css.js,img等元素使用摘要做文件名部署,例如45edw.js,新老版本并存且可回滚,资源部署完后再部署html(==好==)
对应静态资源保持生命周期内不会变,max-age可设置的很长,无视失效更新周期
html文件设置no-cache或较短max age,以便于更新
html文件仍然设置较长的max age,依靠动态的获取版本号请求发送到后端,异步下载最新的版本号的html后展示渲染在前端
动态请求也可以静态化成json资源推送到cdn上 依靠异步请求获取后端节点对应资源状态做紧急下架处理
可通过跑批紧急推送cdn内容以使其下架等操作
定义:在服务端完成html,css,甚至js的load渲染成纯html文件后直接以静态资源的方式部署到cdn上
phantomjs应用---类似于爬虫的原理
修改需要全页面静态化的实现,采用initView和hasInit方式防止多次初始化
编写对应轮讯生成内容方式
将全静态化页面生成后推送到cdn
扣减库存缓存化
(1)活动发布同步库存进缓存
(2)下单交易减缓存库存
异步同步数据库------异步消息队列rocketmq
分布式事务
库存数据库最终一致性保证
方案:
(1)引入库存操作流水
(2)引入事务性消息机制
秒杀令牌的原理和使用方式
秒杀大闸的原理和使用方式
队列泄洪的原理和使用方式
本地OR分布式?
可以使用外部的分布式,如果出现了性能问题,可以使用降级策略,切换到本地。
为什么要进行限流?
限流方案
限流力度
限流范围
传统防刷
黄牛为什么难防
防刷策略
1.验证码
2.排队,限流,令牌均只能控制总流量,无法控制黄牛流量
3.不同端进行隔离,使用代码混淆,HTTPs等技术
4.设备指纹
◆采集终端设备各项参数,启动应用时生成唯一设备指纹
◆根据对应设备指纹的参数猜测出模拟器等可疑设备概率
5.凭证系统
◆根据设备指纹下发凭证
◆关键业务链路上带上凭证并由业务系统到凭证服务器上验证
◆凭证服务器根据对应凭证所等价的设备指纹参数并根据实时行为风控系统判定对应凭证的可疑度分数
◆若分数低于某个数值则由业务系统返回固定错误码,拉起前端验证码验身,验身成功后加入凭证服务器对应分数
通用性能优化---缓存+异步+批处理
写---批量写
读---索引
mysql单机配置性能优化拓展
max_connection=1000
innodb _file_per_table=1
innodb_buffer_pool_size=1G
innodb_log_ file_size=256M
innodb_log_buffer_size=16M
innodb_flush_log_at_trx_commit=2(1---事务提交就刷盘)
mysql主从
CAP理论
base理论
作者:gsyzh
链接:https://juejin.im/post/5ed5adbd6fb9a047d3710da4