GigaHttpd 设计思想 0.2 版

原创 2009年02月04日 17:36:00

 

 

GigaHttpd 设计思想



版本:  0.2
提交时间:2009-02-05 (2008-10-15 开始写)
本版作者:鲁义明 (Yiming Lu) lu.yiming.lu@gmail.com
所属:  GigaHttpd 开发文档



* 先说实话

  这一版设计思想重点在如何实现,也就是要做第一个原型出来。跟上一版同样的,这个设计可能彻底不可行。不过没关系,虽然我很无知,但我会继续前进 :)

  这一版的原型包括 GigaHttpd 的代码,以及一个示例网站,可以让很多人(百万数量级)同时在一张纸上画画。


* 前言

  建议在看本文档之前,先看过前一版设计思想,即 0.1 版,可以简单的对整个系统有个初步的认识。

  本文是边想系统如何设计,边写出来的,历时四个月,大的思路没变,但后面小节的设计比刚开始的要详细一些。

  最后几个小节的详细内容不写了,因为影响也不太大,所以只留下了题目,备忘,后续版本再详细考虑。

  本版设计思想对开始写代码应该够用了,所以接下来会开始写代码(当然还有数据结构图、协议流程图以及程序流程图),随着第一个可运行版本的逐步开发,会继续修改完善设计思想,并在适当的时候发布。


* 系统结构总述

  在现在这个阶段(GigaHttpd 还太年轻),GigaHttpd 作为 Linux 的一个内核模块来加载。以后是否会彻底脱离 Linux,发展成一个独立的操作系统,留到后续版本考虑。

  所以 GigaHttpd 是一个内核模块,按照一般的内核模块来编译、加载。本文后续部分把这个模块简称为"GH 模块"。

  GH 模块加载后,首先准备好 GigaHttpd 系统的运行环境,然后启动 GigaHttpd 开始运行。整个启动过程类似 Linux 的启动。具体事务如下:

  (1) 准备内存空间。给 Linux 留下基本够用的内存页面。

  (2) 准备 CPU。给 Linux 留下一个 CPU core。

  (3) 准备网卡驱动,初始化协议栈。给 Linux 留下一个正常网卡,其余的都重新初始化成 GigaHttpd 的数据网卡。

  (4) 定位角色,接收计算任务,如果是整个集群中的第一台计算机,则初始化计算任务,并将自己设定成总协调人。

  (5) 加载静态数据。也就是所有的静态数据,从磁盘上,从复制子网获得,从动态的计算任务产生。

  (6) 加载计算任务。动态的计算任务,类似进程、线程的东西,从磁盘上,从复制子网获得,系统管理员上传。

  (7) 内部数据复制,以支持单个数据的大量并发访问。

  (8) 数据日志与备份。

  关于系统运行的监控与调整,我们可以分阶段实现多种监控方式。具体如下:

  (1) 通过 Linux 监控。这应该是最简单最直接的一种方式,在 Linux 与 GigaHttpd 之间通过内存页面交换数据,然后这些数据通过 /proc 来存取,就可以任意显示、控制 GigaHttpd 的运行状态。

  (2) 通过 web 监控。因为我们要实现的是 HTTP Server,所以 HTTP 协议的支持是最基本的。我们可以开发 GigaHttpd 的监控界面,通过浏览器来管理。这大概会是一个很长的过程。等到可以通过 HTTP 协议管理我们的所有功能的时候,旁边的 Linux 就是可有可无的东西了。呵呵,最近正在重新考虑什么是操作系统,是否以后可以不再支持 POSIX。


* 准备内存空间

  GigaHttpd 自己管理内存,即有自己的页表管理机制,不同于 Linux 内核。因为所有的物理内存页都会在两个系统内部映射,所以可以用一些内存页来交换数据。

  一般情况下,GigaHttpd 内部内存分配的基本单位是页。整页分配,整页回收。这个主要考虑我们的目标,是一个 HTTP Server,绝大多数数据内容都是静态存放在内存中,没有频繁的内存申请与释放。

  GH 模块加载后,取得系统中总物理内存页面数,减去给 Linux 留下的内存页面数,就是 GigaHttpd 的总内存页面数。

  GH 模块首先从 Linux 申请一些页面,用来构建页目录和页表。这些目录和页表准备好后投入应用,GigaHttpd 进入自己的内存空间。

  因为是 64 位的系统,所以我们有足够大的内存地址空间。

  GH 模块的代码,被映射到与 Linux 相同的地址空间,保证程序代码可以继续运行。但是所有 Linux 的内核函数,都不能调用了,所以对于基本的 C 库函数,在编译GH 模块时,要静态连接,同时要确保这些静态函数内部没有动态申请内存的代码。如果实在绕不过去,就写一个简单的动态申请内存的"壳"函数,这个函数在 GigaHttpd 内部真正实现。我们不准备重写所有的东西 :)

  多核系统的内存总线、北桥可能会是瓶颈,关于这个等待硬件厂商的升级吧。


