开发者学堂课程【Java 面试疑难点串讲 4：Java Web 开发：集群设计那点事】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/27/detail/1219
集群设计那点事
一、集群设计
只要是从事 java 的项目开发，那么所遵循的基本原则就是 mvc 设计模式，那么可以思考一下再哪一块会出现问题。
从一个正常的开发的流程来说，最终不管后台经过了多少道处理，那么前台都要进行显示不受限制以及迅速反应才是整个开发中必须要解决的问题;
控制层只是进行内容的接收，验证 vo 转换，业务调用，控制层只是一个导向(业务分发)，从 ajax 的时代开始应该使用 json 让控制层处理更加的容易一些，这样就产生了 restful 架构设计;
业务层需要进行的是业务处理，需要调用一堆的数据层开发程序，所以业务层如何可以简化，如何可以更高效为控制层服务或者是为用户服务是一个关键问题。
数据层需要解决 vo 转换以及速度还要快，不能都进行数据库的操作，因为数据库是瓶颈。如果从最基础的开发要求来看，首先有一个服务器 Webserver，专门做用户处理，做完处理之后，有一台专门的服务器，服务器跑数据库，这样的过程之中，数据库就能进行更有效的处理。用户发送信息给 Webserver。图示如下
这种架构之中,没有考虑特别复杂的操作形式，因为并发数据量少。网站不仅仅被用户访问，还被机器所访问，在整个处理过程之中，用户并不多。从本质效果来说，现在的代码在人少的时候，能够满足要求。配置有 1g 内存加 5g 的数据盘和 20g 的系统盘，这只是一台服务器所能实现的。
需要集群的理由是：
造成整个的开发瓶颈的最大问题在于数据库操作非常缓慢。正常流程中，所有的项目操作流程几乎都会按照一种固定的模式运行，从数据层到数据库，一个项目中有一个数据库，数据层之后还有业务层和控制层。
目前要执行一个功能控制层，能够给予最大的操作形式就是用户的数据交换。如果用户要进行操作，就必须将用户请求发给控制层，控制层将用户的请求进行处理。
0 控制层接收到请求之后调用相应的业务层进行处理，业务方法中牵扯到业务层中的业务接口。业务层接口最终结果要调用数据接口，在处理当中，一个业务接口要调用许多个数据接口，做一个复杂查询，可能同时要查 20 张表。数据接口会去调用数据库，不管如何处理操作，数据层执行完成之后，这些操作都返回到业务接口，而后业务接口再将数据处理，于是这些数据真正发回给控制层，控制层，再把数据发回用户。图示如下
如果这个时候用户量暴增，所有的业务复杂操作就都会影响到用户。如果做抢购的时候，所关心的一定不会是商品数量减少，商品的订单增加，所关心的问题只有一个就是是谁能抢到。如果只是简单的抢夺，只需要做一个订单的记录即可。由此可知，数据库的查询性能直接导致项目可能出现问题，那么基于以下考虑
大型数据库贵，所以只能使用 my sql。
应该多准备数据库，数据需要同步。处理准备两组数据库进行改进，是简单的主从操作，相当于从一个人干活，升级到两个人干活。从相当于做备份，因为在数据量过大时，不能够及时做备份，从服务器此时能够给予主服务器支持，数据层加快。
但是如果这样开发，又会产生一个新的问题既然都有两台数据库都做查询有点浪费，我们认为应该将更新操作也分摊一下。
准备三组 mysql，此时包含六台服务器。如果六台服务器都进行读操作，会浪费资源，所以可以往里写数据。假设项目里只有三类数据，需要平均分配到不同表中， 所以会有一台专门的服务器进行分配。用户只关注能否取到数据，不关心如何存储数据。mycat 组件做读写分离，由 mycat 去维护所有能够见到的主机，将数据平均分配。用户不关注服务器有多么复杂的组成，只需要知道通过一个专门的服务器，用户就可以读到数据。这个过程按照传统 jdbc 使用，代码操作比较迅速。
进行集群设置，仅仅因为建立数据库昂贵。即使再将数据库的服务搭建更加复杂，实际上最终也只是对于整个项目的提升不能得到特别大的改善，因为它的读写仍然较慢。如果现在有需求，每秒钟要求可以读写达到 10 万次。如果使用 mysql 就会很慢，所以如果要进行数据高速读取，就会出现 nosql 数据库 (MongDB、Redis)。
用户按照正常操作发出请求，依然要寻找控制层，业务层，数据层。数据层之后是关系型数据库集群，通过集群能够得到较大提升。当前架构如果只是做简单开发，一定能满足需求，能保证项目正常进行。但关系型数据库集群很慢，于是又加入主从，用 redis 集群控制。用户读数据一定需要通过控制层读取，但不应该通过传统的业务层读取，应该通过集群读。 此时诞生组件 codis，该组件负责协调 redis 集群。以上操作。能保证高速读取读写频率每秒钟 10 万次左右。
此时还存在问题，控制层只有一个。所以就算后面读取很快。但是控制层无法承担，相当于后台的数据，可以按照每秒 10 万次的读取，但是控制层每秒只能处理1000 个用户。于是会发现所有的问题都卡在了控制层的性能上，于是就继续建立一个 tomcat 集群。
用户需要正常进行访问，需要通过 web 访问，但 web 中并不是唯一的，有很多个web，每个 web 之中都有独立的处理关系型数据库集群的能力。项目很大的情况下，准备多个 tomcat，但平时用不到多个服务器，所以存在 5 台备用，15 台主用。在该过程中，用户操作较为简单，只需要输入网址。但是还需要将用户请求进行分摊。并不是一开始就进行处理操作，先进行分摊处理，如此就可以完成控制层操作分担。在整个操作过程中，以下集群可以做高效操作。
对业务层控制层数据层进行合理处理后，还可以对业务用 RPC 进行拆分。假设办公中存在很多系统，人事子系统，仓库子系统，行政资源子系统内部办公资源子系统，这些系统之间能够进行相互调用，形成另一套集群,此时可以形成一套完整的 rpc 框架。但又存在一个问题。
如果进行图片或视频信息的存储，那么空间会占用较大，实际中可以运用图片视频服务器进行处理。
无限扩展系统之后，用户调用图片时可直接从 tracker 中读取。以下专门对于图片进行处理的子系统。
在整个系统划分之中，如果要采用大数据的分析处理，这个时候又需要构建大数据的分析系统。
大数据分析如下，在大数据分析之中，最重要的就是用户数据采集，通过一套消息中间件行为把操作发送，这些消息中间件形成一套消息集群。
集群之间正常调用，保证操作性能。将用户零散数据发送到消息中间件，此时存在消息分析系统。
之后存在 storm 集群，内存需要非常庞大，64g 以上为宜。还需要对数据进行零散数据分析，又存在一 个 hadoop 集群。hadoop 都会向关系型数据库中直接保存。
会将用户信息存存到缓存数据库集群中，以便下次调用。结构如下
但其中的关键是 zk。
此时再进行正常开发时，需要的服务器较多。如果要构造完整的集群开发模式，用户轻松上网，能够接收到用户的处理行为的是一台 nginx，以下对应许多 tomcat，第一区域是用户能够直接访问的一套完整区域，第二区域是真正处理服务的集群过程。
在该集群当中，在整个处理过程之中，两者之间可以做访问处理。
Tomcat 之后有许多远程服务集群，提供别样服务。 仍然牵扯到关系型数据库集群，还需要缓存集群。
该流程结束后，还需要消息集群并牵扯到大数据集群。消息集群都会给大数据集群做开发，还存在一个图片集群。图示如下。