##百度初秋打卡挑战赛#1.代码
之所以把代码放到第一位，是因为这一点最容易引忽视，比如拿到一个性能优化的需求以后，言必称缓存、异步等。
实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。
有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如for循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次等，这样的优化成本是最低的。
2.数据库
1.SQL优化
这里以MySQL为例，最常见的方式是，由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的SQL，然后使用explain、profile等工具来逐步调优，最后经过测试达到效果后上线。
这里举几个优化的例子：
1.查询优化
对查询进行优化，要尽量避免全表扫描，首先应考虑在where及orderby涉及的列上建立索引。
2.避免null判断
应尽量避免在where子句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
selectidfromtwherenumisnull
3.避免全表扫描
应尽量避免在where子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。
应尽量避免在where子句中使用or来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。
in和notin也要慎用，否则会导致全表扫描，如：
selectidfromtwherenumin(1,2,3)
对于连续的数值，能用between就不要用in了：
selectidfromtwherenumbetween1and3
4.大数据量查询
对于多张大数据量的表JOIN，要先分页再JOIN，否则逻辑读会很高。
5.合理使用索引
索引并不是越多越好，索引固然可以提高相应的select的效率，但同时也降低了insert及update的效率，因为insert或update时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。
一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
6.多使用数字型字段
尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
7.避免大数量
尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
8.避免大事务
尽量避免大事务操作，提高系统并发能力。
2.连接池调优
我们的应用为了实现数据库连接的高效获取、对数据库连接的限流等目的，通常会采用连接池类的方案，即每一个应用节点都管理了一个到各个数据库的连接池。
随着业务访问量或者数据量的增长，原有的连接池参数可能不能很好地满足需求，这个时候就需要结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量作一个综合的判断，通过反复的几次调试得到最终的调优参数。
3.架构层面
这一类调优包括读写分离、多从库负载均衡、水平和垂直分库分表等方面，一般需要的改动较大，但是频率没有SQL调优高，而且一般需要DBA来配合参与。
3.分布式缓存
缓存可以称的上是性能优化的利器，缓存主要用来存放那些读写比很高、很少变化的数据。
什么情况适合用缓存？考虑以下两种场景：
短时间内相同数据重复查询多次且数据更新不频繁，这个时候可以选择先从缓存查询，查询不到再从数据库加载并回设到缓存的方式。此种场景较适合用单机缓存。
高并发查询热点数据，后端数据库不堪重负，可以用缓存来扛。
使用缓存需要注意的问题：
1.避免缓存失效
把频繁修改的数据放入缓存，容易出现数据写入缓存后，应用还来不及读取缓存，数据就已经失效的情形，徒增系统负担。
2.缓存热点数据
缓存使用的内存资源非常宝贵，只能将最新访问的数据缓存起来，而把历史数据清理出缓存，即缓存资源应该留给20%的热点数据。
3.数据不一致性
一般会对缓存设置失效时间，超过失效时间，就要从数据库重新加载。
因此应用要忍受一定时间的数据不一致，另一种策略是数据更新时立即更新缓存，不过这也会带来更多的系统开销和事务一致性的问题。
4.缓存可用性
业务发展到一定阶段时，缓存会承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务器崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用，这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。
解决方式：
1）缓存热备（当某台服务器宕机时，将缓存访问切换到热备服务器上；
2）缓存服务器集群。
5.缓存预热
缓存中存放的是热点数据，热点数据是缓存系统用LRU对不断访问的数据筛选出来的，这个过程需要较长的时间。
新启动的缓存系统没有任何数据，此时系统的性能和数据库负载都不太好。因此可以选择在启动缓存是就把热点数据预加载好。
6.缓存穿透
因为不恰当的业务或恶意攻击，持续高并发地访问某一个不存在的数据，如果缓存不保存该数据，就会有大量的请求压力落在数据库上。
简单的解决方式是把请求的不存在的数据也放进缓存，其value是null。
4.异步化
针对某些客户端的请求，在服务端可能需要针对这些请求做一些附属的事情，这些事情其实用户并不关心或者用户不需要立即拿到这些事情的处理结果，这种情况就比较适合用异步的方式处理这些事情。
异步化的作用：
缩短接口响应时间，使用户的请求快速返回，用户体验更好。
避免线程长时间处于运行状态，这样会引起服务线程池的可用线程长时间不够用，进而引起线程池任务队列长度增大，从而阻塞更多请求任务，使得更多请求得不到技术处理。
线程长时间处于运行状态，可能还会引起系统Load、CPU使用率、机器整体性能下降等一系列问题，甚至引发雪崩。异步的思路可以在不增加机器数和CPU数的情况下，有效解决这个问题。
比如：使用消息队列（MQ）中间件服务，MQ天生就是异步的。
一些额外的任务，可能不需要我这个系统来处理，但是需要其他系统来处理，这个时候可以先把它封装成一个消息，扔到消息队列里面，通过消息中间件的可靠性保证把消息投递到关心它的系统，然后让这个系统来做相应的处理。
再比如C端在完成一个提单动作以后，可能需要其它端做一系列的事情，但是这些事情的结果不会立刻对C端用户产生影响，那么就可以先把C端下单的请求响应先返回给用户，返回之前往MQ中发一个消息即可，而且这些事情理应不是C端的负责范围，所以这个时候用MQ的方式，来解决这个问题最合适。
5.Web前段
Web前端指网站业务逻辑之前的部分，包括：
浏览器加载
网站视图模型
图片服务
CDN服务等
主要优化手段有优化浏览器访问，使用反向代理，CDN等。
1.浏览器访问优化
(1)减少