在不久前我们的一篇名为《8款入门级樱桃红轴机械键盘测试排名》的文章中，AKKO 3108意外的成为“大键一致性测试”的末名得主。有些人觉得名副其实，而有人则不太相信，但不管如何，键盘是市场上抽取的、数据和结果是真实公正的。唯一能安慰的是，这项测试是“按压一致性”的品控测试，可能测试方式也比较“过分”，在这里垫底的产品也并非一无是处。
下面我们单独介绍下这款产品的详细测试情况和归纳它的问题点(相比同级别同价位)，也许能让大家更理性的看待这款产品，而不要以排名或分数一概而论，数据不过是督促厂家努力做好品控的参考，而对玩家和用户而言，读懂各个产品的体验上的特点似乎更有益于各自的选择。
【测试设备&原理】
【测试设备】：按键克重曲线分析仪
【原理】：将键盘保持默认出厂状态在水平测试台上，以模拟人手的使用作为测试场景。机械臂模拟手指做垂直按压的操作，感应器将以缓慢、高灵敏度(100000点/秒)准确抓取整个“下压和回弹”过程中各个点的压力变化，测出按键的克重和行程关系的曲线图，并计算实测数值与轴体理论值的偏差率，统计出各项指标的结果。最后将数据偏差和按键的实际情况结合进行分析，确认其整体按键顺畅程度、一致性和手感特点。
【测试方法】：测出普通键(X1倍键帽)的曲线作为参照标准，再选择操作频率最高的大键(带平衡结构的键如Space、Enter、Shift*2、Backspace、)的各个测试点作为重点测试对象，模拟人手操作习惯，将各个大键的实测曲线图与标准曲线进行分析、计算偏差率，最终得出该键盘在实际体验时大键手感的优劣。
【测试取样点】5个大键、11个触发点，适用于标准键位布局键盘。
【轴体】
CHERRY MX红轴是近几年来最受玩家喜欢的轴体，它直上直下的手感、轻快灵敏的反映让它文(Office)武(Gaming)兼修。它也是黑轴之后针对游戏优化的轴体，二者风格相似，但如果平衡技术(平衡杆、卫星轴)做的不好的时候，MX红轴大键的手感会变得像黑轴那么重，控制好力度成为大键的关键，而3108在测试中就倒在这上面。
【按键】实测数据
【普通键】普通键虽然是全绿通过，但你会发现，普通键的“总程压力”就达到了73.73cN(22.88%的偏差)，普通键单点得分才82分(比较低)，感觉这是测试前的一个讯号。
【Backspace键】中心触发时数据、线型和结果都令人十分满意。但左侧卫星轴触发时，蓝线的倾斜度明显陡增，加上“预紧力”18.78cN，让线型比较明显的呈现“二段式”，前0.5mm显得较松软(轻微的松垮)，后面3.5mm力度比较大，接近在黑轴的范围。
【Enter键】很让人意外的是，居然中心触发时出现了一项飘红：“总行程”仅3.53mm。虽然在左侧卫星轴触发处有所增加，但总体来说触底的感觉不是那么足够，尚不能充分的体现出钢板OEM机械的干净、硬朗的触底反馈感。
【左Shift键】从线型图能清晰的看到，中心触发时数据表现不够稳定，“总程压力”陡增明显，“导通行程”太大，这两项的飘红导致它的单点得分已经是我们测试过的所有[左shift键]中最低的。加上右侧卫星轴触发时4项飘红的糟糕表现，57分的单点得分，这个键的一致性很糟糕。
从线型和单项数据来看，力度在这个键上基本失控了，无论中心还是卫星轴处的触发，人手能感觉到敲击时比较费劲，而且导通(垂直黄线标识的位置)太晚，对于游戏而言，基本失去了红轴的价值。
【右Shift键】除了“导通行程”之外，和[Enter键]的问题基本一样，中心触发的“总程压力”依然居高不下，达到了95.17cN，从线型来看，这是末端的陡增造成的问题，可能需要从卫星轴的触底时的情况来找寻解决方法。在左侧卫星轴触发时，力度陡增的问题依然没有缓解，下压线型呈现明显两段式的增长，可以感觉到它的费力。稍微欣慰的是，结合前面的“预紧力”不足的情况来看，17.99cN的“预紧力”也不是太差，轻微松垮而已。
【Space键】与前面的键相比，[Space键]显得好不少，除了两侧卫星轴都有“预紧力”不足的问题之外，但其实17cN并不是特别松垮，客观的说，这个表现是可以接受的。但是卫星轴处的触发却呈现明显的分段式，整个按键的流畅度还是有待加强。
从这5个大键的表现来看，空格是相对最好的，从品控角度来看，这是AKKO不够关注[Space键]之外的大键造成的问题。
实测偏差汇总：
从测试结果来看，AKKO 3108在55个测试点共有15个点的测试数据没通过一致性测试，通过率仅73%，单点测试得分在55~95之间巨大的跨度，并有两个单点得分不及格的键。从数据来看它的主要问题是：两个Shift键的“总程压力”过大，多数大键边缘“预紧力”不足。
*表格分析：
从数据来看，AKKO 3108的问题非常的集中：是“力”的问题而非行程的。“总程压力”、“预紧力”各有5项不合格，很清晰的显现出这款键盘的特点：
 “总程压力”的控制比较一般，平均偏差达到了的32.67%(19.8cN)，飘红的范围则在21.36~39.6cN之间，已经落入黑轴的克重压力范围了。
