|
|
|
|
|
|
|
|
|
|
|
系统响应时间是指用户发出完整请求到系统完成任务给出响应的时间间隔。处于系统中不同的角色的人，对响应时间的关注点是不一样的。从系统管理员的角度来看，系统响应时间指的是服务器收到请求的时刻开始计时，到服务器完成执行请求，并将请求的信息返回给用户这一段时间的间隔。这个“服务器”包含的范围是给用户提供服务的接口服务器，中间的一些业务处理的服务器和排在最后面的数据库服务器。这里并不包含请求和响应在网络上的通信时间。
|
|
|
|
从用户的角度来看，响应时间是用户发出请求开始计时（如按下“回车”键的时刻），到用户的请求的相应结果展现在用户机器的屏幕的时候的这一段时间的间隔。这个时间称为“客户端的响应时间”，它等于客户端的请求队列加上服务器的响应时间和网络的响应时间的总和。可以看出，从用户角色感受的“响应时间”是所有响应时间中最长的，很多影响因素不在应用系统的范围内，如数据包在网络上的传输时间、域名解析时间等。
|
|
|
|
响应时间超出预期太多的应用系统会导致用户的反感，因为系统在让他们等待，这样会降低他们的工作效率，延长他们的工作时间。位于互联网上的Web网站也存在同样的问题，有调查表明，如果一个Web网页不能在8秒钟内下载到访问的用户端，访问者就会失去耐性，他们有的尝试其他同类型的网站，有的可能访问竞争者的网站，并且可能影响他们圈子里面的人访问这个网站的兴趣和取向。对于一个指望这些访问者变为客户的网站站点而言，响应时间带来的后果等同于销售额的损失。
|
|
|
|
系统的响应时间对每个用户来说都是不一样的，以下因素会影响系统的平均响应时间：
|
|
|
|
（1）和业务相关，处理不同的业务会有不同的响应时间。
|
|
|
|
（2）和业务组合有关，业务之间可能存在依赖关系或其他，也会相互影响。
|
|
|
|
（3）和用户的数量有关，大的并发操作会严重影响应时间。
|
|
|
|
有多种方法可以用来测试响应时间，常用的有两种方法，分别是首字节响应时间和末字节响应时间。首字节响应时间是指向服务器发送请求与接收到响应的第一个字节之间的时间，末字节响应时间是指向服务器发送请求与接收到响应的最后一个字节之间的时间。通过测量响应时间，可以知道所有客户端用户完成一笔业务所用的时间以及平均时间、最大时间。
|
|
|
|
米勒曾经给出了3个经典的有关响应时间的建议，至今仍有参加价值：
|
|
|
|
|
|
（2）1秒：用户愿意接受的系统立即响应的时间极限。即当执行一项任务的有效反馈时间在0.1~1秒之内时，用户是愿意接受的。超过此数据值，则意味着用户会感觉到有延迟，但只要不超过10秒，用户还是可以接受的。
|
|
|
|
（3）10秒：用户保持注意力执行本次任务的极限，如果超过此数值时仍然得不到有效的反馈，用户会在等待计算机完成当前操作时转向其他的任务。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Redis是一种主要基于内存存储和运行，能够快速响应的键值数据库，属于临时和永久兼具类型，有点像Memcached，整个数据库统统加载在内存当中进行操作，但是通过定期异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作。
|
|
|
|
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作。此外单个value的最大限制是1GB，不像Memcached只能保存1MB的数据。其主要缺点是数据库容易受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有扩展能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
|
|
|
|
将传统关系型数据库、MongoDB和Redis的特点做一个简单对比。如下表所示，读写响应性能上，传统关系型数据库一般，MongoDB类似于磁盘读写的NoSQL数据库速度较快，基于内存存储的Redis数据库最快。但是传统关系型数据库应用范围广泛，后两者以互联网应用为主。在当前互联网环境下，许多大型网站需要这种处理高并发和高响应的内存数据应用。
|
|
|
|
|
|
传统关系型数据库和MongoDB、Redis的比较
|
|
|
|
Redis的数据库存储模式，是基于键值（Key-Value）基本存储原理，进行细化分类，构建了具有自身特点的数据结构类型。像MySQL这样的关系型数据库，表的结构比较复杂，会包含很多字段，可以通过SQL语句，来实现非常复杂的查询需求。而Redis客户只包含“键”和“值”两部分，只能通过“键”来查询“值”。正是因为这样简单的存储结构，也让Redis的读写效率非常高。键的数据类型是字符串，但是为了丰富数据存储的方式，方便开发者使用，值的数据类型很多，它们分别是字符串、列表、字典、集合、有序集合。在对数据进行各种命令操作之前，首先要掌握Redis的数据结构类型特点。
|
|
|
|
字符串是Redis数据库最简单的数据结构，形式如下表所示，字符串值的内容是二进制的，意味着可以把数字、文本、图片、视频等都赋给这个值，最大长度不能超过512MB。键名的命名要容易阅读，方便系统维护；键名不要太长，否则会影响数据库执行效率。
|
|
|
|
|
|
|
|
列表由若干插入顺序的字符串组成，支持存储一组数据。这种数据类型对应两种实现方法，一种是压缩列表，另一种是双向循环链表。列表中存储的数据量比较小的时候，列表就可以采用压缩列表的方式实现。压缩列表由Redis自己设计实现，类似于数组，通过一片连续的内存空间存储数据，在读写操作时只能从其两头开始（由链表的寻址方式所决定）。不过，它跟数组不同的一点是Redis允许存储的数据大小不同。如下表所示，将700010看作表头的第一个结点字符串数据，结尾是700012字符串。值的内容允许重复出现。列表可用于聊天记录、博客评论等无需调整字符串顺序但又需要快速响应的场景。
|
|
|
|
|
|
|
|
集合是由不重复且无序的字符串元素组成的整体，结构如下表所示，集合与列表最主要的区别是，集合里面所有字符串是唯一的；所有字符串的读写顺序是任意的，不存在从两头操作的问题。
|
|
|
|
|
|
|
|
散列表可以存储多个键值对的映射，是无序的一种数据集合。只有在数据存储数据量比较小的情况下，Redis才使用散列表进行操作，如下表所示。键的内容必须是唯一的，不能重复，且字符串不宜过长，以免占用过多内存，影响执行效率。使用“：”等隔离符号增加可读性，并给使用者提供更大的存储空间。值可以是字符串类型也可以是数字型。散列表特别适用于存储一个对象，会占更少的内存，并且方便存取整个对象。
|
|
|
|
|
|
|
|
有序集合的键被称为成员（member），每个成员都是各不相同的。有序集合的值则被称为分值（score），分值必须为浮点数。有序集合是Redis里面唯一一个既可以根据成员访问元素，又可以根据分值以及分值的排列顺序访问元素的结构，如下表所示。有序集合的值自动进行排序，键字符串必须唯一，值可以重复。由于采用自动值排序，在数据量较多的情况下，检索速度比散列表快。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在Web服务中，一般采用三层架构模式：浏览器+Web服务器+数据库。其中，Web脚本程序负责处理来自浏览器端提交的信息，如用户登录名和密码、查询请求等。但是，由于Web脚本程序的编程漏洞，对来自浏览器端的信息缺少输入安全合法性检查，网络攻击者利用这种类型的漏洞，把SQL命令插入Web表单的输入域或页面的请求查找字符串，欺骗服务器执行恶意的SQL命令。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
功能性是指当软件在指定条件下使用时，软件产品满足明确和隐含要求功能的能力。
|
|
|
|
|
|
适合性是指软件产品为指定的任务和用户目标提供一组合适的功能的能力。
|
|
|
|
|
|
准确性是指软件产品具有所需精确度的正确或相符的结果及效果的能力。
|
|
|
|
|
|
互操作性是指软件产品与一个或更多的规定系统进行交互的能力。
|
|
|
|
|
|
保密安全是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对它们的访问。
|
|
|
|
|
|
功能性依从性是指软件产品依附于同功能性相关的标准、约定或法规以及类似规定的能力。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
功能需求即网络在用户单位业务中应该提供的功能，可以通过了解用户单位所从事的行业、该单位在行业内的地位以及和其他单位的关系等来确定其功能需求。另外，还可以通过了解项目背景来明确用户单位建网的目的，从而有助于描述详细的功能需求。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样的处理，直到事务的开始标志。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WebApp描述了使WebApp达到其业务目标的基础结构，典型使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含WebApp的业务规则的内容层或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器（Model-View-Controller，MVC）结构是WebApp基础结构模型之一，它将WebApp功能及信息内容分离。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
|
|
|
|
（1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。
|
|
|
|
（2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
事务（Transaction）是一系列的数据库操作，是数据库应用程序的基本逻辑单位，即应用程序对数据库的操作都应该以事务的方式进行。
|
|
|
|
事务是一个操作序列，这些操作“要么都做，要么都不做”，是数据库环境中不可分割的逻辑工作单位。事务和程序是两个不同的概念，一般一个程序可包含多个事务。
|
|
|
|
事务通常由数据库操纵语言或其他高级语言（如SQL、CoBOL、C、C++、Java等）书写的用户程序来实现。一个事务由应用程序的一组操作序列组成，它以BEGIN TRANSACTION语句开始，以END TRANSACTION结束语句。
|
|
|
|
|
|
（1）BEGIN TRANSACTION：事务开始。
|
|
|
|
|
|
（3）COMMIT：事务提交。该操作表示事务成功地结束，它将通知事务管理器该事务的所有更新操作现在可以被提交或永久地保留。
|
|
|
|
（4）ROLLBACK：事务回滚。该操作表示事务非成功地结束，它将通知事务管理器出故障了，数据库可能处于不一致状态，该事务的所有更新操作必须回滚或撤销。
|
|
|
|
典型的例子是银行转账业务。对“从账户A转入账户B金额x元”业务，站在顾客角度来看，转账是一次单独操作；而站在数据库系统的角度它至少是由两个操作组成的，第一步从账户A减去x元，第二步给账户B加上x元。下面是银行转账事务的伪代码：
|
|
|
|
|
|
|
|
SQL标准规定当一条SQL语句被执行，就隐式地开始了一个事务，SQL中的Commit work和Rollback work语句之一会结束一个事务。
|
|
|
|
（1）Commit work：提交当前事务。这意味着将该事务所做的更新在数据库中永久保存。一旦事务被提交后，一个新的事务自动开始。
|
|
|
|
（2）Rollback work：回滚当前事务。这意味着将撤销该事务对数据库的更新。这样，数据库恢复到该事务执行第一条语句之前的状态。
|
|
|
|
需要注意的是，若事务已执行了Commit work，就不能用Rollback work来撤销。数据库系统能保证在发生诸如某条SQL语句错误、断电、系统崩溃的情况下，若事务还没有执行Commit work，则所造成的影响将被回滚。对断电、系统崩溃的情况，回滚是在系统重新启动时进行。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
用户界面是计算机中实现用户与计算机通信的软件和硬件部分的总称。用户界面也称为用户接口或人机界面。
|
|
|
|
|
|
计算机发展早期，用户通过控制台开关、板键或穿孔纸带向计算机送入命令或数据，而计算机通过指示灯及打印机输出运行情况或结果。这种界面的特点是人去适应计算机，现在看来是十分笨拙的。
|
|
|
|
|
|
字符用户界面是基于字符型的。用户通过键盘或其他输入设备输入字符，由显示器或打印机输出字符。字符用户界面的优点是功能强、灵活性好、屏幕开销少；缺点是操作步骤繁琐，学会操作较费时。
|
|
|
|
|
|
随着文字、图形、声音、图像等多媒体技术的出现，各种图形用户界面应运而生，用户既可使用传统的字符，也可以使用图形、图像和声音同计算机进行交互，操作更为自然、更加方便，多媒体技术进一步推广、发展与完善。现代界面的关键技术是超文本。超文本的"超"体现在它不仅包括文本，还包括图像、音频、视频等多媒体信息，即将文本的概念扩充到超文本，超文本的最大特点是具有指向性。
|
|
|
|
|
|
多媒体、多通道及智能化是新一代用户界面的技术支持。新的、更加自然的交互技术，将为用户提供更方便的输入技术。计算机将通过多种感知通道来理解用户的意图，实现用户的要求；计算机不仅以二维屏幕向用户输出，而且能以真实感的计算机仿真环境向用户提供真实的体验。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
资产管理实现对网络设备、服务器、PC、打印机、各种配件（显示器、显卡、网卡、硬盘）、软件、备品备件等设备资产信息的维护、统计及资产生命周期管理。根据资产信息获取方式的不同，资产管理可分为静态资产信息管理和动态资产信息管理。
|
|
|
|
|
|
（1）资产信息维护：包括资产信息的获取与更新、查询、导出和打印。
|
|
|
|
（2）资产信息分析统计：实现静态资产的统计分析，关键指标为设备利用率。
|
|
|
|
（3）资产生命周期管理：对资产的采购、入库、维修、借调、领用、折旧、报废等生命周期各阶段的管理功能。
|
|
|
|
（4）辅助决策：包括预警功能，如资产过保修期预警、资产报废预警等；同时包括基于规则的运维费用的计算，运维费用包括资产维护费用和相关的维护人员费用，能够灵活调整计算规则。
|
|
|
|
|
|
动态资产信息管理是在静态资产信息管理的基础上实现资产信息的自动发现和采集，资产信息的自动同步和更新。
|
|
|
|
|
|
|
|
|
|
|
|
|