* 准备 CPU

  本文所述的 CPU,仅指 CPU Core(下同)。

  为了性能以及系统结构简化,GigaHttpd 内部不进行 CPU 调度。是否将来进行 CPU 调度,后续版本考虑。

  所谓调度,是指一个 CPU 可以在多个进程、线程,或者计算任务之间进行切换,例如把不忙的进程、线程或计算任务挂起,然后切换到其他的去运行。

  GigaHttpd 的 CPU 只负责响应网卡的数据,然后做两件事情,一个是响应静态数据请求,另一个是响应动态数据计算请求,以下称作计算任务。

  GigaHttpd 的 CPU 负载在单个 PC 内部,以及整个集群内部进行均衡。均衡的主要思想是动态改变数据的分布,即静态数据,或者动态计算任务在多个 PC 上的分布,根据需要动态调整,以此来支持单个数据的大量并发访问(例如热点视频实时全球直播)。均衡算法留待详细设计时考虑。

  GH 的 CPU 所管理的内存相互间隔离,只通过共同的内存页面交换数据。

  GH 模块加载后,为每个 CPU 准备好页表页目录,以及 main() 函数和堆栈,引导每个 CPU 进入 main() ,并进入内部的循环。同时修改 Linux 内核的 CPU 数据,让 Linux 看起来只剩一个 CPU。

  因为不考虑多任务(多进程、多线程),每个计算任务结束后,如果产生静态数据(例如论坛的帖子),则静态数据转成长期的数据保存在静态数据区。其他运行过程中需要的动态内存,都应该可以被当作空闲内存而重复使用。所以,GigaHttpd 不提供 C 语言中基本的 malloc() 函数,而是 main() 函数中提供一块静态的巨大的内存来做数据缓冲区。根据自身的实际需要,计算任务的开发者自己考虑这块内存的详细使用布局。另外,从性能和编程方便的考虑,如果堆栈可以接受,则可以预留巨大的堆栈内存空间供计算任务来使用。

  关于动态计算任务中的漏洞(例如缓冲区溢出)导致运行未知代码,或者进而被黑客利用的问题,可以给每个 CPU 设置不同的内存空间,防止一个 CPU 出现问题影响到其他 CPU 的地址空间。关于漏洞被黑客利用,植入黑客代码,修改其他 CPU 的页表页目录,进而修改整个系统数据的问题,留待以后的版本考虑。如果这个问题上升到非常严重的程度,则可以考虑回到 Linux 的进程模式,这个问题是要在安全与性能之间作出抉择,尽管进程模式也可能被黑客利用。

  关于计算任务“僵尸”的问题,也就是动态计算任务代码存在 bug,导致 CPU 进入死循环。这个可以利用定时器来检查判断,或者另外设置一个“监控”CPU,或者 CPU 间定期互相监控,当发现一个 CPU 进入“僵尸”后,就对其初始化,之前把僵尸现场,包括计算任务记录下来,同时对此计算任务设置标志,阻止其再次进入运行状态。被阻止运行的计算任务应给用户浏览器返回错误提示,同时也给系统管理员发出报警信号,以此来辅助快速定位问题发生点。

  总的来看,GH 的 CPU “永远不死”,一直循环处理计算任务(静态数据/动态计算任务)。


* 准备网卡驱动和协议处理

  GigaHttpd 中 CPU 的唯一任务就是响应网卡的请求,返回静态数据(例如页面),或者先进行动态的计算任务,一般生成静态数据,然后返回给用户。本版设计中,为了系统结构简单,PC 中的网卡与 CPU 数量一样多,一一对应。同时,像 CPU 有一个留给 Linux 一样,也留一个网卡给 Linux,处理类似 ssh 这样的连接。后续的版本中,可以考虑 CPU 数量与网卡数量不一致的设计。

  另外,为了实现 PC 间的负载均衡,需要把一个 CPU(或一组 CPU)计算出来的静态数据,复制到多个 PC 中,所以需要一块“复制”网卡。

  这样,GigaHttpd 的网络系统可以分为三个独立的子网。一个数据子网,连接所有的“数据”网卡;一个复制子网,连接所有的“复制网卡”;一个网管子网,连接所有的 Linux 网卡。本版中,为了系统结构简单,三个子网在物理上独立。

  在支持 10 亿并发请求的系统中,有 1 千台 PC,数据子网的网卡大约有 1 万块,在这个子网中绝对禁止广播包。复制子网有 1 千块网卡,这个子网内大部分是广播包,后续版本可以考虑划分 vlan,在 vlan 内广播。网管子网有 1 千块网卡,这个是普通的 Linux 网络。

  GH 模块加载后,从 Linux(或者 BIOS)里取得各网卡的信息,留下一个给 Linux,把其他的网卡从 Linux 里卸载(或关闭),然后把每个网卡分配给每个 CPU。在此我们需要一些事先准备好的设置参数,指定哪个网卡留给 Linux,哪个网卡作复制,剩下的网卡都是数据网卡。由此,在本版设计中,我们需要准备一个配置文件,包含 GigaHttpd 启动的各种参数。以后的版本中,可以增加自学习的功能,让系统在启动时自动探测每块网卡属于哪个子网。

  数据网卡和复制网卡分配给每个 CPU 后,CPU 在自己的 main() 中循环读取、设置网卡的状态和数据。本版设计中,为了结构简单,不考虑使用中断模式来访问网卡。总体上来说,可能中断模式对网卡的整体吞吐效率没有什么帮助,只是对编程有很大的好处(另外可能还有省电环保),可以支持多任务系统。GigaHttpd 的 CPU 只专注于响应网卡的数据处理,没有多任务的需求。

  对于花费较长时间的动态计算任务,会造成网卡和 CPU 的“堵塞”,导致其他的并发请求响应缓慢。关于这个问题,一方面,从总吞吐量来看,中断一个正在运算的请求,保留现场,然后去处理后续的请求,并不能增加总吞吐量,所以采用中断处理意义不太大。另一方面,对于计算量很大的计算任务,例如几千万人同时参与全球环境治理模型的发展演变,仿真展现三维效果,则需要一定规模的 PC 群来进行集中计算。可以把用户提交的数据,翻译后通过数据子网转发到集中计算服务器群,然后等待一个复制子网的数据更新,将更新结果返回给用户。对于另外的应用类型,例如商品竞价买卖,计算可以分担在很多 PC 上,每个 PC 只负责少数几个商品的竞价撮合,这样这些集中计算的 PC 来给用户返回计算结果。

  所以在 GigaHttpd 系统中,接收用户请求的网卡和给用户返回数据的网卡可能不是一块网卡,当然如果这种情况发生,则这两块网卡很可能不在同一个 PC 上。进一步,GigaHttpd 内部的静态数据会支持包含关系,例如一个网站的新闻页面,既包含 HTML 内容,也包含 Javascript 代码和 CSS 代码,同时 HTML 代码中还包含了一些随时变动的信息,例如广告或者计数器之类的东西。当然这些变动的东西可以用 AJAX 技术来动态获取,但这会增加与网站的交互量,在为了提高效率的考虑下,GigaHttpd 可以把这些内容一次性打包的发给用户端,但是这些东西因为经常变动,在 GigaHttpd 内部是动态生成的,各部分都保存成独立的静态数据。所以 GigaHttpd 支持静态的数据包,里面是链接,指向各静态数据的内部地址。于是,在给用户返回数据的时候,就把这些静态数据包依次给用户发回去。但是这些静态数据包分散在不同的 PC 上,所以接收用户请求的网卡(以及CPU),会把这个请求依次转发给其他的网卡,其他的网卡依次把数据给用户发回去。

  再考虑一个类似的情况,电影。把整部高清电影当作一个静态数据显然不可取,另外也不是所有人都会每次都把整部电影全部看完,还有要考虑允许在电影中插入广告,所以把电影分段保存,应该是个好主意。

  当然这最后会产生系统内部复杂度,与客户端效率之间的平衡,实际应用中可以根据情况来调整。

  整体来看,静态数据包应该是躲不过去的。

  在静态数据包的返回过程中,整个 GigaHttpd 所有的数据网卡返回的数据包中的 IP 地址是相同的,对用户端是透明的。

  本版设计中,对于数据网卡,GigaHttpd 的协议处理程序只处理 IP 包,以及数据网卡间的转发包。IP 包包括 TCP 和 UDP 包。支持 UDP 是为了保留将来对网络游戏之类应用的支持。

  好吧,惭愧一下,根据目前的实际网络情况,本版网络协议只支持 IPv4,IPv6 留待后续版本实现。

  TCP 协议方面,初步实现 RFC-793。任何一块数据网卡都可以接收 TCP 连接请求(SYN包),对应的 CPU 接收后做基本检查,如目的端口、校验等,GH 根据检查结果返回响应(ACK包)、或者拒绝(FIN包)。如果检查通过,GH 申请一页内存,来存放 TCP 连接信息,包括客户端的 IP、Port、Sequence Number,以及连接状态,以及 GH 端的 Sequence Number 等。

  TCP 的端口事先记录在配置文件中,GH 模块启动时读入内存。运行中的端口改变通过广播子网来设定。

  客户端接收到 GH 的 TCP响应(ACK)包后,向 GH 的这块网卡发来第一个数据包,包含 TCP ACK,包内的数据部分是一个 HTTP 请求包的一部分。后续逻辑如下:

    检查 TCP 包,如 Sequence Number 等;
    if (检查通过) {
      解析 HTTP 请求,读取 URL;
      计算客户请求的对象(静态数据或动态计算任务)所在的 PC;
      if (对象在本 PC) {
        将此 TCP 的状态信息(包括客户端发来的 HTTP 请求),挂在对象的客户请求表中;
        调用响应的函数进行进一步处理,具体见后;
      } else {
        将此 TCP 的状态信息(包括客户端发来的 HTTP 请求),通过数据子网发给静态数据所在的 PC 的某块数据网卡;
        等到对方的接收确认后(异步等待),释放本地的内存页;
      }
    } else {
      向客户端发送拒绝(FIN包),并释放内存页;
    }

  如上,因为第一个 TCP 请求数据包要在 GH 数据子网内转发,为了高效率最好用一个以太数据包完成,所以 GH 给客户端的第一个 ACK 中的 Window 大小不超过 1K。

  对于要进行用户身份确认的应用,客户登录页面的信息要放在 URL 中发给 GH,而不是通过 HTTP POST 的 BODY 来发送。GH 接收后,会首先分析用户名等信息,如进行 hash 计算,然后将这第一个 TCP 请求发给用户信息所在的 PC 的某块网卡。在 10 亿用户的应用中,10 亿用户信息会存放在 400 台 PC 上,总共占用 4TB 的内存,在数据子网上有大约 4000 块网卡响应用户身份验证。用户身份数据与对象数据的分布优化留待后续版本实现。

  本版设计中,来自外网的 TCP/IP 包如何发送到准确的数据子网的目的网卡,由前端的负载均衡设备来实现。当然这要与负载均衡的设备开发商进行合作。GH 在明确了一个 TCP 的真正目的网卡后,通知负载均衡设备,此后负载均衡会根据客户端的 IP/Port 信息,以及 GH 的 IP/Port 信息,自动把后续的 IP 包都转发到特定的 GH 数据网卡。当然在一个 TCP 的连接完成之前,GH 端的目的网卡会发生改变。例如 GH 要把一个大尺寸的图片数据发送给客户端,开始的用户身份确认阶段是某一个数据网卡,而身份确认后,大量返回图像数据的阶段,是另一个数据网卡。

  本版设计中,TCP-SYN flood 攻击由防火墙设备来处理。

  本版设计中,以太网协议与 IP 协议只实现到可以支持 TCP 即可。

  UDP 协议支持留待后续版本实现。

  ICMP 只做最基本的实现,能够用于简单地测试网络联通。本版设计中,客户端并不知道是具体哪块数据网卡在回应 ICMP。

  本版设计中,SSL/TSL 由前端负载均衡来实现。