“总行程”是3108相对来说比较好的表现，但5.5%的偏差也不是十分出色，所测试的8款中位列中游。
“预紧力”总体偏低，除了[Enter键]之外，所有其他大键的卫星轴都存在轻微的松垮问题，比较安慰的是但钢丝声控制比较好，杂音的干扰相对较少。
【总结】
通过结合数据和实际敲击体验，AKKO 3108有接近ikbc C104、GANSS GS104C这些善于功保持充分下压过程的能力，按压过程也比较充裕，而且大键没有特别明显的松垮。但在力度控制上做的明显不够，除了[Space键]之外的大键基本上给人的力度是黑轴的感觉，虽然风格(直上直下)变化不大，但确实不符合红轴的品控，相比普通键能感觉到大键的费力程度。
作为AKKO主打热销的系列之一，从抽样测试的结果来看，揭示了不少一致性上的缺陷，没有准确的控制力度、守住红轴的底线是3108本次测试暴露出的最大问题。由此不难推测，同批次的黑轴3108那个力度能达到什么地步了。
 感谢关注GWT报告，开箱找感觉，深究看报告。

本文是根据7月26日InfoQ中文站在杭州举行的QClub活动（第三期）后半程小组讨论总结而成。主要内容包括如何在SOA系统中实现服务编排，如何保证分布式系统中的一致性和可用性，以及如何在实施SOA的过程中控制接口的粒度等。活动前半程的嘉宾分享部分，InfoQ中文站已经通过视频和PPT演示的形式发布了。

如何在SOA里面实现服务编排？

SOA系统或产品一般会提供ESB这样一个核心服务。在开发过程中，我们自己曾经用过BEA的WebLogic产品，在它的企业服务总线里面有一个UDDI，里面注册了很多服务。假设目前有A，B，C三种服务，而我们需要用到的一种顺序是ACB，这就需要在一个调用中把这三个服务串起来。在ESB里有一些脚本语言可以把这些服务找出来，然后经过串联形成一个虚拟服务D。从而通过这样的方式把分离的服务编排成一个相互之间有顺序的，能够完成你实际需要的那么一种服务。另外在ESB里面每个服务会有一个事务框架，也就是说每个服务自己是有事务处理。假如要把它们封装到一起形成一个链的话，那么在这个链中任何一个服务的事务失败之后，都会使得整个链中的事务失败，最后回滚到最开始执行的场景，保证整个D服务的事务也是完整的。





图1：演讲嘉宾程立参与分组讨论

如何保证分布式系统中的最终一致性和可用性？

对于本地事务处理，或者是集中式的事务处理系统，很显然我们应该采用已经被时间证明也是很成熟的ACID（注：Atomic/原子性、Consistency/一致性、Isolation/隔离性和Durability/持久性）模型。它会利用到数据库管理系统和成熟的JMS服务器等，用其本身所具有的事务管理功能，来保证程序具有数据库事务处理的这四个特性，对于编程模型来讲，这也是最简单的。但是当我们开发的系统不再是一个简单的集中式系统，比如简单的MIS（管理信息系统），OA（办公自动化系统）或者是博客系统等，而是类似支付宝或者说eBay的Paypal支付系统的时候，其访问量特别巨大和系统结构非常复杂的特点，导致它必须具有一个分布式的架构。又因为系统处理的事情特别多，这也需要它具有很长的事务过程；另外最重要的一点是因为涉及到资金的流转，它对安全性的要求非常高，不允许发生资金的错误。

