偶是测试新手,希望前辈们能多多指教。

发布新日志

  • 互联网产品接入支付功能如何测试?[转载]

    2017-03-15 15:34:35

    现在有不少测试朋友做的项目中,可能也会涉及到支付相关的功能。比如:做商城的,做游戏的以及其他在线交易的网站、APP等。如果支付出了问题,或者用户拿少的钱通过篡改请求数据购买大金额的商品,如果是实物的话,发货前还有可能被发现。如果是虚拟商品话费、游戏币等就有可能造成损失。
      所以,不管是实物也好,虚拟商品也好,涉及到支付功能时,大家在测试的过程中一定要重视,否则,会造成很大损失。之前可能大家也都看到过或者听过一个bug损失4.6亿美金的惨痛教训或者身边也有发生过其他因为支付功能的bug导致直接损失的案例。
      给大家举个真实的案例:比如使用支付宝购买虚拟商品,往支付宝跳转时,篡改了小的金额,结果购买虚拟商品成功了。(原本10元的商品,0.01元就搞定了)。多么可怕的一个bug啊,当然这个问题可能对于一个做过支付有过经验的测试朋友来说,可能会想:哎呀,这个问题都发现不了,还做什么测试?是的,问题是很简单,对于一个刚入职场的测试朋友或者没有支付相关经验的测试朋友来说,很有可能会忽略。
      那么,问题来了,对于支付模块的相关测试,我们应该如何进行呢?比如,针对游戏来说,使用第三方支付往游戏充值游戏币功能,看起来是不是很简单,大家主要思考下以下内容:
      1、支付都是与第三方支付(支付宝、微信、财付通、QQ钱包、短信支付等)进行对接,那么,是否了解了第三方接口有哪些?是否都能清楚我们的产品与第三方是如何交互的?是否能画出流程图?
      2、异常场景有哪些?
      3、有哪些风险,如何规避?
      第三方支付的流程,与商户的对接方式基本相似,大同小异。(题外推荐:如下流程图使用的chrome插件:Gliffy,个人感觉比较好用。)
      支付流程:
      退款流程:
      查询流程:
      先看下流程图,是否对流程图有些了解,不仅仅是做支付功能相关测试才去搞清楚其中的流程,做其他的测试一样也要搞清楚流程,只有搞清楚流程,才能更好的评估其中的风险,才能有利于测试用例的设计。当然流程图中只是提到了商户与第三方是如何交互的,同样商户内部处理的流程也要有所了解及数据怎么存储的,涉及到哪些DB也要清楚。
      流程清楚之后,我们再来看看其中会涉及到哪些接口?这个支付流程图里面就涉及到了第三方支付接口:
      · 下单接口:商户提交下单请求到第三方支付接口,第三方支付收单成功后返回下单成功结果给到商户系统。(下单接口的最终处理结果分为下单成功和下单失败,若未收到明确结果可调用单笔订单查询接口查询结果。)
      · 支付接口:调用该接口时指定支付参数,完成买家账户向商户账户的支付,采用页面跳转交互模式和后台通知交互模式。(结果分为两路返回:一路为前台在return_url页面跳转显示支付结果;一路为后台在notify_url收到支付结果通知后进行响应。)
      · 退款接口:调用第三方支付的支付请求接口返回付款成功后,在需要做退款处理时调用退款请求接口发起退款处理。(退款接口的最终处理结果分为退款成功和退款失败,若未收到明确结果可调用退款查询接口查询结果。)
      · 单笔订单查询接口:根据订单号查询单笔订单信息和状态。
      · 退款订单查询接口:调用第三方支付的退款接口返回后,在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。
      那么针对第三方的接口,我们大致也有所了解了,接下来针对测试过程中涉及到主要的测试点整理如下:
      测试过程中需要注意的主要测试点及异常场景:
      · 首先要保证接口都能正常调用;
      · 生成一笔订单,支付完成后,同步或异步重复回调,只有一次有效;
      · 生成一笔订单,复制订单号和金额,再次生成一笔订单,用fiddler设置断点,用第一笔已完成的订单号和订单金额去替换现有的订单号和金额,无法完成支付;
      · 生成一笔订单,跳转到第三方时修改金额,无法到账,或者如果是游戏充值游戏币的话,到账为篡改后的金额对应的游戏币;
      · 异步通知屏蔽,同步有效,进行支付,同步能够正常到账;
      · 同步设置无效,异步有效,进行支付,异步能够正常到账;
      · 同步异步都设置无效,在第三方支付完成后,在重发机制时间范围内,设置异步有效,到下次通知时间点时,能够正常通知到账(补单机制的验证,如果商户收到第三方支付成功的通知后,要告知第三方支付收到了成功的通知,如果第三方支付收到商户应答不是ok或超时,第三方支付就会认为通知失败,会在规定的时间内持续调用notify_url,一般有时间或次数的限制);
      · 针对支付订单在数据库中存储是否完整和正确进行校验(比如:第三方订单号--方便与第三方对账和问题排查、订单金额、订单状态等);
      · 如果是用户购买实物商品,用户发起退货,要保证退货流程正常,资金能正常返还,要考虑下并发情况的验证以确保安全性;
      · 如果是用户购买虚拟商品,比如话费、油卡之类的商品,只有在发货失败的时候才能发起退货,注意验证;
      遇到过的坑:
      · 用户购买100元游戏币时,前往第三方支付跳转进行金额的篡改由100元改成0.01元,结果就拿了0.01元充值了100元的游戏币。对订单金额没有做校验导致这样的后果,损失比较大。大家在测试的过程中一定要注意对服务端进行校验,支付时数据的篡改一定要有校验。
      · 当同步、异步通知都存在的情况的,异步通知(第三方支付成功后台通知),没有到账,导致部分用户充值不到账,引起客诉。当同步、异步并存的时候,一定要分别对同步和异步进行检验,确保都能正常到账。
      我们所做的绝大多少的互联网产品都会涉及到第三方支付,所以支付功能必然是重要的,作为测试互联网产品的一员,我们必须要做好支付的安全性。
      那么,如何规避支付风险?
      为了进一步的加强支付功能的安全,也可以适当的增加一些监控机制,比如:订单与第三方订单进行对比,可以使用跑批完成,当我们完成支付的订单从数据库中查出来与通过第三方订单查询接口查询出来的同一个订单金额有异常时,进行报警通知能够及时发现处理,甚至当有异常情况进行创建订单的终止,从而把损失降到最低
  • cookie 和session 的区别详解[转载]]

    2017-03-15 15:14:39


    这些都是基础知识,不过有必要做深入了解。先简单介绍一下。

    二者的定义:

    当你在浏览网站的时候,WEB 服务器会先送一小小资料放在你的计算机上,Cookie 会帮你在网站上所打的文字或是一些选择,

    都纪录下来。当下次你再光临同一个网站,WEB 服务器会先看看有没有它上次留下的 Cookie 资料,有的话,就会依据 Cookie

    里的内容来判断使用者,送出特定的网页内容给你。 Cookie 的使用很普遍,许多有提供个人化服务的网站,都是利用 Cookie

    来辨认使用者,以方便送出使用者量身定做的内容,像是 Web 接口的免费 email 网站,都要用到 Cookie。


    具体来说cookie机制采用的是在客户端保持状态的方案,而session机制采用的是在服务器端保持状态的方案。

    同时我们也看到,由于采用服务器端保持状态的方案在客户端也需要保存一个标识,所以session机制可能需要借助于cookie机制

    来达到保存标识的目的,但实际上它还有其他选择。

    cookie机制。正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在HTTP的响应头中加上一行特殊的指示以提示

    浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie的使用

    是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie,如果某个cookie所声明的作用范围

    大于等于将要请求的资源所在的位置,则把该cookie附在请求资源的HTTP请求头上发送给服务器。
     
    cookie的内容主要包括:名字,值,过期时间,路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间,则表示这

    个cookie的生命期为浏览器会话期间,关闭浏览器窗口,cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。

    会话cookie一般不存储在硬盘上而是保存在内存里,当然这种行为并不是规范规定的。若设置了过期时间,浏览器就会把cookie

    保存到硬盘上,关闭后再次打开浏览器,这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏

    览器进程间共享,比如两个IE窗口。而对于保存在内存里的cookie,不同的浏览器有不同的处理方式

    session机制。session机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。

              当程序需要为某个客户端的请求创建一个session时,服务器首先检查这个客户端的请求里是否已包含了一个session标识

    (称为session id),如果已包含则说明以前已经为此客户端创建过session,服务器就按照session id把这个session检索出来

    使用(检索不到,会新建一个),如果客户端请求不包含session id,则为此客户端创建一个session并且生成一个与此session相

    关联的session id,session id的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串,这个session id将被在本次响应

    中返回给客户端保存。保存这个session id的方式可以采用cookie,这样在交互过程中浏览器可以自动的按照规则把这个标识发送给

    服务器。一般这个cookie的名字都是类似于SEEESIONID。但cookie可以被人为的禁止,则必须有其他机制以便在cookie被禁止时

    仍然能够把session id传递回服务器。

    经常被使用的一种技术叫做URL重写,就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器

    会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。比如: 
    <form. name="testform" action="/xxx"> 
    <input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764"> 
    <input type="text"> 
    </form> 
    实际上这种技术可以简单的用对action应用URL重写来代替。

    cookie 和session 的区别:

    1、cookie数据存放在客户的浏览器上,session数据放在服务器上。

    2、cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
       考虑到安全应当使用session。

    3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
       考虑到减轻服务器性能方面,应当使用COOKIE。

    4、单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。

    5、所以个人建议:
       将登陆信息等重要信息存放为SESSION
       其他信息如果需要保留,可以放在COOKIE中

  • SVN使用时遇到的各种问题的解决方法

    2014-08-20 10:13:48

    SVN常见问题

    目录

    1 1. 提示SVN证书过期?
    2 2. 用户名密码校验失败?
    3 3. SVN提交文件时提示文件冲突怎么办?
    4 4. SVN提交文件时提示失败?
     

    1. 提示SVN证书过期?

    问题描述:
    访问SVN库时,会多次弹出证书过期的提示,如下图所示:
    SVN_23.png

    解决方案:
    腾讯云平台于2012年11月1日发布了新的SVN域名以解决该问题,请开发者切换到新的SVN库地址。

     

    2. 用户名密码校验失败?

    一般是由于保存了某个SVN库的登录凭证,导致访问另外1个SVN库时密码错误导致的,请开发者清除登录凭证。
    访问SVN库时,会弹出要求用户输入SVN库用户名和密码的弹框,如下图所示:
    SVN_21.png
    注意不要勾选下面的“Save authentication”,原因是如果1个开发者有多个应用,则有多个SVN库,保留1个SVN库的登录凭证可能会导致登录别的SVN库失败。
    如果失败,请选择右键菜单的“TortoiseSVN”->“Settings”->“Save Data”对话框中,点击“Authentication data”旁的“Clear”按钮,清除登录凭证。清除登录凭证如下图所示:

    SVN_22.png

     

    3. SVN提交文件时提示文件冲突怎么办?

    1. 如果执行svn commit命令时遇到了"xxx is out of date"提示,如下图所示:
    SVN_24.png
    那么一般是因为您修改了本地某文件或目录结构,而别人也修改了同一个的文件或目录并且先于您提交到了SVN库。

    2. 解决的办法是先使用svn update命令获取SVN库上最新修改的文件,这个命令并不会直接覆盖掉您本地所做的修改,SVN客户端会先尝试将SVN库上该文件的修改合并到你的本地文件中。
    如果SVN客户端成功的进行了合并,您可以再次执行SVNcommit命令进行本地文件的提交即可。

    3. 如果SVN客户端无法进行自动合并(可能因为文件是一些二进制文件,或者两人修改的地方是同一个,或者修改的地方太多等原因),则svn客户端会提示“one or more files are in confict state”,即告诉您有文件发生了冲突,如下图所示:
    SVN_25.png

    4. 如果是文本文件冲突,则在文件夹下会多出几个冲突文件,如下图所示:
    SVN_26.png

    其中:
    -f2是尝试合并的文件,里面有svn客户端加入的一些标记;
    -f2.r69是您本地修改文件的基础版本,69是版本号;
    -f2.mine是您本地修改后的文件,即f2.mine是在f2.r69文件基础上更改的;
    -f2.r70是服务器上最新版本的文件,即别人修改后提交的文件。

    此时的解决方法有多种:
    (1)比较f2.r70和f2.mine,将您自己做的修改和别人做的修改手工合并,然后把合并后的内容覆盖到f2中。
    最后右键点击f2,然后选择Resovled,之后f2.mine,f2.r69,f2.r70文件都会自动被删除。然后您再次执行svn commit就可以了。如下图所示:
    SVN_27.png

    (2)如果要保留别人的修改而放弃自己的修改,则可以删掉f2,f2.mine, f2.r69,f2.r70几个文件,再执行以下update,这样会重新从服务器上把最新文件下载到本地。

    (3)如果是保留自己的修改而放弃别人的修改,则可以删掉f2,f2.r69,f2.r70,然后把f2.mine改名为f2,然后再次执行svn commit,就可以把自己的修改上传到svn服务器。

    5. 如果发生冲突的是二进制文件,此时SVN客户端是无法执行自动合并的,这样目录下只会多出以.rXX结尾的两个文件,而不会出现.mine结尾的文件,此时的处理方法可以参考上面的(2)(3)。

  • hosts文件不起作用了

    2013-09-17 09:48:36

        我的浏览器设置了代理服务器,取消了代理,hosts文件就生效了。。。
  • 360 急速模式与兼容模式的趋避

    2013-09-02 10:47:47

    以前的浏览器大部分都采用IE核心,这类浏览器体积都很小,因为他们都只是给IE披了个外衣而已,只是在IE的基础上增加了些功能,其网页显示的效果和IE是一样的,如果你的电脑上没有IE,那这些浏览器也就没有用了。但是IE内核速度比较慢,所以现在的浏览器都使用一个叫Webkit的内核,这个内核浏览速度比IE快很多,因为加入了新的内核,所以现在的浏览器体积都比较大,但是因为国内的大部分用户都是用IE,所以很多网站都是针对IE开发的,用其他的浏览器核心会显示不正常,所以出现了双核浏览器,平时使用Webkit内核,即极速模式,遇到显示不正常的网页就换成IE内核,即兼容模式。
  • 如何设置windows 2003的最大远程连接数

    2010-12-09 17:31:01

     

    按以下操作执行:

    开始 - >
    运行 - >
    gpedit.msc  - >
    管理模板 - >  
    Windows组件 ->
    终端服务 - > 
    限制连接数量 - > 
    启用 TS允许的最大连接数 。

    完成。
    操作如下图:

    如何设置windows 2003的最大远程连接数 - 我爱看火影 - wodexinlihua1 的博客
    如何设置windows 2003的最大远程连接数 - 我爱看火影 - wodexinlihua1 的博客
  • 远程桌面登录蓝屏、不显示桌面问题解决方法

    2010-06-25 13:54:05

    远程桌面登录蓝屏、不显示桌面问题解决方法

    目前使用远程桌面进行远程管理服务器的用户估计会遇到远程桌面登陆服务器后显示黑屏,或无法显示桌面无法进行操作的问题,您可以尝试以下操作方法对远程桌面进行激活。
    1.使用远程桌面,输入您服务器IP地址登陆服务器。


    2.登陆后出现黑屏或无法显示桌面是请您按下Ctrl+Alt+End键,激活远程桌面中的任务管理器。


    3.点击激活窗口中“任务管理器”后,结束查看进程标签中explorer.exe进程,选中该进程,并点击右下角“结束进程”,将该进程结束。


    4.然后您在“Windows 任务管理器”窗口中点击“文件”---“新建任务(运行...)”---“浏览”在浏览中选择“C:\WINDOWS\explorer.exe”程序---“确定”,即可激活远程服务器。
  • 让数据库性能测试性能有所保障【转载】

    2009-07-10 17:16:19

     
    2009年01月09日 星期五 15:07
    虽然说SQL Server数据库本身提供了很好的锁管理机制。但是,从某一方面来说,其实数据库只是一些客户端应用程序的“傀儡”。这主要是因为客户端应用程序对服务器上获取的锁几乎有完全的控制能力。客户端应用程序发出的查询请求以及对结果的处理方式,往往具有直接的控制能力。所以,如果应用程序在设计上稍有不合理的情况时,就会因为锁机制而导致阻塞。

      如当遇到如下几种情形时,就可能会导致阻塞情况的发生。

      一、客户端取消查询后没有回滚实务。

      查询是大部分应用程序经常发生的作业。但是,用户通过前台客户端应用程序查询后台数据库时,有时候往往会因为各种原因取消查询。如用户打开查询窗口后,因为死机或者用户觉得反映速度慢强制取消查询。但是,当客户端取消查询时,若没有加上回滚事务的语句,则此时,因为用户已经向服务器发送了查询请求,所以,后台数据库中所涉及的表,都已经加L上了锁。故即使用户取消查询后,所有在事务内获取的锁都将会保留。此时,若其他用户也需要查询这些表或者用户重新打开查询窗口想通过输入查询条件来提高系统响应速度时,就会发生阻塞的现象。

      二、客户端没有及时取得所有查询的结果。

      通常情况下,用户将查询请求发送到服务器之后,前台应用程序必须立即完成提取所有结果行。如果应用程序没有提取所有结果行的话,就会产生一个问题。因为只要应用程序没有及时提取所有结果,锁可能会留在表上而阻塞其他用户。既然应用程序已经将SQ语句递交给服务器,则该应用程序就必须提取所有的结果行。若应用程序不遵循这个原则的话(如因为一时疏漏而没有配置),就无法从根本上解决阻塞问题。

      三、查询执行时间过长。

      有些查询会耗用比较长的时间。如因为查询语句设计不合理或者查询设计到的表与记录比较多时,都会使得查询的执行时间加长。如有时候用户需要对纪录进行Update或者Delete操作时,如果涉及的行比较多时,就会获取很多的锁。这些锁无论是否最终升级到表锁,都会阻塞其他查询。

      故通常情况下,不要将长时间运行的决策支持查询和联机事务处理查询混在一起。

      当数据库遇到阻塞时,往往需要检查应用程序递交的SQL语句本身,以及检查与连接管理、所有结果行的处理等有关的应用程序行为。通常情况下,为了避免因锁冲突所导致的阻塞,笔者有如下建议。

      建议一:查询完成后提取所有的结果行。

      有些应用程序为了提高用户查询的响应速度,会有选择的提取所需要的记录。这个“小聪明”看起来很合理,但是,却会造成更大的浪费。因为查询结果没有及时提取的话,锁就不能释放。当其他人查询数据时,就会发生阻塞。

      所以,笔者建议在应用程序设计时,对于数据库中查询的记录要及时的提取。可以通过其他方式,如添加查询条件、或者后台查询的方式,来提高查询的效率。同时,在应用程序层面设置合理的缓存,也可以非常明显的提高查询效率。

      建议二:在事务执行时不要让用户输入内容。

      虽然在事务执性的过程中,可以让用户参与进来,以提高互动性。但是,我们数据库管理员往往不建议这么做。因为若要用户在事务执行过程中输入参数,会延长事务的执行时间。虽然人比较聪明,但是其反应速度仍然没有电脑那么快。所以,在执行过程中加入让用户参与的过程,会延长事务的等待时间。故除非有特殊的需要,不要在应用程序的执行过程中,提醒用户输入参数。一些事务执行必须的参数,最好在事先就提供。如可以通过变量等预先把需要的参数传入进去。

      建议三:使事务尽可能的简短。

      笔者认为,数据库管理员应该把一些问题简单化。当某个需求需要很多SQL语句才能够完成时,不妨把任务进行分解。同时,也把事务分解成一些简短的事务。

      如数据库中一张产品信息表,其记录数量有二百万条。现在处于管理的需要,把一次性更改其中的一百五十万条记录时。若通过一个事务进行更改,则其时间会比较长。若其中还牵涉到级联更新的话,则时间会更长。

      针对这种情况,我们就可以学着把事务简短话。如这个产品信息中,可能有产品类型字段。那么在更新数据时,我们能否不一次性进行更新。而是通过产品类别字段进行控制,

    对记录进行分次更新的。如此每个类别的更新事务所耗用的时间就可能会大大缩短。如此虽然操作的时候,会需要多个步骤。但是,往往可以有效避免阻塞情况的发生,提高数据库的性能。

      建议四:子查询与列表框,最好不要同时使用。

      有时候在应用程序设计的时候,通过列表框确实可以提高用户输入的速度与准确率,但是,若前台应用程序没有缓存机制的话,往往会造成阻塞。

      如在一个订单管理系统中,可能需要频繁的输入销售代表。为了用户输入的方便,销售代表往往设计成一个列表框。每次需要输入时,前台应用程序都会从后台中进行查询销售代表信息(如果应用程序没有涉及缓存)。一方面,子查询的速度本来就比较慢;其次,列表框会生成长时间运行的查询。这两个方面碰在一起,就可能导致应用程序提高运行时间过程的查询。从而对其他用户的查询,如系统管理员需要维护用户信息,而造成阻塞。

      所以,在应用程序设计时,子查询最好少用。而子查询与列表框同时使用,更需要禁止。若避免不了的话,则要在应用程序中实现缓存机制。如此的话,应用程序需要销售代表信息的时候,就会从应用程序缓存中取得,而不会每次都去查询数据库。

      同时,可以在这个列表框中设计“重新查询”功能。当用户信息有变更,如系统管理员加入了一个新的销售代表。在没有进行重新查询之前,由于应用程序是从自身的缓存中取得数据,所以没有刚更新的内容。此时,用户就需要运行重新查询功能,让前台应用程序重新从数据库中查询信息。这种设计,就可以提高列表框与子查询的执行时间,有效避免阻塞问题。

      建议五:在取消查询时设置回退事务。

      前台应用程序设计时,应该允许用户临时改变主意,取消查询。如用户查询所有产品信息时,可能会觉得响应时间比较长,难以忍受。此时,他们就会想到取消查询。在这种情况下,

    应用程序设计时就需要设计一个取消查询按钮。用户可以在查询的过程中随时点击这个按钮取消查询。同时,在这个按钮事件中,需要注意加入一个回滚命令。让数据库服务器能够及时对相关记录或者表进行解锁。

      同时最好能够采用锁或者查询超时机制。这主要是因为,有时候大量查询也会耗费用户主机的大量资源,而导致客户机死机。此时,若能够采用查询或者锁超时机制,即在查询超时过后,数据库服务器自动对相关对象进行解锁。这也是数据库管理员需要跟程序开发人员协商的一个问题。

      另外,对数据库连接采取显式控制、在所预计的并发用户全负荷下对应用程序进行承受能力测试、使用邦定连接、对每个查询使用查询超时与锁超时等等,这些手段都可以有效避免锁冲突产生的阻塞。当数据库管理员发现有阻塞的症状时,可以从这些方面出发,寻找解决的措施。

      从以上的分析中可以看出,SQL Server数据库锁是一把双刃剑。其在保障数据库数据一致性的同时,也会给数据库造成一些负面影响。如何把这些负面影响降到最低,就是我们数据库管理员的任务。在应用程序设计时,遵循如上建议,可以有效解决因锁问题产生的阻塞问题,提高数据库的性能。可见,要从根本上解决阻塞问题,需要数据库管理人员与程序开发人员共同努力。

  • JVM JRE JDK到底是什么?[转载]

    2009-07-10 15:52:01

    JVM JRE JDK到底是什么?

      JVM JRE JDK,这些东西到底是什么?

      我们在安装好JDK后就可以想象成我们已经买了一台安装好软件的新的电脑。

      JVM : Java Virtual Machine(Java虚拟机) 。所谓“虚拟机”顾名思义就是模拟出来的东西。就像是我们在用电脑看电视,但是电脑里并没有像电视机里面一样的硬件支持,但是我们仍然可以从电脑里接受电视台的节目。那是因为我们编写了一个可以模拟电视机硬件工作的软件运行在电脑的平台上面的原因。同样JVM就是模拟了电脑的硬件,它同样有着像CPU一样可以执行代码的功能。它的实现具体有:指令集 寄存器组 类文件格式 栈 垃圾收集堆 内存区。可以把它理解成是专门用来执行Java程序的一台机器。也就是说JVM提供了Java执行的硬件平台。JVM上执行的代码都存放在 .CLASS 文件中。JVM只执行字节码文件。

      JRE : Java Runtime Environment(Java运行环境)。就是可以运行Java程序的地方。就像是我们要在电脑上运行一个视频软件的时候必须在Windos或者是Linux操作系统上一样。那我们就可以把它看做是一个操作系统。也就是说JRE提供了Java执行的软件平台。在运行Java的过程中除了需要有JVM执行Java代码这个动作外,还需要Java API(Application Programming Interface,应用编程接口)说简单的就是“类库”。Java程序在运行中没有这些API是不行的,所以JRE包含JVM。

      JDK : Java Development ToolKit(Java开发工具包)。我们有了硬件和软件两个平台后就可以做我们自己想做的事情了。JDK就是我们用来做事情的工具,它包括JRE还有其他工具。我们所说版本的不同,也就是说它里面的工具有差异。就像是你不同的工具箱里放着不同的工具一样。举个例子:最常用的一个就是javac,它是把.java的文件翻译成.class文件的工具。然后让JVM来执行.class文件中的字节码。(就像电脑的CPU只认识0或1的道理)

      如果一台计算机的需求只是运行Java程序,而不是去编写Java程序的时候,它只需要安装JRE就可以了。现在大家知道JVM JRE JDK,这些东西到底是什么了吧。

  • 流媒体的技术

    2009-06-04 16:33:43

    一、流式传输的基础
      在网络上传输音/视频等多媒体信息,目前主要有下载和流式传输两种方案。A/V文件一般都较大,所以需要的存储容量也较大;同时由于网络带宽的限制,下载常常要花数分钟甚至数小时,所以这种处理方法延迟也很大。流式传输时,声音、影像或动画等时基媒体由音视频服务器向用户计算机的连续、实时传送,用户不必等到整个文件全部下载完毕,而只需经过几秒或十数秒的启动延时即可进行观看。当声音等时基媒体在客户机上播放时,文件的剩余部分将在后台从服务器内继续下载。流式不仅使启动延时成十倍、百倍地缩短,而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部从Internet上下载才能观看的缺点。
      流媒体指在Internet/Intranet中使用流式传输技术的连续时基媒体,如:音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件,只将开始部分内容存入内存,流式媒体的数据流随时传送随时播放,只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。
      流式传输定义很广泛,现在主要指通过网络传送媒体(如视频、音频)的技术总称。其特定含义为通过Internet 将影视节目传送到PC机。实现流式传输有两种方法:实时流式传输(Realtime streaming)和顺序流式传输(progressive streaming)。一般说来,如视频为实时广播,或使用流式传输媒体服务器,或应用如RTSP的实时协议,即为实时流式传输如使用HTTP服务器,文件即通过顺序流发送。采用那种传输方法依赖你的需求。当然,流式文件也支持在播放前完全下载到硬盘。
      顺序流式传输
      顺序流式传输是顺序下载,在下载文件的同时用户可观看在线媒体,在给定时刻,用户只能观看已下载的那部分,而不能跳到还未下载的前头部分,顺序流式传输不象实时流式传输在传输期间根据用户连接的速度做调整。顺序流式传输经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段,对通过调制解调器发布短片段,顺序流式传输显得很实用,顺序流式文件是放在标准HTTP 或 FTP服务器上,易于管理,基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频,如:讲座、演说与演示。它也不支持现场广播,严格说来,它是一种点播技术。
      实时流式传输

      实时流式传输指保证媒体信号带宽与网络连接配匹,使媒体可被实时观看到。实时流与HTTP流式传输不同,他需要专用的流媒体服务器与传输协议实时流式传输总是实时传送,特别适合现场事件,也支持随机访问,用户可快进或后退以观看前面或后面的内容。理论上,实时流一经播放就可不停止,但实际上,可能发生周期暂停。实时流式传输必须配匹连接带宽,这意味着在以调制解调器速度连接时图象质量较差。而且,由于出错丢失的信息被忽略掉,网络拥挤或出现问题时,视频质量很差。如欲保证视频质量,顺序流式传输也许更好。实时流式传输需要特定服务器,如:QuickTime Streaming Server、RealServer与Windows Media Server。这些服务器允许你对媒体发送进行更多级别的控制,因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议,如:RTSP (Realtime Streaming Protocol)或MMS (Microsoft Media Server)。这些协议在有防火墙时有时会出现问题,导致用户不能看到一些地点的实时内容。

    二、 流媒体技术原理

      流式传输的实现需要缓存。因为Internet以包传输为基础进行断续的异步传输,对一个实时A/V源或存储的A/V文件,在传输中它们要被分解为许多包,由于网络是动态变化的,各个包选择的路由可能不尽相同,故到达客户端的时间延迟也就不等,甚至先发的数据包还有可能后到。为此,使用缓存系统来弥补延迟和抖动的影响,并保证数据包的顺序正确,从而使媒体数据能连续输出,而不会因为网络暂时拥塞使播放出现停顿。通常高速缓存所需容量并不大,因为高速缓存使用环形链表结构来存储数据:通过丢弃已经播放的内容,流可以重新利用空出的高速缓存空间来缓存后续尚未播放的内容。——流式传输的实现需要合适的传输协议。由于TCP需要较多的开销,故不太适合传输实时数据。在流式传输的实现方案中,一般采用HTTP/TCP来传输控制信息而用RTP/UDP来传输实时声音数据。流式传输的过程一般是这样的:用户选择某一流媒体服务后,Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息,以便把需要传输的实时数据从原始信息中检索出来;然后客户机上的Web浏览器启动A/VHelper程序,使用HTTP从Web服务器检索相关参数对Helper程序初始化。这些参数可能包括目录信息、A/V数据的编码类型或与A/V检索相关的服务器地址。

      A/VHelper程序及A/V服务器运行实时流控制协议(RTSP),以交换A/V传输所需的控制信息。与CD播放机或VCRs所提供的功能相似,RTSP提供了操纵播放、快进、快倒、暂停及录制等命令的方法。A/V服务器使用RTP/UDP协议将A/V数据传输给A/V客户程序(一般可认为客户程序等同于Helper程序),一旦A/V数据抵达客户端,A/V客户程序即可播放输出。

      需要说明的是,在流式传输中,使用RTP/UDP和RTSP/TCP两种不同的通信协议与A/V服务器建立联系,是为了能够把服务器的输出重定向到一个不同于运行A/VHelper程序所在客户机的目的地址。实现流式传输一般都需要专用服务器和播放器,其基本原理如图所示。

      

     
    流媒体播放方式

      1.单播

      在客户端与媒体服务器之间需要建立一个单独的数据通道,从一台服务器送出的每个数据包只能传送给一个客户机,这种传送方式称为单播。每个用户必须分别对媒体服务器发送单独的查询,而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担,响应需要很长时间,甚至停止播放;管理人员也被迫购买硬件和带宽来保证一定的服务质量。

      2.组播

      IP组播技术构建一种具有组播能力的网络,允许路由器一次将数据包复制到多个通道上。采用组播方式,单台服务器能够对几十万台客户机同时发送连续数据流而无延时。媒体服务器只需要发送一个信息包,而不是多个;所有发出请求的客户端共享同一信息包。信息可以发送到任意地址的客户机,减少网络上传输的信息包的总量。网络利用效率大大提高,成本大为下降。

      3.点播与广播

      点播连接是客户端与服务器之间的主动的连接。在点播连接中,用户通过选择内容项目来初始化客户端连接。用户可以开始、停止、后退、快进或暂停流。点播连接提供了对流的最大控制,但这种方式由于每个客户端各自连接服务器,却会迅速用完网络带宽。

     
    流媒体技术应用

      互联网的迅猛发展和普及为流媒体业务发展提供了强大的市场动力,流媒体业务正变得日益流行。 流媒体技术广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电台、 实时视频会议等互联网信息服务的方方面面。流媒体技术的应用将为网络信息交流带来革命性的变化,对人们的工作和生活将产生深远的影响。

      一个完整的流媒体解决方案应是相关软硬件的完美集成,它大致包括下面几个方面的内容: 内容采集、 视音频捕获和压缩编码、内容编辑、内容存储和播放、应用服务器内容管理发布及用户管理等。

  • 数据库死锁及解决死锁问题

    2009-06-03 10:39:31

    deadlocks(死锁

    所谓死锁<DeadLock>: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程. 由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这就产生了一种特殊现象死锁。 一种情形,此时执行程序中两个或多个线程发生永久堵塞(等待),每个线程都在等待被其他线程占用并堵塞了的资源。例如,如果线程A锁住了记录1并等待记录2,而线程B锁住了记录2并等待记录1,这样两个线程就发生了死锁现象。 计算机系统中,如果系统的资源分配策略不当,更常见的可能是程序员写的程序有错误等,则会导致进程因竞争资源不当而产生死锁的现象。锁有多种实现方式,比如意向锁,共享-排他锁,锁表,树形协议,时间戳协议等等。锁还有多种粒度,比如可以在表上加锁,也可以在记录上加锁。
    产生死锁的原因主要是: (1) 因为系统资源不足。 (2) 进程运行推进的顺序不合适。 (3) 资源分配不当等。
    如果系统资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁。其次,进程运行推进顺序与速度不同,也可能产生死锁。 产生死锁的四个必要条件: (1) 互斥条件:一个资源每次只能被一个进程使用。
    (2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。
    (3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。
    (4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之一不满足,就不会发生死锁。 死锁的解除与预防:
    理解了死锁的原因,尤其是产生死锁的四个必要条件,就可以最大可能地避免、预防和
    解除死锁。所以,在系统设计、进程调度等方面注意如何不让这四个必要条件成立,如何确 定资源的合理分配算法,避免进程永久占据系统资源。此外,也要防止进程在处于等待状态 的情况下占用资源,在系统运行过程中,对进程发出的每一个系统能够满足的资源申请进行动态检查,并根据检查结果决定是否分配资源,若分配后系统可能发生死锁,则不予分配,否则予以分配 。因此,对资源的分配要给予合理的规划。

    如何将死锁减至最少

    虽然不能完全避免死锁,但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销,因为只有很少的事务:

    ◆回滚,而回滚会取消事务执行的所有工作。

    ◆由于死锁时回滚而由应用程序重新提交。

    下列方法有助于最大限度地降低死锁:

    ◆按同一顺序访问对象。

    ◆避免事务中的用户交互。

    ◆保持事务简短并在一个批处理中。

    ◆使用低隔离级别。

    ◆使用绑定连接。

    按同一顺序访问对象

    如果所有并发事务按同一顺序访问对象,则发生死锁的可能性会降低。例如,如果两个并发事务获得 Supplier 表上的锁,然后获得 Part 表上的锁,则在其中一个事务完成之前,另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后,第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。

    避免事务中的用户交互

    避免编写包含用户交互的事务,因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度,例如答复应用程序请求参数的提示。例如,如果事务正在等待用户输入,而用户去吃午餐了或者甚至回家过周末了,则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量,因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况,访问同一资源的其它事务也会被阻塞,等待该事务完成。

    保持事务简短并在一个批处理中

    在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长,其持有排它锁或更新锁的时间也就越长,从而堵塞了其它活动并可能导致死锁。

    保持事务在一个批处理中,可以最小化事务的网络通信往返量,减少完成事务可能的延迟并释放锁。

    使用低隔离级别

    确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取(未修改)的数据,而不必等待第一个事务完成。使用较低的隔离级别(例如提交读)而不使用较高的隔离级别(例如可串行读)可以缩短持有共享锁的时间,从而降低了锁定争夺。

    使用绑定连接

    使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有,反之亦然,因此不会相互阻塞。

     

    用存储过程查出引起死锁的进程和SQL语句

    假如发生了死锁,我们怎么去检测具体发生死锁的是哪条SQL语句或存储过程?此时我们可以使用以下存储过程来检测,就可以查出引起死锁的进程和SQL语句。

    use master
    go
    create procedure sp_who_lock
    as
    begin
    declare @spid int,@bl int,
    @intTransactionCountOnEntry int,
    @intRowcount int,
    @intCountProperties int,
    @intCounter int
    
    create table #tmp_lock_who (
    id int identity(1,1),
    spid smallint,
    bl smallint)
    
    IF @@ERROR<>0 RETURN @@ERROR
    
    insert into #tmp_lock_who(spid,bl) select 0 ,blocked
    from (select * from sysprocesses where blocked>0 ) a 
    where not exists(select * from 
    (select * from sysprocesses where blocked>0 ) b 
    where a.blocked=spid)
    union select spid,blocked from sysprocesses where blocked>0
    
    IF @@ERROR<>0 RETURN @@ERROR 
    
    -- 找到临时表的记录数
    select @intCountProperties = Count(*),@intCounter = 1
    from #tmp_lock_who
    
    IF @@ERROR<>0 RETURN @@ERROR 
    
    if @intCountProperties=0
    select '现在没有阻塞和死锁信息' as message
    
    -- 循环开始
    while @intCounter <= @intCountProperties
    begin
    -- 取第一条记录
    select @spid = spid,@bl = bl
    from #tmp_lock_who where Id = @intCounter 
    begin
    if @spid =0 
    select '引起数据库死锁的是: '+ CAST(@bl AS VARCHAR(10)) 
    + '进程号,其执行的SQL语法如下'
    else
    select '进程号SPID:'+ CAST(@spid AS VARCHAR(10))+ '被' 
    + '进程号SPID:'+ CAST(@bl AS VARCHAR(10)) +'阻塞,其当
    前进程执行的SQL语法如下'DBCC INPUTBUFFER

    与锁定有关的两个问题--死锁和阻塞

    死锁

    死锁是一种条件,不仅仅是在关系数据库管理系统 (RDBMS) 中发生,在任何多用户系统中都可以发生的。当两个用户(或会话)具有不同对象的锁,并且每个用户需要另一个对象的锁时,就会出现死锁。每个用户都等待另一个用户释放他的锁。当两个连接陷入死锁时,Microsoft® SQL Server™ 会进行检测。其中一个连接被选作死锁牺牲品。该连接的事务回滚,同时应用程序收到错误。

    如果死锁变成单个公用事件,而且它们的回滚造成过多的性能降级,那么就需要再次进行深入彻底的调查。使用跟踪标记 1204。例如,下面的命令从命令提示符启动 SQL Server,并启用跟踪标记 1204:

    c:\mssql\binn\sqlservr -T1204

    现在所有消息都会显示在启动 SQL Server 的控制台屏幕上和错误日志中。

    使用分布式事务时,也可能发生死锁。

    阻塞

    任何基于锁的并发系统都不可避免地具有可能在某些情况下发生阻塞的特征。当一个连接控制了一个锁,而另一个连接需要冲突的锁类型时,将发生阻塞。其结果是强制第二个连接等待,或在第一个连接上阻塞。

    在本主题中,术语"连接"是指数据库的单个登录会话。每个连接都作为系统进程 ID (SPID) 出现。尽管每一个 SPID 一般都不是单独的进程上下文,但这里常常用来指一个进程。更确切的说,每个 SPID 都是由服务器资源和数据结构(为给定客户单个连接的请求提供服务)组成。单个客户应用程序可能有一个或多个连接。就 SQL Server 而言,从单个客户机上的单个客户应用程序来的多个连接和从多个客户应用程序或多个客户机来的多个连接是没有区别的。不管是来自同一应用程序还是来自两台不同客户机上单独的应用程序,一个连接都可以阻塞另一个连接。

  • 常见的网络协议

    2009-05-08 11:56:56

    常见的网络协议有:

    (1)TCP/IP协议

    TCP/IP协议是Internet信息交换、规则、规范的集合,是Internet的标准通信协议,主要解决异种计算机网络的通信问题,使网络在互连时把技术细节隐藏起来,为用户提供一种通用的、一致的通信服务。

    其中,TCP是传输控制协议,规定了传输信息怎样分层、分组和在线路上传输;IP是网际协议,它定义了Internet上计算机之间的路由选择,把各种不同网络的特理地址转换为Internet地址。

    TCP/IP协议是Internet的基础和核心,是Internet使用的通用协议。其中传输控制协议TCP对应于OSI参考模型的传输层协议,它规定一种可靠的数据信息传递服务。IP协议又称为互联网协议,对应于OSI参考模型的网络层,是支持网间互联的数据报协议。TCP/IP协议与低层的数据链路层和物理层无关,这是TCP/IP的重要特点,正因为如此,它能广泛地支持由低层、物理层两层协议构成的物理网络结构。

    (2)PPP协议与SLIP协议

    PPP是点对点协议;SLIP是指串行线路Internet协议。它们是为了利用低速且传输质量一般的电话线实现远程入网而设计的协议。用户要通过拨号方式访问WWW、FTP等资源,必须通过PPP/SLIP协议建立与ISP的连接。

    (3)此外,常见的还有:文件传输协议FTP,邮件传输协议SMTP,远程登录协议Telnet,以及WWW系统使用的超文本传输协议HTTP等,这些都是常用的应用层协议。

Open Toolbar