* 加载静态数据

  本节主要描述 GH 内部的数据分布与访问方式。主要挑战在于静态数据的快速定位,以及数据量的持续增长。

  静态数据的快速定位,就是如何快速找到用户 URL 所指定的数据,例如某个图像文件。GH 的静态数据全部存放在硬盘上,部分存放在内存中。GH 的静态数据直接通过内存地址来定位,也就是 URL 中直接包含内存地址,类似于 http://x.y.z./1111。

  静态数据既包括内容/页面数据,也包括用户数据。所以用户登录后,后续的 URL,无论是浏览器直接点击,还是 AJAX 访问,都类似于 http://x.y.z./1111/u222/sSSSSSSS,其中 1111 是页面数据的内存地址,222是用户数据的内存地址,SSSSSSS 是用户登录后的 Session。

  一个 Web Server 中的页面数据是从零开始增长的,注册用户也是从零开始增长的。

  静态数据的产生。无论是用户、网编,还是网管,向 GH 提交一个数据后(HTTP 协议),一个 GH 的动态计算任务将被启动。计算任务的计算完成后申请一个内存地址,然后将计算结果复制到那个地址。

  GH 的静态数据在内存中以 4M 为一个基本单位(下称数据块)来分布。也就是每申请一个内存地址都会得到一个边界为 4M 的内存地址。数据块都有一个标准的头部。保存一些基本信息,如数据长度,有效状态,数据的产生时间,最后一次访问时间,访问次数,校验和,授权码或者授权块的地址(用来设定数据块的访问保护),下一个数据块的地址,硬盘上的备份位置,TCP 的连接表指针(此数据正在向客户发送的所有连接状态信息),源 PC 信息(此数据是别的 PC 生成后广播复制过来的),等等。头部之后是实际的数据。

  如果单个数据的尺寸大过 4M,则可以保存成多个数据块。

  GH 内部每个 CPU 都有一个内存块链表,记录所有尚空闲的数据快区域。

  GH 的动态计算任务调用内部函数来申请数据块,函数参数中包含数据块的尺寸。该函数从内存块链表中取得一块或多块,然后根据实际需要的尺寸来映射物理内存页(物理内存页尺寸初步定为 4K)。也就是我们不会让博客或论坛中只有一个字的“顶”帖占用 4M 的物理内存。

  GH 中的数据可以被删除,删除后剩下的地址空间以后可以继续利用,物理页被回收。

  除非实在迫不得已,否则我们不会考虑支持任何 CPU 互锁的情况存在,因为我们支持超过 1 万个 CPU,超过 1 千台 PC。所以在申请内存地址方面,我们为每个 CPU 预先留下足够的内存地址空间。多亏我们是 64 位系统,呵呵。

  我们支持应用系统从一个 CPU 开始起步,这应该是最符合实际情况的做法。以后随着应用系统访问量、数据量的增加,再逐步增加 CPU/网卡,增加 PC;而且我们支持动态增加(热插拔);另外,在系统检修、排除故障时,我们要支持动态缩减 PC(如需要保证客户服务不中断,则需要在明确的内部数据复制指令完成后)。所以,我们一开始就为应用系统的最大可能数量的 CPU 们留下足够的内存地址空间。每个 CPU 的数据地址空间暂定为 4T(2的42次方),1 万(约 2^14)个 CPU大概会占用 64KT(2的56次方)的地址空间。

  一个数据块占用 4M 的内存地址空间,4T 可以容下 2^20(约一百万)个数据块。

  所以数据块的地址,由两部分组成,CPU 序号与 CPU 地址空间内的一个地址(怎么这么别扭,以下简称 CPU 内地址)。我们把一个 CPU 的序号用 cpu_n 来表示。

  数据块内存地址的长度为 56 位,以 4M 为边界,减去 22 位,还剩 34 位,不到 4.5 个字节,翻译成 16 进制字符串需要 9 个字节,格式如下:

    ........  54321098765432  10987654321098765432  1098765432109876543210
    [ 8 bit]  [                          56 bit                          ]
                [   14 bit   ]  [       20 bit     ]  [      22 bit        ]
                [  CPU 序号   ]  [     CPU 内地址     ]  [    边界,省略        ]
                [          数据地址,34 bit          ]

  数据块地址在 URL 中可以采用省略写法,用冒号分隔 CPU 序号和 CPU 内的地址,格式为: cpu_n:xxxx。

  本版设计中,我们给每个 CPU 分配 1GB 的物理内存。随着数据量的增加,一个 CPU 的地址空间内数据总量接近 1GB 的时候,CPU 将最老的、访问次数最少的数据从内存中丢弃(之前已经备份到了硬盘上),回收物理内存,进行重新分配(映射)。

  所以,一个应用系统规模逐步增加过程中,GH 内部的数据分布变化大致是这样的:

  (1) 某个公益/商业创意团队发布自己的一个应用网站,只有一台 PC,双网卡,2G 内存,一个双核 CPU,GH 用其中的一个 CPU Core,这个 CPU 接收到的用户数据都保存在 4T-8T(4T 以下保留给系统)的地址空间中,并且数据被备份在硬盘上。

  (2) 随着访问用户的不断增加,提交的数据越来越多,达到几百 M 或者几个 G 的时候,团队新增一个 PC,四块网卡,4G 内存,一个四核的 CPU。启动“上线”命令后,GH 自动把在第一台 PC 上的大部分经常被用户访问的数据都复制到第二台 PC 的内存中,此后两台 PC 共同给用户提供服务。所以第二台 PC 内部的内存中,在 4T-8T 的地址空间中,保存着第一台 PC 的“热点数据”,这样用户访问以前的数据(指定了内存地址)就可以均衡到两台 PC 的 4 块网卡/4个 CPU 上。第二台 PC 上的 3 个 GH CPU 新接收到的用户数据,就会存放在 8T-12T/12T-16T/16T-20T 的地址空间中,并且备份到本地硬盘中。当然第一台 PC 新接收的数据,还会放在自己的地址空间 4T-8T 中。

  (3) 此后两台 PC 的热点数据会继续互相复制。另外,在 CPU 的空闲期,两台 PC 将对方的全部数据都备份到本地硬盘中。以此来保证一台 PC 突然故障后,另一个 PC 可以实时接管所有的用户请求。具体硬盘的数据备份如何恢复到内存中来见后。假设是第一台 PC 发生了故障,那么第二台 PC 中的 GH CPU 接受的用户数据继续保存在自己的内存地址空间中,即不再写如到 4T-8T 中。

  (4) 假设第一台 PC 故障后无法修复,团队又增加了一个新 PC,4G 内存,四块网卡,一个四核的 CPU。启动上线命令后,GH 自动把 4T-8T 的数据全部复制到第三台 PC,这样第三台 PC 的内存地址分布为 4T-8T/20T-24T/24T-28T。第二台 PC 的热点数据也会复制到第三台 PC 上,实现负载均衡。

  (5) 以此类推,可以不断地增加 PC,然后不断地摊匀热点数据,比如首页、爆炸性实时新闻、热点视频直播等,可以在每个 PC 的内存中都进行复制。以此来应付访问量的持续增长、热点数据的不断变换。

  (6) 数据量积累方面,当一个应用系统的规模从一台 PC 增长到一千台 PC 的时候,最早的第一台 PC 上的数据可能积累得最多,有可能会占满 4T-8T 的内存地址空间(因为哪怕再小的数据都占用 4M 地址空间)。关于这个问题,后续版本会考虑内存地址复用来解决。原因很明显,很多数据在网站保存后,后续的访问量非常小,比如一年前的新闻报道、两年前的时尚杂志内容、三年前的电子商务交易记录明细、某个糊涂鬼忘记密码后留下的信箱邮件以及博客文章,等等。为此类很长时间不访问的数据保留唯一的内存地址空间,显然不太合适,我们只要支持在很多年后,如果有人来访问,能让这个数据再次从硬盘上被找到,重新读取回内存即可。

  (7) 每台 PC 的数据都在相邻的 PC 里做硬盘备份,以减少系统的运行风险。

  本版设计中,还需要考虑一个实际情况,针对目前主流的 4 核 CPU 系统,中小型应用中,单独拿出来一块网卡来做复制子网可能不划算,那就先在数据子网中做数据复制,尽量少用广播包。

  本节最后,简单设想一个应用,一个不超过 60 个 CPU 的中小型应用,例如一个很多人参与的 web 游戏,每个 CPU 有 1G 物理内存,假设每个数据(虚拟城市)的实际平均尺寸为 1M,则每个 CPU 理论上可以支持约一千个城市。但是用户数据也是要占用内存的,假设每个用户的数据占用 1K,每个 CPU 如果支持 10 万个用户同时在线,则同时在线用户数据会占用 100M 的物理内存。剩下 900M,去掉系统可能占用的基本内存 100M,每个CPU 应该还可以支持 800 个虚拟城市。假设热点城市占总城市数的1/3(热点城市数据会在多个 PC 内存中复制),则平均每个CPU 应该可以支持超过 500 个虚拟城市。所以整个系统应该可以支持 600 万用户同时在线建设一个有 3 万个城市的虚拟星球,呵呵,在此基础上可以进一步展开各种气候、生态、商业等等创意。如果同时在线用户与总注册用户的数量比例是 1:3 到 1:5,那么这个系统应该可以支持 2000 万到 3000 万注册游戏用户。

  60 个 CPU,需要 20 台 PC,每台 PC 配备一个 4 核 CPU、4G 内存、几百 G 的硬盘。按照 2008 年的电子市场行情,PC 总价应该不会超过 20 万元。呵呵,性价比有些不真实,还不知道哪里计算失误了,不过没关系,幻想/梦想就是动力,我们继续前进。