对于这样的分布式系统，组件的分布会导致它调用的成本和时间代价非常高。如果我们采用传统的ACID本地事务的话，所出现的情况就是系统可用性和严格一致性之间的冲突。因为当我们要求分布式系统具有严格一致性的时候，可用性就会受到损失，而可用性又是一个不允许我们讨价还价的，比如说像支付宝这样的业务，它就要求服务器一年365天7*24小时不间断运转。结果就是我们只能在严格一致性上做出让步，这就需要放弃掉传统的，也是最简单的ACID模型，而选择BASE，即基本可用，柔性状态，柔性一致和最终一致等。对一个“基本可用”系统来说，我们需要把系统中的所有功能点进行优先级的划分，像资金划拨这样的功能在一致性上不能做出任何让步，我们可以选择继续使用这样的严格一致性。而例如邮件发送、通知这样的功能，我们可以对系统做一个选择，降低其一致性的特性，使其具有高度可用性。所谓柔性一致就是系统内的状态对用户来说是一个完整的系统，它的一致性是不允许有任何损失的，就是说用户支付了10块钱，那么他的帐户上必然是只扣掉了10块钱；但是对于系统内部的状态，我们可以采用一种柔性的策略，比如说系统内分布了ABC三个功能模块，我们允许它们在某一时刻三个模块的状态可以不一致。我们会通过业务和技术的手段，比如说异步机制或者批处理方式来保证系统通过柔性状态一致来获得可用性。





图2：QClub杭州负责人冯大辉现场组织

最终一致性其实也是同样的意思，柔性的状态一致只是说某一些阶段不一致，但最终要求系统必须保持一致，也就是说在用户看来你的系统必须是一致的。所以归根到底，BASE的实现是放弃掉纯粹的业务手段，而采取技术和业务相结合的机制来保证系统对于外部看来是一个一致的系统。由于采用了这样一个灵活的策略，使得我们同时具有最终的一致性和系统的可用性。

如何在实施SOA的过程中控制接口的粒度？

针对在SOA中如何控制服务的粒度，以及如何让SOA与现有的业务相结合这两个问题，在我们现在行业里没有一个放之四海而皆准的标准。这个东西一定是你在制订SOA策略的时候就提前做考虑，通过对现有业务进行抽象，然后定义出来SOA系统的接口。在设计这个接口时，我们的原则就是它一定是粗粒度的，不是细粒度的，因为只有粗粒度接口才能够灵活应对我们业务的变化。现在不论是哪一个行业，比如互联网行业和企业管理，它们的业务需求变化都是非常快的。



图3：活动结束后合影留念

