javaweb模型

 声明：本文中的数据和资源两个词完全等价，本文中有大量逻辑包含关系，经常出现的是大概念和小概念偷换，望见谅。

动态和静态：这是一个不新鲜的问题。我准备用新鲜的例子去解释。

我有一个需求，我想要得到圆周率小数点后一亿亿亿亿位的数据（忽略除运算条件外的其他条件），因为我的计算机运算能力不足所以我需要一台算力更优秀的电脑去运算并将结果获取过来。但是我们知道随着运算的深入这个结果是有可能发生变化的，其变化不取决于我的电脑，而取决于提供数据的电脑，像这种数据的提供取决于在“非我电脑”上的现象，我们称之为动态。再比如你的账号数据不能在你自己的电脑上修改，这是因为数据存储于其他电脑的数据库。静态反之。

因为资源在质与量方面的差异，以及电脑用户对资源质量的追求，通过网络获取动态资源的必要性和紧迫性与日俱增。电脑接入网络（以太网，广域网，局域网.....）变为连接设备，有开放的连接设备的称为服务器（服务器是个相对概念），请求方为客户端，响应方称之为服务器。

动态数据传输通道——动态数据传输需要通道：

1、网络：现在的网络质量都不算太差，太差的网络会导致各种问题，比如丢包，重连等，这一层由运营商代理，该通道不能存储数据，除非提供中介服务器。

2、内存：现在的内存传输效率也不低，但不能存储数据，只能运算数据。

3、硬盘：分为固态硬盘和机械硬盘，随着技术的提高，固态硬盘容量越来越大，数据读写效率也有极大提高，质量也越来越好，最重要是缓冲区得到极大拓展，但仍然是CPU效率瓶颈。

动态数据传输通道路线：

请求：客户端硬盘（读取数据）→客户端内存（封装需求）→域网络（请求）→服务端内存（解封需求）→服务端硬盘（写入数据）

响应：服务器硬盘（读取数据）→服务器内存（封装服务）→域网络（响应）→客户端内存（解封服务）→客户端硬盘（写入数据）

这个是一个闭环传输通路，其实只要能够构成一个闭环传输通路，任何数据都能够成为动态数据。

有以下至少三种选择：

域网络（请求）→域网络（响应）→域网络（请求）这就是一个最简单的动态数据通路，只不过这个数据只在域网络中传输，也有这种情况的使用比如DOS里的ping命令用来验证网络可达性，也就是所谓的延迟。

客户端内存→......→服务器内存→......客户端内存 这是一个持续型动态数据通路，这个数据在内存中运行，比如说远程连接，在线视频通话等。这也就是为什么远程吞吐量极大的原因，本身远程获取来的数据没有条件也跟本不可能存储到硬盘里。

客户端硬盘→......→服务器硬盘→......客户端硬盘 这是一个应用最广的动态数据通路，客户端和服务器都有硬盘资源，客户端可以（不）上传任意的量的数据，服务器可以（不）响应任意量的数据，客户端可以（不）下载任意量的数据，由此最大程度的控制了动态资源的任意性。

其他选择：

客户端内存→域网络→客户端内存，命令服务系统，dos窗口的小程序等。

客户端硬盘→域网络→客户端硬盘，文件服务系统，对单硬盘文件的读写操作，两个硬盘文件的拷贝等。

数据资源的任意性：

①、客户端有可能向服务器上传不可预计质量的数据（比如超量数据、恶性数据、非请求规范数据）：比如明码、木马脚本等

②、服务器有可能向客户端响应不可预计质量的数据（比如超量数据、恶性数据、非响应规范数据）：比如捆绑软件、木马脚本等。

③、客户端有可能向数据库存储不可预计的质量数据（比如超量数据、恶性数据、非存储规范数据）：比如爬虫、磁力链、其他系统软件等。

动态数据传输通道的实现：

我们只说最长的通道，因为本文讲的就是最长通道实现的方式——javaweb。

域闭环传输实现。接根网线，可以是通往各种域的网线。我们这里选择了通往本机的网线，IP地址是127.0.0.1或localhost，tomcat软件服务器端口8080，数据流可以通过。

内存闭环传输实现。开启谷歌浏览器。编写java文件，通过数据流向页面输出数据。

硬盘闭环传输实现。我们不上传数据（上传0量数据），通过设置请求服务的URL，通过数据流请求数据，java获取请求数据，java连接数据库，获取定量数据，通过数据流响应数据，我们不下载数据（下载0量数据）。

综上分析，tomcat和浏览器共同集成了对于数据流的域闭环传输和内存闭环传输以及客户端侧的硬盘闭环传输。这样的话服务器只需要专注于自己的硬盘闭环传输问题就可以了。

服务器端硬盘闭环传输问题：

域请求（响应）处理，这个处理都是在HTjava中执行的，一般意义上的大数据吞吐量没有问题。