* 硬盘数据备份

  本节主要描述 GH 内存中的数据如何备份到硬盘上,以及如何读回内存。

  动态计算任务产生静态数据后,存放在了内存中,之后应该及时在硬盘上作备份。内存中的静态数据是以(连续)数据块的形式存储的,有一个唯一的内存地址,还有很多附加信息,如相关日期、访问次数、授权信息等等。这些数据保存在硬盘上也继续采用这种格式。为什么采用这种格式,而不采用像 ext2/3 之类的传统文件系统格式?举个例子,对于视频网站这样的应用,一旦有一个用户开始从头播放一个数据尺寸几百 M 甚至几个 G 的电影,我们如果立刻把整部电影都读入内存中,显然不合适。另外,用户可能从影片的任意部分开始播放电影,所以我们应该支持读入任意一个数据块。

  本版设计中,每个 CPU 在硬盘上都拥有一块自己的“独立空间”,避免访问时产生互锁问题。本版设计中,为了设计简单,每个 CPU 的“独立空间”就是硬盘上的一个逻辑分区。每个 CPU 在内存中拥有 1GB 的物理内存,按照 1:50 的比例,每个 CPU 的逻辑分区大小 50GB,实际应用中可以根据硬盘容量及网站数据量进行调整(在网站系统的规划阶段)。这样,一个 4 核 CPU 的 PC 中,硬盘上有 150GB 空间应该保留给 GH。另外,GH 会把每一个静态数据在相邻的 PC 上备份,这意味着每个 PC 上还可能要保存邻居 PC 上的 150GB 的数据。所以,在这个 PC 初始化时,应该在硬盘上保留超过 300G 的空闲空间。

  现阶段的一个中小型应用,60 个 CPU,每个 CPU 保存 50GB 的数据,总共可以保存 3TB 的数据。如果应用中需要保存大量数据,例如邮件系统,则可以增加每个 PC 上硬盘的容量与个数。

  GH 中,每个上线后的 PC 都有一个自己的序号,并且与系统中的其他所有 PC 自动商量,与一台或若干台 PC 建立数据备份约定(根据每台 PC 硬盘中的空闲空间而定)。

  数据块在硬盘上的存储,以簇(10KB,20 个扇区)为基本单位。内存中的数据块,头部记录其在硬盘上的起始簇的位置,如此有助于数据块内容被修改后及时同步。

  在 CPU 逻辑分区的开始部分(头部),预留一块空间用来记录该分区内所有数据块信息以及簇信息,簇信息里有指向硬盘扇区的簇指针。一个大数据块存放在多个簇中,所以簇信息里也包含下一个簇的指针。数据块信息的长度初步定为 128 字节,簇信息的长度也初步定为 128 字节,可以包含数据块的更多附加信息(预留)。

  本版设计中,为了简单,CPU 逻辑分区中的空间一直“向后使用”,到达尾部后再回到头部继续。即,每次要向 CPU 逻辑分区写入一个数据块时,总是写在分区内的数据尾端,而不考虑利用分区中数据块被删除后留下的空白簇。这些空白簇会在下次循环回来后再次被使用。这种方式也有利于支持 U 盘。

  本版设计中,同样为了简单,数据块信息空间也一直“向后使用”,但不循环。本版设计不考虑数据块地址的复用,所以数据块地址是一直是持续增长,因此,在硬盘上的数据块空间内的数据块地址都是从小到大排列的,当然一个数据块被删除后会留下空洞。当数据块空间使用达到最后时,CPU 专门整理一次这个空间,从前向后去掉空洞,以便容纳新的数据块。

  CPU 逻辑分区也有一个头部,存放剩余簇数、簇顶端、剩余数据块空间、数据块空间的顶端等信息。

  在给定一个数据块内存地址后,如何从硬盘上快速找到这个数据块,则利用数据块空间的顶端这个数据,进行折半查找。

  CPU 逻辑分区内的各种优化,以及与 DMA 相关的各种优化,留待后续版本。

  GH 内部的数据之间的联系,主要通过数据本身来记录。解释一下,比如 GH 内部大量存储网页,每一个网页都只能通过其他的网页中的超级链接(内存地址)来找到;再比如一个商品交易网站,每个商品通过一个商品代码(内存地址)来找到。

  类比一下,目前记录数据之间的关系主流方式有文件目录、数据库、全文检索这三种方式。文件目录支持遍历所有目录,找到所有数据。数据库支持 SQL 语句,可以找到所有数据,当然还可以作统计。全文检索支持按关键字搜索数据,但不一定能找到所有数据。

  本版设计中,暂不支持以传统文件目录方式来访问一个硬盘分区内的所有数据,但可以提供简单浏览功能,如在“一个目录下”列出来硬盘上所有的数据,还可以包括数据类型,比如是图像、博客文章、商品、交易记录、游戏装备、NPC 怪物等等。

  本版设计中,支持将硬盘上一个 CPU 逻辑分区内的数据,复制到 U 盘中作为备份。备份出来的数据,需要的情况下,可以从硬盘中删除,例如超过若干年的商品交易记录、财务数据等。

  本版设计中,不支持对所有数据采用 SQL 语句的访问方式,也就是不支持任意的数据排序、统计、约束关系等。原因很简单,对存在于一千台 PC 的硬盘中的数据进行任何排序或统计,都可能花费太长的时间,而且在排序、统计中一旦锁定所有数据,则可能会严重影响性能。

  本版设计中,如果需要对整个系统中的数据进行深入分析,包括任意排序及统计,可以基于备份出来的 U 盘上的数据来进行。

  本版设计中,数据间的约束关系(类似数据库内数据表间的约束关系),由动态计算任务自行维护。例如网管删除一个博客用户,动态计算任务负责删除其名下的所有博客文章。

  本版设计中,对于应用中所必须的排序与统计,在动态计算任务内“逐步积累”,也就是事先设定好排序与统计的算法与存储空间(数据块),没增加一个数据,动态计算任务就更新排序索引,以及统计结果。例如,对于一个在线商品竞价交易所,每撮合成一笔交易,就累加进当日个人与交易所的总成交额;如果应用中需要统计当日交易额的前一百名用户,则交易成功后判断并更新每个 CPU 下的前一百名记录。假设整个系统有 500 台 PC,1500 个 CPU,每个 CPU 管理 100 种商品,总共管理 15 万种商品;每个 CPU 管理 10 万在线用户,总共管理 1.5 亿在线用户( 5 亿注册用户)。这种情况下,计算任务可以定期每 10 个 CPU 将自己的前一百名记录发给某一个 CPU 进行排序,得出这 10 个 CPU 范围内的前一百名。以此类推,经过四轮,就可以定期的得到整个交易所的交易额前一百名用户,商品交易额统计、商品逐级分类统计等也可以如此。

  全文检索留待后续版本实现。