在系统日常的工作中，常会冒出一些新的业务类型，但这些类型在我们做业务抽象的时候并没有出现。如果我们当初定义的这个SOA接口粒度非常细的话，那么现在很有可能没有办法处理这样一个新的业务。如果要处理，可能的方法是再投入开发资源去开发一个新的接口，或者在原有接口上再增加新的方法。试想一下，如果现在有一个粗粒度接口，我们就可以把这个新的业务类型包容进来。具体的解决方案是我们可以对外界提供一个粒度很粗的接口，而在我们的系统内部通过很多细粒度接口对它进行支撑。比如说我们现在对外公布一个传递数值的接口，传递过来后，系统返回一个业务操作的具体结果。在这些接口里，假设每一个细粒度接口对应一个业务分支，那么当出现新的业务类型时，因为我们当初定义接口的时候赋予它一定的扩展性，所以能够很容易地更新变化的数据。可以预见的结果是，当有了新的业务类型，我们也不用再担心，只需要再加上几个细粒度接口即可。新的业务分支对应到这几个细粒度接口上去，使得SOA的一个粗粒度对外接口应对所有新的业务变化，而且这个接口的定义整体是没有变的，对外界而言完全是一个稳定服务的接口。

 
DB2 UDB通过锁来完成应用程序的并发性控制，而应用程序的并发性可以有效地保证数据的完整性和一致性，同时大大提高应用程序的执行效率。但是，由于应用程序设计，代码编写或者数据库设计方面的不足，多数数据库应用程序都经历过锁升级，甚至死锁的现象。这大大降低了应用程序的并发性能，严重影响了用户对于产品的满意程度。本文通过实例帮助用户了解如何在DB2 UDB中监控死锁的发生以及分析监控的结果，从而提出了几个最佳的实践和规则，最大可能地避免锁升级和死锁的发生。
序言
本文的目的就是通过详细的实例来阐述如何在DB2 UDB 中监控死锁的发生。在DB2 UDB中有两种类型的监控器：快照监控器和事件监控器。快照顾名思义就是数据库连续状态下的一个切面，通过快照监控器，你可以很方便地查看当前连接的应用程序，当前等待的锁，当前的死锁，以及正在执行的SQL语句，同时你可以查看缓冲区，表和表空间的用法。如果保存历史数据，并且能够做出比较，对于分析数据库的并发性能有很大的帮助。
但是我们并不能预测什么时候发生死锁，所以如果有一个后台程序能够一直监控数据库的活动，记录下所有的死锁事件，这对于数据库管理员来说是非常重要的。DB2 UDB提供了事件监控器。通过不遗漏地获得一段时间内所有的数据库事件（在本文中只关心其中的死锁事件），事件监控器提供了一种可以分析历史数据（本文的重点），预测将来趋势的可能。DB2 UDB同时提供了DB2 Performance Expert (DB2/PE) 或者类似的程序用来生成分析报表，不过这已经超出了本文的范畴。

常用术语
锁是控制应用程序并发的数据库软件机制，锁用来防止以下情况的发生：
1． 丢失以前更新
2． 不可重复读取
3． 访问未提交数据
锁的模式包括共享锁和排他锁，共享锁允许其他程序读取已经被其他共享锁占用的资源，所以也叫读锁，排他锁意味着在释放资源以前其他的应用程序无法访问同一资源，所以也叫写锁。此外，DB2 UDB 还提供了不同的锁级别，不同的应用程序可能会要求访问不同范围的数据，锁级别有利于充分利用系统资源，提高系统性能。若一个应用程序请求一个锁，而该锁被另外一个应用程序所使用且不能共享，DB2 UDB 就会挂起前一个应用程序。锁升级就是当LOCKLIST (LOCKLIST代表锁能够占用的内存空间) 耗尽或者一个应用程序所拥有的锁大于MAXLOCKS*LOCKLIST的时候（MAXLOCKS 代表应用程序所拥有的锁占所空间的百分比），DB2 UDB 就试图把几个行级别的锁合并为一个表级别的锁，从而释放锁空间。虽然锁升级本身并不耗费多少时间，但是锁住整个表通常会大大地降低并发性能。
当应用程序处于挂起状态超过了一段规定的时间后，DB2 UDB就会自动中止这个应用程序，同时会向SQLCA发送描述性的错误信息。当两个或者更多的应用程序都持有另外一个应用程序所需资源上的锁，没有这些资源，那些应用程序都无法继续完成其工作的时候，就会发生死锁。
在DLCHKTIME超时之后，DB2 UDB会中止发生死锁的某个应用程序（通常为所做工作最少的那个应用程序），这会释放这个应用程序所持有的所有的锁，并允许别的应用程序继续工作，DB2 UDB 将向被终止的应用程序的SQLCA发送描述性的错误信息。LOCKTIMEOUT 指定一个应用程序被允许的锁等待的时间，这将避免全局的死锁从而导致整个应用崩溃。如果LOCKTIMEOUT 的值为-1，应用程序会等待直到该锁被释放或者发生一个死锁。
事件监控器
事件监控器用来收集当一个数据库事件发生时所关联的应用程序的信息。这里的事件指，连接，死锁，声明和事务。你可以定义你想监控的事件类型的监控器。比如说，一个死锁监控器就是用来监控死锁的发生。
在DB2 UDB 中存在两种和死锁有关的事件类型：
DEADLOCKS
记录简单的应用程序信息。 
DEADLOCKS WITH DETAILS
记录所有复杂的信息，包括应用程序、执行语句声明以及死锁的详细信息。但是使用这种事件监控器会因为需要得到大量额外的信息而降低系统的性能。