内存——硬盘通路处理（javaweb的核心），这个问题说简单点就是内存到硬盘的传输效率问题，也叫做数据持久化问题。

java的代码是在内存里的，比如Array、LIst、Map这就意味着在这些容器中存储的数据都是临时的，重启java程序之后数据进入新的生命周期。这种程序也有，比如计算器——本质上是只使用程序的计算代码，属于基本功能。

但是要对存储的数据进行持久化，则需要使用存储于硬盘的文件，比如txt，properties，json、xml、sql等，java的io类等提供了对这些文件的操作接口。

一种文件类型是否适合存储数据要看多方面表现的情况，txt存储数数据没有统一规范，所以不适用，properties、json、xml存储数据有统一规范但是由于缺乏构建庞大复杂数据和数据处理的算法特点，所以不适用。

sql凭借优秀的规范进入数据持久化的行列。我们使用mysql举例，他的默认端口是3306，java程序通过这个端口和mysql提供的连接接口实现了数据持久化，这样一个服务器端硬盘闭环传输问题就从逻辑上解决了。

我们的研究定位到了javaweb模型图右下角的mysql模块，从这里是构建javaweb项目开始，根据模型我们看到了下一个环节。

此时，还需要一个输入和输出的载体，java提供了awt和swing来完成它的图形化，但是由于使用过的人说很不好，所以没使用过的人也就对它不理睬了。

到此刻已经是一个局域网内的C/S架构的软件了，只要他们配置的是同一个数据库，他们就可以实现数据的共享和操作，这类软件太多了，几乎都成了规模化生产了，像什么各类的管理系统。

去掉javaGUI，我们继续看图。tomcat提供了servlet，你需要开启tomcat服务器，这个服务器的端口是8080，我们这个时候仍然需要一个用于表现的载体，说白了就是如何让html文件和java文件联系起来。

启动tomcat之后可以看得出来localhost:8080打开的网页实际上是这个网页（index.jsp），按照链接规范原则上我们可以访问该目录下的所有开放资源。

我很抱歉我把图片顺序弄得一塌糊涂，但就是这个意思。实际上这种访问我们不通过tomcat也可以实现，你只需要在同级目录下创建一个html5文件和json文件并使用超链接访问即可。那么使用tomcat的意义在哪呢？

就像我们刚才说的重点在于实现html和java文件的联系http发布一个请求这请求是一个路径，由于这个请求是在tomcat服务器内发生的，tomcat服务器提供了一个路径映射文件，通过路径映射文件去寻找开放目录下的class文件（被编译的java文件）并执行此文件。在执行之后，可以通过重定向去跳转其他页面，也可以通过输出流向浏览器输出数据(注意：输出的数据实际上是一个流文件，这个文件可以被很多浏览器解析，不同的浏览器对数据的表现方式不同，比如：谷歌浏览器会将数据纳入文档流，生成一个<pre>标签，这个标签的作用是预格式化)。

 

 

至此完成了javaweb B/S架构的整个运行过程。那我为什么要写出来呢，其实这些都是些不新鲜的东西了。因为有的时候路走的长了，总是要回头看看自己的原点在哪，知道自己原点的意义就是看清自己想要的东西。有的人刚开始学习编程就开始问，分布式怎么写啊，负载均衡怎么做啊，双11秒杀系统为什么不崩溃啊？说白了这些的东西产生的根源并不是大数据量所导致的，而是因为互联网巨头垄断形成的瓶颈效应，整个互联网的发展几乎就是大厂一宕机小厂就瘫痪，高度的依赖性使得各种工具都难以上下其手。所以不得不回到最初的原点去思考这些问题。对互联网的地位看法，国内还是普遍倾向于商业化认识，这种认识使得互联网不得不一步步的陷入一个又一个的发展泥潭。要解决这个问题又得去思考互联网背后的智慧根源，这种思考根本没有土壤产生。

回到正题：javaweb B/S架构我们来分析一下。

整体上根据 数据库、Java、Tomcat不同的作用，分别形成了持久层、业务层、表现层三层的结构，但是这样分的话会使得每一项技术越分越远，以此我们使用整体的眼光来看这三层的关系。

实际上java和mysql之间独立的读写是很轻松就能实现的，甚至说图形化了的mysql很大程度上就像是一个通用型软件系统，是什么需求导致的必须在java和mysql之间建立联系呢？首先数据库资源的相对有限，第二客户端需求的相对有限。简单来说并非所有的数据库资源都是用户需要的以及并非所有的资源都能被客户需要的，这样一来mysql就需要一个由数据特定关系操作形成的逻辑，这种逻辑经过规范整合成业务，这就是业务层的来源。

举个例子，登录业务的本质是查询操作，根据查询方式和结果的不同我们得到两种查询，值查询和量查询，他们的关系是：量查询是值查询的一个存在性判断，值查询也可以判断存在，但是其结果包含的其他内容对于业务来讲过于冗杂。登录业务的表象就是该账户信息是否在数据库中存在，而不是账户信息以何种类型存在，当然涉及到安全的业务必然要牵扯到账户信息以何种类型存在。