* 普通用户

  GH 中的用户分为系统用户(系统管理员帐号),与普通用户(网站的注册用户)。本节中“用户”均指普通用户。

  系统用户帐号信息与普通用户帐号信息在 GH 中都以静态数据块的形式存在,都有一个静态内存地址。

  应用程序中的用户,无论分多少级,GH 都按普通用户对待,应用级别用权限来标志。例如一个有很多层级的论坛,每一级用户权限由权限码来设定。

  如果应用中需要给用户分“组”,则“组”信息也是静态数据块。用户与组之间的数据关系(一对多/多对多)由应用程序(动态计算任务)自己维护。例如每个用户可以有很多“好友”,所以每个用户可以有一个“好友组”;每个用户可以属于很多圈子,圈子在内部也可以设计成组。

  本版设计中,仅支持用户通过用户名和密码来登录。为了安全,用户名和密码不放在可见的 URL 中提交。

  如何避免注册用户重名是个麻烦问题,因为我们可能有 1 万个 CPU 同时接受用户注册,不可能在任一时刻锁定所有 CPU 的内存;而且我们支持超过 10 亿用户,即使每个 CPU 维护一个用户名索引,内部查找的负担也很大。所以,本版设计中,一个用户注册成功后,GH 自动给用户名后面增加一个字符串表示的内存地址,格式如“-cpuid_CPU内地址”,cpuid 和 CPU 内地址合计最长 9 个字节。所以一个用户名的将变成类似“张王李-1234_12345”,优化一下,我们用一个 CPU 的名字来代替 cpuid,所以结果就类似“张王李-黄山12345”,“黄山”是一个 CPU 的名字。反正我们要在每个 PC 内部保存一个所有 CPU 的列表,因此给每个 CPU 增加一个名字(及索引)不会增加多少负担。此种方式下用户注册时肯定不会重名了,呵呵。

  但是,显而易见,无论如何优化,这种命名方式还是很难看的。其实问题的本质是解决名字字符串与一个内存地址的对应问题,分布在很多个 CPU 上。我们可以设计一个标准的接口,允许应用程序开发人员可以自行设计替代函数,实现更好的对应关系,和更快速的增加/查找方式。

  用户密码保存成原文,还是一个校验和,支持由应用开发团队来决定。

  用户产生(提交)的数据,与用户帐号数据都尽量保存在同一个 CPU 的数据空间内,减少 CPU 间的跳转。例如博客的作者与文章、网店的老板与商品等。

  用户登录验证通过后,随机生成一个 Session,长度 32 位(8 字节长的字符串),记录在用户的帐户信息内。本版设计中,用户的帐户信息内可以放置 10 个 Session,也就是允许一个用户帐号最多同时从 10 个客户端登录,例如用户可以同时从电脑、汽车、手机、卫星定位器、人体植入装置等设备中同时登录自己的帐户,开展应用。

  为了快速解析,Session 放在 URL 中来传输(避免使用 cookie)。

  10 个 Session 位置循环使用。每个 Session 可以设定任意长的过期时间。

  GH 支持在任意客户端界面上使用图形验证码。GH 的每个 CPU 都在自己的内存空间保存 100 个验证图形,需要使用验证码时随机从其中选出一个来使用。每个验证图形都有生命期,一分钟。

  对于探测用户名、密码、图形验证码的行为,GH 会锁定帐户及客户端 IP 地址一段时间。