如何监控死锁
为了详细说明事件监控器在死锁监控中的用途，我引入了一个简单的死锁场景来触发一个死锁，在随后的章节，我会告诉读者如何分析监控结果以及根据结果来避免死锁的发生。
这里我们需要至少三个应用程序来调用DB2 CLI，一个用来监控死锁的发生，另外两个用来产生死锁。我们可以使用DB2 UDB 安装时附带的SAMPLE数据库。
1． 首先建立一个死锁事件监控器
Session Monitor
db2 connect to sample
db2 "create event monitor dlmon for tables, deadlocks with details write to file 'C:/dlmon'"
mkdir C:/dlmon
db2 "set event monitor dlmon state 1"
2． 用另外两个应用程序来产生一个死锁
Session A
db2 connect to sample
db2 +c "insert into employee values('000350', 'Truman', 'I', 'Jiang', 'B00', '5892',
'1999-02-21', 'Engineer', 19, 'M', '1978-06-17', 60000, 2000, 6000)"
现在应用程序A就拥有了一个EMPLOYEE表的行级别的排他锁
（注: +c 代表不自动提交SQL语句，DB2 中 autocommit 是缺省设置，也可以通过 db2 update command options using c off 关闭该缺省选项。）
Session B
db2 connect to sample
db2 +c "insert into project values('AD3300', 'Dead Lock Monitor', 'B00', '000350', 7.00, 
'1982-07-21', '1983-02-03', 'AD3111')"

现在应用程序B就拥有了一个PROJECT表的行级别的排他锁
Session A
db2 +c "select projname from project"

应用程序A需要PROJECT表上所有行的共享锁，但是因为PROJECT表正在被应用程序B以排他锁的形式独占，这时候应用程序1就进入一个锁等待的状态。
Session B
db2 +c "select firstnme from employee"

应用程序B也进入一个锁等待的状态。此时就出现了一个死锁状态。
3． 两个本身处于锁等待并且占有资源的应用程序互相等待另外一方所持有的资源，这时候Session A和Session B就出现了死锁状态，这种状态一直会延续直到死锁检查器（超出DLCHKTIME时间以后）检查出一个死锁并且回滚其中的一个事务。
Session B
SQLN0991N 因为死锁或者超时，当前事务已经被回滚。原因码为 "2". SQLSTATE=40001
这时候死锁事件监控器就会记录这个死锁，同时应用程序A可以完成他的工作。

Session A
PROJNAME
----------------------------------------
……
20 条记录已选择
Session A
db2 connect reset
Session B
db2 connect reset
4． 通过 db2evmon 工具可以获得死锁信息的日志，并且把日志文件导入到本地机器的文件系统当中。在下面一节，我们将详细分析导出的日志文件。
Session Monitor
db2 connect reset
db2evmon -path c:/dlmon > c:/dlmon/dllog1.txt
分析监控结果
本节我们开始详细分析上一节产生的监控结果，从监控导出的日志文件中，我们可以分析出死锁发生的时间，级别，模式以及产生死锁的SQL语句，从而据此来进一步地修正可能由程序并发设计或者数据库设计所导致的缺陷。

--------------------------------------------------------------------------
                            EVENT LOG HEADER
Event Monitor name: DLMON
Server Product ID: SQL08022
……
Server instance name: DB2
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Database Name: SAMPLE 
Database Path: C:/DB2/NODE0000/SQL00001/
……
--------------------------------------------------------------------------
3) Deadlock Event ...
Deadlock ID:   1
……
4) Connection Header Event ...
Appl Handle: 949
……
5) Deadlocked Connection ...
Deadlock ID:   1
Participant no.: 2
Participant no. holding the lock: 1
Appl Id: G9B56A72.HE13.01B406083205
Appl Seq number: 0001
Appl Id of connection holding the lock: G9B56A72.HD13.02CE06083152
……
Deadlock detection time: 2006-01-06 16:34:27.327582
Table of lock waited on      : EMPLOYEE
(A锁发生的表)
Schema of lock waited on     : JT      
Tablespace of lock waited on : USERSPACE1
Type of lock: Row
（A锁级别为行锁）
Mode of lock: X   - Exclusive
（A锁模式为排他锁）
Mode application requested on lock: NS - Share (and Next Key Share)
（在A排他锁上要求B共享锁，发生死锁）
……
Text     : select name from employee
（产生B共享锁的SQL语句）
List of Locks:
（当前所有锁的列表）
   ……
      Lock Name                   : 0x020005000D0000000000000052
      Lock Attributes             : 0x00000008
      Release Flags               : 0x40000000
      Lock Count                  : 1
      Hold Count                  : 0
      Lock Object Name            : 13
      Object Type                 : Row
      Tablespace Name             : USERSPACE1
      Table Schema                : JT      
      Table Name                  : PROJECT
      Mode                        : X   - Exclusive
    （在PROJECT表上有一个排他锁）