根据上述例子，我们会得到一个结论，数据的量操作和值操作的逻辑才是构成业务层的基础。量操作形成资源权限，值操作形成资源服务。这个时候也就解决了资源的两个有限性问题的，或者说这种解决本来就是天然的，只不过三层的关系使得其数据操作的实质越来越模糊（本文数据和资源两个概念可以等价）。

打个比方，增加和删除都属于量操作，数据增加（删除）的结果是该资源有（无）权限。查询和修改属于值操作，查询（修改）的结果是该资源有（无）服务。删除一条数据，该资源则无法获取。修改一条数据，该资源则进行更新。

根据前文我们知道，html与和java根本不在乎大数据量，java和mysql之间的传输对大数据量极度敏感，这样我们又回到了讨论服务端内存——硬盘传输通道的问题了，这其实就是大数据和高并发的问题其中之一。我们将这两个问题一起研究。

 大数据的问题是由服务端内存——硬盘通路引起的效率瓶颈，高并发的问题是由资源竞争引起的死锁。这两个问题用redis很大程度上能够解决，redis是单线程内存数据库，单线程解决高并发，内存解决大数据，但很多大厂更愿意去直接考虑更底层的硬盘数据传输问题解决办法，于是就出现了面试中经典的问题：如何用尽量少的时间去处理尽量大的数据的题目，很大程度上让你一方面展示你的钻研程度，另一方面白嫖你的知识成果，面试中开放性题目是最值得警惕的！

那么问题来了，博客的作用是什么？当然是帮兄弟们解决实际问题。

有的时候问题想的久了，就会变复杂，我们需要回到原点去思考这个问题，业务产生的本质。

产生：第一、数据库资源的相对有限，第二、客户端需求的相对有限。

举例：校长想要大一空航系三班所有女生的数据，但不幸的是校长花光了预算，程序员小王在自己工作价值内仅仅完成了mysql的部署并负责维护。校长找到小王，小王给了他导出一个Excel文件，但美中不足的是一但有新的女生来，校长又得去找小王更新，这就是数据库的时间有限性（其实就是动态）。校长想找别的系的女生数据，结果和前面一样又得去找小王导Excel，但小王烦了，他把所有的女生数据全部导了出来，校长却说，我只要一点数据，你给我这么大一个表干嘛？这就是客户端需求的相对有限性（其实就是权限）。为什么资源会产生这两个问题呢？这个问题说起来就涉及到经济学了，我本可以留下一句话——我有一个很好的解释，但是这里空太小了写不开。但我还是稍微解释一下：

动态和权限是资源的两个基本属性。动态意味着资源（R）作为有（e）和无（n）的主体，权限意味着资源作为是（p）和非（q）的的主体。

当R（e&p）资源为可持续主体，其余情况资源不可持续只能是持久的，这就是为什么可持续会导致诸多权限产生。——完全都是我自己想出来的。

计算机中的可持续意味着不断电，比如通电之后的计算机，文件服务和命令服务是可持续的，域通道在连接网络的时候是可持续的。

接着校长和小王的例子讲，由于校长的行为导致女生很不满意，于是所有的女生全部离开了学校。为了销毁证据，校长让小王将所有女生的数据全部清除。但是因为女生的离开，学校里的男生也都离开了，此时小王管理的数据库里啥都没有了，这就是资源本身所具有的生命周期特征。资源在某一个条件下可以存在，也在某一条件下消亡。生命周期接近尾声的资源称之为历史资源、无效资源或灰烬资源。

历史资源：在之前的特定时期内作为可持续主体，其中的权限属性逐渐脱离。

无效资源：该资源在任何时期内都不具备意义，权限完全脱离。

灰烬资源：资源经过大部分权限脱离，消耗几乎殆尽。

 到这里才是资源管理的开始，也是解决大数据和高并发的开始。

资源管理——资源动态和权限的管理：

资源管理现状：

①、资源任意化——硬盘上的数据本身是无差别的，硬盘本身不关心数据所带来的现实意义，而经过运算后数据被封装成任意资源：权限，信息等

②、资源规范化——经过某些规范使数据封装成权限资源：图片、视频等

③、资源自由化——数据生命周期失调，数据虚化严重：资源耦合，资源枯竭。

资管理理泛定理：

①、资源的数量和质量决定资源的生命周期，一般来讲资源的数量越大或资源的质量越高，生命周期也就越长。

②、资源数量的状态决定权限状态，资源数量越大生命周期越复杂。

③、资源质量的状态决定持续状态，资源质量越高生命周期越持久。

资源管理泛定理实例：

例一、压缩文件，将资源的数量降低为一单位，资源质量降低，生命周期缩短，整体资源只有删除和解压两个权限。生命周期简单，资源只能整体更新，或读取。

例二、