* 普通用户的权限

  用户的权限,也就是用户与静态数据之间的关系。

  静态数据在其头部记录拥有者的ID,也就是用户的内存地址。

  静态数据在其起头部记录读写权限标志,64 位,每两位代表一个标志,共 32 个标志。两位标志中,前一位代表是否必须遵守,后一位是标志。本版设计中,支持 5 种标志:不保护、拥有者读写、读取授权函数、更改授权函数、删除授权函数,其余的标志位留给应用程序去发挥。

  “不保护”的数据任何人都可以读取,但只有拥有者可以更改/删除。例如网站的新闻,谁都可以看,但只有上传者可以更改。

  “拥有者读写”的数据,顾名思义,只有拥有者自己可以读取、更改、删除。例如博客中的个人私密文章,资金帐号中的信息等。

  设置了授权函数标志的数据,其头部还要记录对应函数的内存地址。例如一个数据设置了读取授权函数,当某个用户读取时,GH 发现其不是数据的拥有者,于是调用此函数,函数入口参数包括拥有者ID、读取者ID、数据ID,函数的返回值指明是否可以读取。这个函数可以由应用程序开发团队设计,这种模式可以支持复杂的数据间授权关系,例如好友,圈子,等等。

  举个例子,网站中的一则新闻,新闻内容由某个编辑提交,在新闻正式发布到网页之前,这个编辑就有所有读写删的权限。这篇新闻被上一级编辑审核后,当初发布的编辑就没有了删除的权限。在文章被终审通过发布后,当初发布的编辑也没有了删除的权限,删除权限给了另外的用户。对于这个应用,这则新闻数据的授权标志,刚提交时:拥有者读写;经过第一轮审核,发布前变成:读取授权函数、更改授权函数、删除授权函数;发布后增加一个:不保护。具体的编辑之间的授权关系,由新闻网站的开发团队来设计。

  请注意,GH 中的数据是直接对外的,即只要给定一个数据的内存地址(当然不是内部数据),就直接可以返回数据。不像传统应用,会有数据库/数据文件等后端。所以数据的权限保护是需要重视的。