……
      Lock Name                   : 0x02000300000000000000000054
      Lock Attributes             : 0x00000000
      Release Flags               : 0x00000001
      Lock Count                  : 1
      Hold Count                  : 0
      Lock Object Name            : 3
      Object Type                 : Table
      Tablespace Name             : USERSPACE1
      Table Schema                : JT      
      Table Name                  : EMPLOYEE
      Mode                        : IS - Intent Share
   （在EMPLOYEE表上有一个共享锁）
Locks Held: 6
Locks in List: 6
……
9) Table Event ...
Table schema: JT      
Table name: EMPLOYEE
Record is the result of a flush: FALSE
Table type: User
Data object pages: 1
……
Rows read: 35
Rows written: 1
……
Tablespace id: 2
Table event timestamp: 2006-01-06 16:37:28.972501
（记录EMPLOYEE表上发生的事件）

我们可以分析一下dllog1.txt 文件，来准确定位死锁发生的原因，看看5）Deadlocked Connection: 我们可以看出死锁发生的表是EMPLOYEE，同时我们也可以判断出这是一个对于已被排他锁占有的资源申请共享锁所导致的死锁。更加重要的是我们得到了产生死锁的SQL语句，从上面我们可以推断出一定存在别的应用程序在以独占锁的方式占用EMPLOYEE表，这很有可能就是对于EMPLOYEE表的插入或者更新动作造成的。
而这最有可能就是插入或者更新事务时间过长所导致的，导致事务时间过长的原因大体有两种，一是来自于并发程序的设计和编写，二是来自于数据库的设计和数据库参数的调整。
本节我们通过仔细地分析事件监控器的结果来推断出导致死锁发生的原因，从而采取有效的措施去避免死锁的发生。这些措施包括调整数据库参数，或者修改应用程序的代码，或者修改SQL语句甚至是数据库的设计来提高代码和SQL语句执行的效率。
避免死锁的方法
越早地考虑数据库设计中的并发性问题，就越可以提高代码执行的效率，降低程序开发和维护的成本，这里我们提出了一些避免死锁，提高应用程序并发性的方法。
设置隔离级别，根据应用程序的业务逻辑和数据完整性需求来决定合适的隔离级别，包括：RR，RS，CS，UR。该决定需要对应用程序需求和相关的业务规则具有基本理解 
尽量避免锁升级，正确调整参数LOCKLIST, MAXLOCKS 
SQL0911N返回码68（LOCKTIMEOUT参数）的原因是锁等待超时，而SQL0911返回码2（DLCHKTIME参数）的原因则是因为死锁被强制回滚，避免这两种错误的方法就是合理设计数据库和建立合理的索引 
尽快提交事务，不要在事务中加入不必要的执行时间过长的代码，比如大的代码循环和远程调用，或者一些没有用处的SELECT语句 
应用程序的框架实现保证一旦发现SQL错误，立刻执行回滚事务，释放锁。 
如果多个应用程序访问同一资源，最好以相同的次序访问。这样，即使前一个访问资源的应用程序会延迟其他应用程序的访问，也不会导致死锁的发生 
设定外键索引，如果想删除父表中的行，就需要扫描多个子表中的多行数据，这样就需要占用多个子表的锁，我们可以通过在外键上建立索引来减少扫描子表的行数，否则若不建立索引，如果从父表中删除一行的时候，就需要扫描整个子表

