这里写目录标题

  • 高并发解决方式：
  • 缓存数据一致性：
  • 缓存穿透：缓存中的数据没有，恶意请求，直接到数据库了
  • 缓存的雪崩：大量的数据在同一时刻失效，导致请求直接到数据库上了
  • 缓存的击穿：热点key访问非常高频，在热点key失效的瞬间，造成大量并发到数据库
  • 分布式事务：
  • Nginx高可用：
  • 分布式和微服务区别：
  • 前端向服务器信息推送技术
  • 高并发量：
  • dubbo的问题：


高并发解决方式：

  1. 缓存：redis内存数据库，Nginx静态页面缓存
  2. 异步：消息中间件，多线程
  3. 并发编程：
  4. 分布式：
  5. 数据库：数据库层可以用读写分离（前提是读多写少，读80%、写20%），分库分表，集群方式实现高并发（尽量不使用数据库的缓存，一般都是在服务层做缓存）

缓存数据一致性：

  1. 准实时性：利用消息队列MQ机制
  2. 缓存失效性；设定失效时间
  3. 强一致性：在增删改的业务中更新redis
  4. 定时任务

缓存穿透：缓存中的数据没有，恶意请求，直接到数据库了

  1. 缓存空对象：把不存在的数据也缓存到redis中，直接赋值为null
  2. 条件过滤：如果用的递增序列可直接<0;如果用的uuid，可以限定长度
  3. 布隆过滤器：是用一个很大的缓存map存放redis中的key，查询之前先校验map中是否有值

缓存的雪崩：大量的数据在同一时刻失效，导致请求直接到数据库上了

  1. 尽量不要让key在同一时间失效
  2. 数据预热：在大并发之前，把相关数据直接先缓存到redis中
  3. 缓存永不过期：一些热点，重要的key，永不过期。

缓存的击穿：热点key访问非常高频，在热点key失效的瞬间，造成大量并发到数据库

  1. 永不过期；最有效方式将这些热点key永不过期 2. 互斥锁：当前热点key正在查询数据库，其他人排队。排队到时间后直接从redis中取

分布式事务：

  1. redis方案解决：
  2. Zookeper方案解决：

Nginx高可用：

  1. LVS：keeplived
  2. DNS负载：一个域名对应多个ip地址

分布式和微服务区别：

  1. 微服务连数据库也是独立的

前端向服务器信息推送技术

  1. 短轮询方式：用js的setInterval定时任务发送ajax请求（如京东登录、京东支付后跳转下单页面）；
    方案：浏览器js设置定时任务
  2. 长轮询方式：客户端请求后，客户端等待，直到有结果再返回。返回后，再次请求（如今日头条消息滚动）。
    方案：浏览器请求有结果后再次调用当前函数；服务端结合spring3提供的DeferredResult使用。
  3. SSE长连接：eventsource支持断线重连
    方案：浏览器用eventsource函数；服务端改动见视频
  4. websocket：

高并发量：

redis：读10万+，写8万+
mysql：机械硬盘300，固态硬盘700
tomcat：平均300-500，极限1000
mysql 的最大连接数300-700
用nginx的页面缓存可以代替cdn技术，但是cdn是要付费的

dubbo的问题：

每次最多返回100条数据，多了需要修改dubbo的配置
序列问题，需要显示声明
编译版本的问题，不同机器编译的dubbo的class文件版本不一致，无法调用