前言：
来自之前做的笔记，总结一下
1.问题：
当高峰期请求数达到 1000-2000的时候，线上的内存开始吃紧，内存使用率开始上升； 高峰期，cpu转的很快，cpu负载开始增加，甚至达到60%-80%；
数据库快要扛不住了，磁盘io下降，sql开始跑的很慢
2.解决办法
**1.第一步 系统拆分，**把系统拆成多个，分别访问自己的数据库，部署在三个服务器上，三个数据库上； 如果请求翻三倍怎么办？
2**.（缓存）开始用缓存，**用缓存来抗读请求，大量读请求（5000/s个请求）还有1000个写请求去走数据库（写请求会先去删对应的缓存，然后去改数据库里的数据）；很多请求都是读请求，浏览啊什么的，redis可以抗很多请求 几万/s的并发
**3.（MQ）**如果用户继续增加，一亿的用户，10000/s个请求； 写请求很高，可以在系统和数据库之间加MQ；虽然每秒来2000个写请求，但是大量请求积压在MQ里面，数据库每秒消费1000个请求，MQ用来削峰
**4.（分库分表）**如果用了MQ还不能解决，用户继续增加，每秒2万个请求，这个时候写请求成倍增加，MQ可能也扛不住，数据库可能每秒需要消费2000个请求，这个时候需要分库分表，把数据库拆成3个数据库；MQ和数据库之间加一个异步系统，每秒给数据库去分发600个请求，分摊并发的压力
**5.（读写分离）**如果用户继续增加，这里有一个问题，因为缓存里的数据是可能失效的，系统还是会经常从数据库里读数据，写入缓存，每秒1000个请求； 这个时候需要做数据库的读写分离， 写的时候写主库，读的时候去读从库的数据，这个时候缓存失效的时候读数据就去从数据库里的从库读取，可以缓解压力
6.关于搜索的问题，如果是单机的可以基于lucence包封装搜索引擎，数据量越来越大，单机上lucence放不下了，而且单机也支撑不了那么大的并发，可以用分布式的搜索引擎ES，直接走ES的集群 可以放几十亿的数据量，用20台机器，每秒可以支撑几万的请求
总结：实际的真正复杂的系统，高并发远远比这个图复杂很多倍，哪些服务需要分库分表，哪些数据需要放缓存里去，哪些数据可以抗高并发的请求，完成对业务分析之后 逐步加入高并发的系统架构的构造，这个系统是很复杂。