结束语
在完成这个例子的过程中，您可以看到不同DB2工具（DBC CLI, SQL, DB2EVMON）的使用实例，并且可以学会如何逐步地利用死锁事件监控器来监控死锁的发生，接着您学会了如何分析那些从死锁监控器得来的结果，以及采用相应的措施来避免死锁的发生。
参考资料
"Lock avoidance in DB2 UDB V8" 一文介绍了 DB2 并发情况下如何用新注册变量来减少锁。 
通过访问 developerWorks DB2 UDB for Linux, UNIX, and Windows 页面 以获得有助于扩展 DB2 UDB 技能的参考资料。 
DB2 for z/OS: DB2 数据库设计：一文为在 z/OS? 环境中取得更好的性能提供了一些一般性的指南和建议。 
理解 DB2 通用数据库中的锁定：本文介绍了一个常见的锁定场景并说明哪些锁会被持有以及相应的原因。

           一、引言　　

        由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。

二、目的

控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。

三、角色与职责


1、市场人员

1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。

2） 负责与客户的沟通确认，并及时反馈客户最新需求。

3）负责与项目经理的沟通

4）负责与客户协调沟通需求变更中需求部分存在的差异

5）负责将需求变更中的需求提供给客户签字确认


2、 项目组长

1）负责协调变更的需求并对变更的需求有拒绝的权利

2）负责对变更的需求部分设计的修改

3）保证项目的开发与需求的一致性

4）确定开发进度是否需要进行变更

5）分配新需求给相关开发人员


3、测试组长

1）负责相应测试需求分析书的修改

2）负责把最新需求及时传达到测试人员

3）保证测试进度与开发进度一致性

4）负责与项目组长及时确认最新需求


4、测试人员

1）负责更改测试用例，保证用例与需求同步

2）调控测试进度，保证任务的正常完成


5、项目经理

1）参与需求修改的评审工作

2）最终确认需求是否进行修改


6、配置管理员

1）负责更新需求文档，记录需求更改记录

2）负责需求变更信息的发布与跟踪

四、需求变更处理流程图

需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图：

1、需求变更流程(客户提出需求变更)

1）执行条件：

客户提出需求变更


          图：需求变更流程(客户提出需求变更)

2）流程说明：

需求来源：客户提交相关需求变更


审核需求变更：评估如果实现该需求，需要的时间、人力成本多少；并评估对项目工期影响有多大？判断那些需求能够目前解决，那些需要留到下一版本解决。最后输出一份审核确认表反馈给客户，和客户进行商讨。参与评审的人员要包含项目经理，项目组长，测试组长，市场人员。


配置管理员：对变更需求进行记录，需求文档进行更新，并通知相关人员


项目组长：负责调整相关开发进度表，评估任务时间，分发给相关开发人员


测试组长：根据变更需求和开发进度，对测试进度进行相对应调整，并修改测试需求分析书，分发需求更新给相关测试人员。测试人员对用例进行补充，修改。

客户提交的变更需求最后必须让客户进行签字确认。


2、需求变更流程（内部提出需求变更）

1）执行条件：


对项目进度不会影响严重

与客户原始需求无偏差


图：需求变更流程（内部提出需求变更）

2）流程说明：

内部需求变更来源：公司内部人员发现逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求不一致内容。


需求变更类型：需求有误、需求有遗漏、需求不明确。


需求变更审核：内部提交的需求应该经过项目经理，项目组长，测试组长，市场人员共同的确认才能确认是否修改。


项目组长：评审需求变更部分的工作量，判断需求变更的内容是否对开发进度有影响，如果需求变更对开发进度有影响，项目组长可以拒绝变更；将变更内容放 入下一版本进行修改，若市场人员认为必须在本版中进行修改，项目组长可以将变更的内容提交给项目经理进行处理，并决定是否在本版中进行修改。


需求信息发布：经过需求人员和项目组长的沟通、协调确定在本版中进行修改的需求变更，需求人员需要将变更内容的信息，以邮件方式通知相关人员。


配置管理员：对需求变更进行备案。


开发，测试：开发、测试人员接收到需求变更内容后首先审核设计文档和测试文档，修改变更的地方。并根据变更后的文档进行开发和测试。

五、附件
客户需求确认单

文档名称
        
 

    
文档摘要
        
 

    
客户确认
        
 

    


经办人签字：     单位公章：        确认日期：

转载于:https://www.cnblogs.com/hlearning/archive/2009/02/24/hjj.html