面试总结12——场景题

高并发解决

1. 尽量使用缓存，包括用户缓存，信息缓存等，可以大量减少与数据库的交互，提高性能。
2. 页面静态化
3. 使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。
4. 使用Ngnix负载均衡
5. 优化数据库查询语句，优化数据库结构，索引，提高查询效率，数据库集群和库表散列
6. 使用线程安全的集合对象
7. 使用线程池。

秒杀

1，优化：

将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）

充分利用缓存：秒杀买票，这是一个典型的读多写少的应用场景

2，基本架构

（1）浏览器端，最上层，会执行到一些JS代码
（2）站点层，这一层会访问后端数据，拼html页面返回给浏览器
（3）服务层，向上游屏蔽底层数据细节，提供数据访问
（4）数据层，最终的库存是存在这里的，mysql是一个典型（当然还有会缓存）

3，各层优化细节：

1）客户端（浏览器，app）：做限速

禁止重复提交请求：重复提交的话增加系统的负载

X秒之内只能提交一次请求——将请求尽量拦截在系统上游

2）站点层次：按照uid做限速，页面缓存

对uid进行请求计数和去重，一个uid，5秒只准透过1个请求。拦住for循环请求。

页面缓存：同一个uid，x秒内到达站点层的请求，均返回同一页面。

3）服务层（知道库存有多少）：按照业务做写请求队列控制流量，做数据缓存

写请求，做请求队列，每次只透有限的写请求（最多库存数量个）去数据层。读请求：cache，

分时分段售票，将流量平摊

数据粒度的优化，对于余票查询这个业务，流量大的时候，做一个粗粒度的“有票”“无票”缓存即可。不用具体到还有多少余量

业务逻辑的异步，下单业务与支付业务的分离。

数据库优化

1，优化sql和索引

(1)用慢查询日志定位执行效率低的SQL语句。

(2)用explain分析SQL的执行计划。

(3)确定问题，采取相应的优化措施，建立索引。

(4)避免全局扫描：where xx is null, !=, <>, in(可替代为between，exists), not in, or, %开头模糊索引，where中对字段进行表达式操作，

2，搭建缓存

缓存和数据库一致性问题

缓存的击穿，穿透，雪崩

3，读写分离，主从复制

4，分区表

5，垂直拆分

(1)把不常用的字段单独放在一张表。

(2)把常用的字段单独放一张表

(3)经常组合查询的列放在一张表中（联合索引）。

6，水平拆分：各模块间耦合性太强，成本太大

Mysql查询缓慢原因

1，查询一直很慢的情况

• 没有索引或者没有用到索引
• 统计出错，走的是全表扫描
• I/O吞吐量小，形成瓶颈。
• 网络速度慢

2，查询偶尔很慢的情况

• 锁或者死锁
• 刷脏页