* 系统用户与权限

  系统用户的信息保存在每一个 CPU 的内存空间内。本版设计中,GH 内系统用户的数量是固定的,最多 32 个,第一个系统用户的用户名是 root,这个名字永远不能改变。

  本版设计中,只有 root 能创建其他系统用户,修改其他系统用户信息,如用户名/密码、权限等。

  设计系统用户的目的是维护系统的运行。所以系统用户可以:
    检查、校验所有的静态数据;
    查看/手工调整热点数据的分布;
    查看每个 CPU 的运行情况;
    设置每块网卡的参数,查看每个 CPU 上的网络连接状况;
    设置/查看硬盘数据的分布与完整性;
    上传/加载/卸载计算任务;
    处理 PC 的上线与下线;
    查看整个系统的负载,调整运行参数;
    调试系统、调试应用程序,发现并解决系统中的 bug;
    备份数据;

  所有系统用户的修改行为都要被记录到审计日志。

  每个系统用户都可以被赋予一定的权限。

  系统用户的数据在硬盘上的单独分区保存。

  系统用户的密码都以校验和的形式保存。

  对于每个系统用户的任何修改,都会被同步复制到其他所有的 PC 上,并保存在所有的硬盘中。

  系统用户不能创建普通用户。普通用户里的第一个管理员用户(如果需要的话),由应用程序自己创建,自行维护。


* GH 的 Shell(命令行界面)

  继续保留命令行界面的好处很多,比如支持命令的批处理。命令行界面仅供系统用户使用。

  系统用户在客户端浏览器上操作命令行界面。命令行界面是个用 Javascript 开发的应用程序,把系统操作员输入的命令直接发给 GH,然后将运行结果取回来,显示在浏览器上。

  Shell 命令样例:

   [中文] 列出_用户_cpu 3 范围 1-100
   [eng] ls_user_cpu 3 range 1-100

  以上两个命令可以列出来 id 为 3 的 CPU 上所有用户中的第 1 到 100 个。

  本版设计中,每一个命令都支持中/英两种语言。

  本版设计中,Shell 暂不支持批处理。

  后续版本设计中,Shell 命令既可以运行在客户端,也可以运行在 GH 内,作为动态计算任务来运行,例如系统启动时的 Shell 命令、一台 PC 上线时的命令等等。


* 动态计算任务

  至此,GH 的数据结构、运行模式基本清楚了,该考虑程序如何运行了。

  GH 内部的程序分成三部分:GH 内核,动态计算任务,函数库(类似与 Linux 的动态链接库)。

  GH 内核程序实现基本的功能:内存管理,网卡驱动与协议处理,硬盘分区管理,静态数据响应,动态计算任务加载,等等。本版设计中,不支持 GH 内核程序动态升级。

  函数库是事先准备好的程序,可以被动态计算任务调用。本版设计中,不支持函数库的动态加载/卸载,留待后续版本实现。

  动态计算任务是 GH 内部的应用程序。本版设计中,不支持动态计算任务的动态加载/卸载,但是在系统结构设计上,要预留支持;另外,也要预留支持网站应用的多次开发,即允许用户来控制其他用户的应用程序的加载/卸载/统计/安全审计等,例如目前流行的 Web API。

  GH 的内核运行在 CPU 的内核级(Intel-Ring0),GH 的每一个动态计算任务可以被单独指定运行在内核级,还是应用级(Intel-Ring3)。每个计算任务在编写/编译时就要支持在内核级和应用级的平滑移动,即不用修改二进制代码就可以切换运行级别。

  如果动态计算任务运行在应用级,情形就会类似传统的操作系统,一个应用程序被加载成一个进程之前,内核需要给他构造内存空间,映射函数库,准备好一系列系统调用来供其访问硬件,然后开始运行。幸运的是我们只需要制造一个“简化版的进程运行环境”。应用级计算任务处理完数据后不会像传统的进程那样退出,而是继续留在内存中,回到它刚被加载后的初始状态,其所需的运行环境也一直存在,等待下一次被调用,继续处理数据。

  从网卡接收进来的数据,通过内存页面映射直接提交给应用级计算任务,也就是没有内核与“进程”内存间的数据复制过程。而计算结果,也直接保存成静态数据,通过内存页面映射返回给 GH 内核。

  内核级的应用程序就相对简单,初始化时映射好所有的库函数即可。

  从安全角度考虑,理论上,应用级计算任务如果发生错误或被黑客利用,只能产生有限的影响或破坏;而内核级计算任务被利用,则可以产生灾难性后果。但是内核级与应用级的性能差别也可能产生重大影响。所以我们把这个抉择留给应用开发团队,如果应用开发团队认为自己的计算任务足够安全(经过充分的测试与很长时间的实际运行),可以设置计算任务运行在内核级,提高性能;否则,可以先运行在应用级,增加安全性。

  类似静态数据,每个动态计算任务也都有一个唯一的内存地址,用来快速定位。所以客户端提交数据时,URL 会类似于:
    http://x.y.z./P5555/u222/sSSSSSSS
  其中的 P5555 就是指内存地址为 5555 的一个动态计算任务。随着这个 URL 提交的数据可以在 URL 中,也可以在 POST BODY 中。

  动态计算任务的 ID(内存地址)同样由 CPU 编号和内存地址组成。本版设计中,一个动态计算任务的程序所占的空间,包括代码、静态变量等,不超过一个数据块的尺寸大小,4MB。后续版本设计支持更大的程序。

  为了支持复杂的分布计算,GH 中的每个动态计算任务可以由多个“计算阶段”组成。一个计算任务从第一个计算阶段开始运行,处理数据,处理完成后交给下一个计算阶段(可能转到其他 CPU 上)继续处理,直到全部完成。

  细化一下,举个例子,我们的一个网站要支持 10 亿注册用户同时在“一张纸”上画图。画图功能在网站内部是由一个计算任务实现的。假设在某个时刻,10 亿用户同时(一秒钟内)在“纸上”画了一笔,所有客户端的程序在一秒中内将 10 亿个 HTTP 请求发向 1 千个 PC 的 1 万个 CPU。如果这个绘图的计算任务只在一个 CPU 上运算,则后续过程应该是:所有的其他 CPU 都将绘图数据发给这个 CPU 来运算,绘制出来最终结果图像,复制到其他 CPU 上返回给用户,显然,采用这种办法,那个负责运算的 CPU 累死也算不完(在用户等待画下一笔的耐心范围内)。

  所以,本版设计中,我们把这个计算过程分配到很多 CPU 上,共同完成。继续用画图这个例子来说明。一个网站上可以有很多计算任务,每个计算任务在每个 CPU 的内存中都有备份。也就是画图这个计算任务一加载,则立刻被复制到所有 CPU 的内存中。另外每个计算任务都有一个“协调人”,负责将各计算阶段分配到其他 CPU 中,当然也包括自己。

  所以,画图这个计算任务的运行过程大概是这样的:

  (1) “图纸”上最初是一片空白。CPU_1(假定)接收到第一个 HTTP 请求,里面是用户的一个绘制动作。这个 HTTP 请求的 URL 中包含绘图计算任务的内存地址。GH 内核在内存中找到这个计算任务,计算任务的头部信息记录着应当由 CPU_7(假定)来协调,于是 CPU_1 将绘制请求发给 CPU_7,等待回应(异步等待)。

  (2) 再看 CPU_7,如果 CPU_7 在一定时间(一秒钟)内,从其他 CPU 处只接收到少量的计算请求(实际画画的人很少),总运算量在自己可以接受的范围内,则启动运算,然后将运算结果返回给各 CPU,或者直接通过自己的网卡返回给客户端(接管 TCP 连接)。

  (3) 如果 CPU_7 同时在极短的时间内接收到大量计算请求,远远超过了自己的计算能力(或者自己本来就在进行着另一个负载很重的计算任务),则 CPU_7 会广播一个通知,告诉所有 CPU 先自行进行绘图计算任务的第一阶段的计算,并同时开始请求相对空闲的 CPU 承担第二阶段的计算。以此类推。

  (4) 所以,10 亿个绘图请求,先在 1 万个 CPU 上进行第一阶段(第一秒)的计算,每个 CPU 处理 10 万个绘图请求,共绘制成 1 万个第一阶段的图像,然后每 100 个 CPU 将图像发送给一个 CPU 做第二阶段的运算(假如每个 PC 有 10 个 PC,则可以增加一个中间阶段,先在本 PC 内运算)。共有 100 个 CPU 接收数据后进行第二阶段的运算(第二秒),运算结束后将结果发送到一个 CPU 做最终的合成运算(第三秒),然后将计算结果广播给所有 CPU,返回给用户(第四、五秒)。

  继续幻想一下,考虑一个更复杂的应用,一个虚拟的股票交易所。虚拟交易所支持 10 亿用户同时在线交易,支持 10 万支股票。10 万支股票分散在 1 万个 CPU 上,每个 CPU 管理 10 支股票。在这个应用中,整个市场中的热点股票是随机出现的,理论上,任何一支股票的交易规模都可能瞬间从零增长到 10 亿级,在这种情况下,全系统范围内动态调整撮合运算的负载均衡就很有必要了。所以,在后续版本中,我们可以支持按照数据和计算阶段共同来调整计算过程的全局分布,即支持每支股票都是一个运算协调人。

  动态计算任务的二进制程序格式,留待后续版本考虑。

  计算任务的同步(互锁)问题,留待后续版本考虑。


