高并发系统的持续优化以及常见事故分析

高并发场景很多，如秒杀、抽奖、活动促销等等。
对此系统要经过不断的优化才能达到理想状态，优化方式也有众多选择，要根据实际环境采取合适策略。

硬件、操作系统方面

1、增加内存、换用高性能硬盘或者固态硬盘
2、linux系统修改文件最大打开进程数

网络方面

1、增加公网带宽，采用CDN缓存
2、内部系统通信尽量使用局域网

应用方面

1、合理使用缓存，尽量减少数据库的使用
2、批量任务合理使用多线程异步操作，多采用池化结构
3、合理使用消息中间件对应用解耦，高访问量削峰填谷
4、尽量进行系统切割，采用分布式部署，对不同的访问量采用不同部署方式
5、加锁操作中尽量缩小加锁范围

数据库方面

1、合理组织sql语句，
①合理使用索引（单个索引、联合索引，太多会影响表插入、删除速度，jion列使用索引）
②尽量减少让索引失效的语句使用例如：like ‘%’，or,sql中拼接、sql中使用计算函数等；
③多表查询使用小表驱动大表；
④select只返回需要的项
⑤表字段设计时尽量非空等等

2、 合理使用缓存，例如Mybatis开启一级、二级缓存，减少数据库访问，开启preparedStatement,减少运行时sql预编译开销

3、采用良好的数据库架构设计，诸如读写分离，水平拆分、垂直拆分；读写分离、垂直拆分即为多数据源问题，拆分规则可以为地域、业务发生时间、业务类型等，可以通过数据访问层中间件或AOP+Annotation自己实现；水平拆分注意拆分规则，可以采用用户ID，账户ID等进行拆分，注意避免多数据库联合查询、分布式事物等，为此可以在设计表的时候进行一定的数据冗余，例如交易表存留客户一些必要信息，将公共表例如权限、路由表在每个库均复制一份

4、 采用高可用的分布式事物解决方案，例如：2pc(对网络要求高，高并发下系统负载太大，效率不高)、柔性事物（通过rocketmq发送事物消息，达到数据最终一致性）

常见事故

1、数据库连接不足
a、配置的最大连接数不足，检查实际配置
b、代码编写不当，不需要读写数据库的位置也会尝试获取数据库连接，比如一个service只是一个不需要数据库的常规操作，应用却定义所有的service的所有方法执行时都会获取connection（spring框架下如此配置时即使没有执行sql也会在当前线程中抢占一个Connection）
2、redis读写错误或者连接不上
a、有不当命令，比如keys频繁抢占redis线程导致其他操作命令堵塞
b、redis挂掉了，需要检查磁盘、内存资源是否足够
c、命令超时时间过短
3、数据库死锁
a、io压力过大，需要优化
b、sql编写不当，发生逻辑死锁

优化分析思路

1.对于大流量的网站,采用什么样的方法来解决各页面访问量统计问题？
第一，确认服务器硬件是否足够支持当前的流量。
普通的P4服务器一般最多能支持每天10万独立IP，如果访问量比这个还要大，那么必须首先配置一台更高性能的专用服务器才能解决问题，否则怎么优化都不可能彻底解决性能问题。

第二，优化数据库访问。
服务器的负载过大，一个重要的原因是CPU负荷过大，降低服务器CPU的负荷，才能够有效打破瓶颈。而使用静态页面可以使得CPU的负荷最小化。前台实现完全的静态化当然最好，可以完全不用访问数据库，不过对于频繁更新的网站，静态化往往不能满足某些功能。
缓存技术就是另一个解决方案，就是将动态数据存储到缓存文件中，动态网页直接调用这些文件，而不必再访问数据库，WordPress和Z-Blog都大量使用这种缓存技术。
如果确实无法避免对数据库的访问，那么可以尝试优化数据库的查询SQL.避免使用Select *from这样的语句，每次查询只返回自己需要的结果，避免短时间内的大量SQL查询。

第三，禁止外部的盗链。
外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，Apache自己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗链，不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。

第四，控制大文件的下载。
大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要提供，建议将大文件放在另外一台服务器上。目前有不少免费的Web2.0网站提供图片分享和文件分享功能，因此可以尽量将图片和文件上传到这些分享网站。

第五，使用不同主机分流主要流量
将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了。

第六，使用流量分析统计软件。
在网站上安装一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面需要再进行优化，因此，解决流量问题还需要进行精确的统计分析才可以。我推荐使用的流量分析统计软件是GoogleAnalytics（Google分析）。

一致性 hash算法应用

分布式session、服务节点集群
环形队列分割若干个均等分割点，在多个点上部署节点，使得某个节点失效后，这个节点前的流量落在改节点后的节点上，其他节点不受影响，同时大部分数据落点仍然不变，避免了集体失效。

如何防止缓存雪崩、穿透

**缓存雪崩：**数据未加载到缓存中，或者缓存同一时间大面积的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机
解决思路：
1，采用加锁计数，或者使用合理的队列数量来避免缓存失效时对数据库造成太大的压力。这种办法虽然能缓解数据库的压力，但是同时又降低了系统的吞吐量。
2，分析用户行为，尽量让失效时间点均匀分布。避免缓存雪崩的出现。
3，如果是因为某台缓存服务器宕机，可以考虑做主备，比如：redis主备，但是双缓存涉及到更新事务的问题，update可能读到脏数据，需要好好解决。
4、数据预热，系统启动时缓存集中缓存所需数据

缓存穿透：数据库中不存在某个特殊数据，请求过来时不断去查询一个不存在的数据
解决思路：
1、布隆过滤器
2、缓存空对象，可设置有效时间