前言
高并发场景特别多，本文章将对高并发处理的主要扩容方向作分析，讲解部分实现，但是，不包括所有的高并发场景。
主体概要
- 扩容
主体内容
一、扩容
1.了解Java 内存结构的应该都知道 , 每个线程都有自己的工作内存, 占用内存大小取决于工作内存里变量的多少与大小 , 单个线程占用内存通常不会很大, 但是随着并发的线程不断的增加 , 从成百上千, 甚至几十万 , 占用的内存就会越来越多.这时候可能就要考虑给系统扩容了 , 简单点的升级内存, 复杂点的 , 增加服务器 , 分担压力。
- 垂直扩容(纵向扩展) , 比如上面提到的增加内存垂直扩容的主要是提高系统部件的能力,但会增大单个服务中其他软件设施的依赖与管理、服务内部复杂度。
-
水平扩容(横向扩展) , 比如上面提到的增加服务器水平扩容主要是增加更多的成员来分担压力，但会增加网络、数据库IO开销、管理多个服务器的难度。
当然，这两种称呼可能在别的地方有别的名称。
（1）首先，我们说一下垂直扩展，在垂直扩展模型里面，我们想要增加系统负荷,就意味着要在系统现有的部件上下功夫，就是通过通过提高系统部件负荷,意思是说现在有3辆卡车，每辆车运送到目的地需要1个小时，一辆车一次可运25根木材，有这些数据可以得出系统最大负荷量为3*25*1=75根木材每小时，现在我们想要每小时处理150根木材，我们现在想要使用垂直扩展模型，那么该怎么办呢？我们至少要做以下两件事，一是卡车运输量每小时25根木材变成每小时50根，要么让每辆卡车运输时间减半，我们没有增加系统的成员数，但是我们通过增加系统成员的生产效率来获得期望的负荷量。
（2）接下来，我们说下水平扩展，在水平扩展中，我们不是增加单个成员的负荷，而是简单的通过增加更多的系统成员，用上面例子来说就是在原有基础上再增加3辆卡车来运输。
2.这种方式让我们联想到服务器集群，这里我们要注意的是每种扩展策略的开销，当我们去提升系统负荷时，这些单独的组件需要在管理上花费更多。拿我们运送木材的例子来说，如果需要更高的车厢，有可能隧道的高度对车的高度有要求，或者宽度，或者驾驶要求，车厢不能太长，这些限制就是对卡车垂直扩展能做到什么限度的要求，我们处理器就需要更多的空间，进而要求更多的服务器存储组件。
相反的，采用水平扩容将额外的开销放在系统中连接起来的共享的组件上，当我们去提升系统负荷时，共享的开销和新增加的成员之间的协调性有关，用以上例子解释，当我们6辆卡车行驶在路上，路就是共享资源，也就成了约束条件，这条路上适合跑多少辆卡车。如果再看我们的水平扩容的网络开销，网络其实是各个系统的共享资源，当你我系统增加更多的节点时，共享资源的负荷也随之增加，为什么数据库是最边缘的呢？因为数据库是共享资源，绝大部分系统都只有一个数据库，或者只有一个主库，
3.对数据库的扩容
读操作扩展：
假如网站是读操作比较多，比如博客这类，那么通过mysql进行垂直扩展是个不错的选择，并且结合memcathe、redis、CDN等构建一个健壮的缓存系统。如果系统超负荷运行，将更多的数据放在缓存中来缓解系统的读压力。采用水平扩容没有太大的意义，因为性能的瓶颈不在写操作，所以不需要实时去完成，用更多的服务器来分担压力性价比太低。所以针对单个系统去强化它的读性能就可以了。
写操作扩展：
假如写操作比较多，比如大型网站的交易系统，可考虑可水平扩展的数据存储方式，比如Cassandra、Hbase等。和大多数的关系型数据库不同，这种数据存储会随着增长增加更多的节点。也可以考虑垂直扩容提升单个数据库的性能，但会发现资金与硬盘的IO能力是有限的，所以需要增加更多数据库来分担写的压力。
所以，针对应用场景使用什么样的扩容要仔细斟酌。