* 系统的启动与上线

  留待后续版本考虑。


* 客户端的结构与设计

  浏览器,主要考虑 AJAX 模式。留待后续版本考虑。

  手机应用。留待后续版本考虑。


* 应用程序的开发与调试

  程序上传。留待后续版本考虑。

  程序编译。留待后续版本考虑。

  printf 与日志。留待后续版本考虑。

  在多个 CPU 上单步调试,类似远程 gdb。留待后续版本考虑。


* 项目实施

  留待后续版本考虑。


* 系统迁移与共存

  在别的平台上已实施的系统如何迁移到 GH 上来,数据迁移、程序重新开发。留待后续版本考虑。

  请注意我们的系统和 Linux 可以共存在同一台 PC 上(起码现阶段如此),所以我们可以支持一个网站由 GH 与 Linux(及其上的应用系统)共同组成。留待后续版本考虑。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

0.2-设计模式怎么样解决设计问题-针对接口编程,而不是针对实现编程

全文来自《设计模式——可复用面向对象软件的基础》的1.6节 该篇短小精悍,个人感觉是理解面向对象思想和设计模式的最佳内经心法 以下内容只是个人的读书笔记,跪求各路神仙牛人指正理解上的偏差
  • ava46
  • ava46
  • 2016-10-01 17:11
  • 69

文件传输0.2版

相信在使用0.1版的时候没开启监听就直接传送文件必将导致异常,而且传输过程中的信息是看不到的。这一篇是对上一篇进行了一些改进,并且可以了解传输的信息(加入了Log),还加入了接收或者拒绝接收文件功能。...
  • Metal1
  • Metal1
  • 2013-12-31 17:41
  • 1207

java JDBC通用BaseDao升级版0.2

,此次升级为了解决链接数据库时每次都要传用户名和密码的烦恼package com.sun.dao;import java.sql.Connection; import java.sql.DriverM...

永久勘误:微软等面试100题答案V0.2版[第1-20题答案]

微软等面试100题答案V0.2版部分答案精选[第1-20题]作者:July 、何海涛等网友---------------------------    开诚布公,接受读者检验    本文,是根据我之前...

[答案V0.2版]精选微软等数据结构+算法面试100题[1-20]

原文地址:[答案V0.2版]精选微软等数据结构+算法面试100题[1-20]作者:叛逆年少                  ...

Java-单机版的书店管理系统(练习设计模块和思想_系列 八 )

本系列前面博客的链接:Java-单机版的书店管理系统(练习设计模块和思想_系列 七 ) http://blog.csdn.net/qq_26525215/article/details/511906...

Java-单机版的书店管理系统(练习设计模块和思想_系列汇总)

介绍:本软件系列到此,我已经全部写完了。项目练习目标 :1、Java应用程序基本分析 2、培养面向对象编程的基本思想 3、Java基本设计模式综合应用 4、掌握分层和接口的基本设计 5...

Java-单机版的书店管理系统(练习设计模块和思想_系列 一 )

书店管理系统:项目练习目标 : 1、Java应用程序基本分析 2、培养面向对象编程的基本思想 3、Java基本设计模式综合应用 4、掌握分层和接口的基本设计 5、构建合理的Java应用程序包...

Java-单机版的书店管理系统(练习设计模块和思想_系列 四(2) )

说明:本博客为补全上篇-Java-单机版的书店管理系统(练习设计模块和思想_系列 四(1) )的,所以如果不懂,请先看上一篇。 本系列都是我一步一步学习来的, 所以,可能比较适合初学设计模块的人来...

Java-单机版的书店管理系统(练习设计模块和思想_系列 五 )

经过前几次的发博客。。 我发现这样发代码太费劲了。。所以我把目前我完成的源代码上传到百度云里面去了。 百度云链接: http://pan.baidu.com/s/1o7X1Kk6 链接如果失效...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)