一、rootkit简介
rootkit是
Linux平台下最常见的一种木马后门工具，它主要通过替换系统文件来达到入侵和和隐蔽的目的，这种木马比普通木马后门更加危险和隐蔽，普通的检测工具和检查手段很难发现这种木马。rootkit攻击能力极强，对系统的危害很大，它通过一套工具来建立后门和隐藏行迹，从而让攻击者保住权限，以使它在任何时候都可以使用root权限登录到系统。
rootkit主要有两种类型：文件级别和内核级别，下面分别进行简单介绍。
1、文件级别rootkit
文件级别的rootkit一般是通过程序漏洞或者系统漏洞进入系统后，通过修改系统的重要文件来达到隐藏自己的目的。在系统遭受rootkit攻击后，合法的文件被木马程序替代，变成了外壳程序，而其内部是隐藏着的后门程序。通常容易被rootkit替换的系统程序有login、ls、ps、ifconfig、du、find、netstat等，其中login程序是最经常被替换的，因为当访问Linux时，无论是通过本地登录还是远程登录，/bin/login程序都会运行，系统将通过/bin/login来收集并核对用户的账号和密码，而rootkit就是利用这个程序的特点，使用一个带有根权限后门密码的/bin/login来替换系统的/bin/login，这样攻击者通过输入设定好的密码就能轻松进入系统。此时，即使系统管理员修改root密码或者清除root密码，攻击者还是一样能通过root用户登录系统。攻击者通常在进入Linux系统后，会进行一系列的攻击动作，最常见的是安装嗅探器收集本机或者网络中其他服务器的重要数据。在默认情况下，Linux中也有一些系统文件会监控这些工具动作，例如ifconfig命令，所以，攻击者为了避免被发现，会想方设法替换其他系统文件，常见的就是ls、ps、ifconfig、du、find、netstat等。如果这些文件都被替换，那么在系统层面就很难发现rootkit已经在系统中运行了。
这就是文件级别的rootkit，对系统维护很大，目前最有效的防御方法是定期对系统重要文件的完整性进行检查，如果发现文件被修改或者被替换，那么很可能系统已经遭受了rootkit入侵。检查件完整性的工具很多，常见的有Tripwire、 aide等，可以通过这些工具定期检查文件系统的完整性，以检测系统是否被rootkit入侵。
2、内核级别的rootkit
内核级rootkit是比文件级rootkit更高级的一种入侵方式，它可以使攻击者获得对系统底层的完全控制权，此时攻击者可以修改系统内核，进而截获运行程序向内核提交的命令，并将其重定向到入侵者所选择的程序并运行此程序，也就是说，当用户要运行程序A时，被入侵者修改过的内核会假装执行A程序，而实际上却执行了程序B。
内核级rootkit主要依附在内核上，它并不对系统文件做任何修改，因此一般的检测工具很难检测到它的存在，这样一旦系统内核被植入rootkit，攻击者就可以对系统为所欲为而不被发现。目前对于内核级的rootkit还没有很好的防御工具，因此，做好系统安全防范就非常重要，将系统维持在最小权限内
工作，只要攻击者不能获取root权限，就无法在内核中植入rootkit。
二、rootkit后门检测工具chkrootkit
chkrootkit是一个Linux系统下查找并检测rootkit后门的工具，它的官方址: http://www.chkrootkit.org/。 chkrootkit没有包含在官方的CentOS源中，因此要采取手动编译的方法来安装，不过这种安装方法也更加安全。下面简单介绍下chkrootkit的安装过程。
1.准备gcc编译环境
对于CentOS系统，需要安装gcc编译环境，执行下述三条命令：
[root@server ~]# yum -y install gcc
[root@server ~]# yum -y install gcc-c++
[root@server ~]# yum -y install make
2、安装chkrootkit
为了安全起见，建议直接从官方网站下载chkrootkit源码，然后进行安装，操作如下：
[root@server ~]# tar zxvf chkrootkit.tar.gz
[root@server ~]# cd chkrootkit-*
[root@server ~]# make sense
# 注意，上面的编译命令为make sense
[root@server ~]# cd ..
[root@server ~]# cp -r chkrootkit-* /usr/local/chkrootkit
[root@server ~]# rm -rf chkrootkit-*
3、使用chkrootkit
安装完的chkrootkit程序位于/usr/local/chkrootkit目录下，执行如下命令即可显示chkrootkit的详细用法：
[root@server chkrootkit]# /usr/local/chkrootkit/chkrootkit -h
chkrootkit各个参数的含义如下所示。
参数含义
-h显示帮助信息
-v显示版本信息
-ddebug模式，显示检测过程的相关指令程序
-q安静模式，只显示有问题的内容
-x高级模式，显示所有检测结果
-r dir设置指定的目录为根目录
-p dir1:dir2:dirN指定chkrootkit检测时使用系统命令的目录
-n跳过NFS连接的目录
chkrootkit的使用比较简单，直接执行chkrootkit命令即可自动开始检测系统。下面是某个系统的检测结果：
[root@server chkrootkit]# /usr/local/chkrootkit/chkrootkit Checking `ifconfig'... INFECTED Checking `ls'... INFECTED Checking `login'... INFECTED Checking `netstat'... INFECTED Checking `ps'... INFECTED Checking `top'... INFECTED Checking `sshd'... not infected Checking `syslogd'... not tested Checking `tar'... not infected Checking `tcpd'... not infected Checking `tcpdump'... not infected Checking `telnetd'... not found |
从输出可以看出，此系统的ifconfig、ls、login、netstat、ps和top命令已经被感染。针对被感染rootkit的系统，最安全而有效的方法就是备份数据重新安装系统。
4、chkrootkit的缺点
chkrootkit在检查rootkit的过程中使用了部分系统命令，因此，如果服务器被黑客入侵，那么依赖的系统命令可能也已经被入侵者替换，此时chkrootkit的检测结果将变得完全不可信。为了避免chkrootkit的这个问题，可以在服务器对外开放前，事先将chkrootkit使用的系统命令进行备份，在需要的时候使用备份的原始系统命令让chkrootkit对rootkit进行检测。这个过程可以通过下面的操作实现：
[root@server ~]# mkdir /usr/share/.commands
[root@server ~]# cp `which --skip-alias awk cut echo find egrep id head ls netstat ps strings sed uname` /usr/share/.commands
[root@server ~]# /usr/local/chkrootkit/chkrootkit -p /usr/share/.commands/
[root@server share]# cd /usr/share/
[root@server share]# tar zcvf commands.tar.gz .commands
[root@server share]# rm -rf commands.tar.gz
上面这段操作是在/usr/share/下建立了一个.commands隐藏文件，然后将chkrootkit使用的系统命令进行备份到这个目录下。为了安全起见，可以将.commands目录压缩打包，然后下载到一个安全的地方进行备份，以后如果服务器遭受入侵，就可以将这个备份上传到服务器任意路径下，然后通过chkrootkit命令的“-p”参数指定这个路径进行检测即可。
三、rootkit后门检测工具RKHunter
RKHunter是一款专业的检测系统是否感染rootkit的工具，它通过执行一系列的脚本来确认服务器是否已经感染rootkit。在官方的资料中，RKHunter可以作的事情有：
MD5校验测试，检测文件是否有改动
检测rootkit使用的二进制和系统工具文件
检测特洛伊木马程序的特征码
检测常用程序的文件属性是否异常
检测系统相关的测试
检测隐藏文件
检测可疑的核心模块LKM
检测系统已启动的监听端口
下面详细讲述下RKHunter的安装与使用。
1、安装RKHunter
RKHunter的官方网页地址为：http://www.rootkit.nl/projects/rootkit_hunter.html，建议从这个网站下载RKHunter，这里下载的版本是rkhunter-1.4.0.tar.gz。RKHunter的安装非常简单，过程如下：
[root@server ~]# ls
rkhunter-1.4.0.tar.gz
[root@server ~]# pwd
/root
[root@server ~]# tar -zxvf rkhunter-1.4.0.tar.gz
[root@server ~]# cd rkhunter-1.4.0
[root@server rkhunter-1.4.0]# ./installer.sh --layout default --install
这里采用RKHunter的默认安装方式，rkhunter命令被安装到了/usr/local/bin目录下。
2、使用rkhunter指令
rkhunter命令的参数较多，但是使用非常简单，直接运行rkhunter即可显示此命令的用法。下面简单介绍下rkhunter常用的几个参数选项。
[root@server ~]#/usr/local/bin/rkhunter–help
Rkhunter常用参数以及含义如下所示。
参数 含义
-c, –check必选参数，表示检测当前系统
–configfile <file>使用特定的配置文件
–cronjob作为cron任务定期运行
–sk, –skip-keypress自动完成所有检测，跳过键盘输入
–summary显示检测结果的统计信息
–update检测更新内容
-V, –version显示版本信息
–versioncheck检测最新版本
下面是通过rkhunter对某个系统的检测示例：
[root@server rkhunter-1.4.0]# /usr/local/bin/rkhunter -c [ Rootkit Hunter version 1.4.0 ] #下面是第一部分，先进行系统命令的检查，主要是检测系统的二进制文件，因为这些文件最容易被rootkit攻击。显示OK字样表示正常，显示Warning表示有异常，需要引起注意，而显示“Not found”字样，一般无需理会 Checking system commands... Performing 'strings' command checks Checking 'strings' command [ OK ] Performing 'shared libraries' checks Checking for preloading variables [ None found ] Checking for preloaded libraries [ None found ] Checking LD_LIBRARY_PATH variable [ Not found ] Performing file properties checks Checking for prerequisites [ Warning ] /usr/local/bin/rkhunter [ OK ] /sbin/chkconfig [ OK ] ....(略).... [Press <ENTER> to continue] #下面是第二部分，主要检测常见的rootkit程序，显示“Not found”表示系统未感染此rootkit Checking for rootkits... Performing check of known rootkit files and directories 55808 Trojan - Variant A [ Not found ] ADM Worm [ Not found ] AjaKit Rootkit [ Not found ] Adore Rootkit [ Not found ] aPa Kit [ Not found ] Apache Worm [ Not found ] Ambient (ark) Rootkit [ Not found ] Balaur Rootkit [ Not found ] BeastKit Rootkit [ Not found ] beX2 Rootkit [ Not found ] BOBKit Rootkit [ Not found ] ....(略).... [Press <ENTER> to continue] |
今天我想对一个Greenfield项目上可以采用的各种性能优化策略作个对比。换言之，该项目没有之前决策强加给它的各种约束限制，也还没有被优化过。
具体来说，我想比较的两种优化策略是优化
MySQL和缓存。提前指出，这些优化是正交的，唯一让你选择其中一者而不是另一者的原因是他们都耗费了资源，即开发时间。
优化MySQL
优化MySQL时，一般会先查看发送给mysql的查询语句，然后运行explain命令。稍加审查后很常见的做法是增加索引或者对模式做一些调整。
优点
1、一个经过优化的查询对于所有使用应用的用户来说都是快速的。因为索引通过对数复杂度的速度来检索数据（又名分制，正如你搜索一个电话簿一样，逐步缩小搜索范围），而且随着数据量的递增也能维持良好的性能。对一个未经索引化的查询的结果做缓存随着数据的增长有时候则可能会表现得更差。随着数据的增长，那些未命中缓存的用户可能会得到很糟糕的体验，这样的应用是不可用的。
2、优化MySQL不需要担心缓存失效或者缓存数据过期的问题。
3、优化MySQL可以简化技术架构，在开发环境下复制和
工作会更加容易。
缺点
1、有一些查询不能光通过索引得到性能上的改善，可能还需要改变模式，在某些情况下这对于一些应用可能会很麻烦。
2、有些模式的更改可能用于反规范化（数据备份）。尽管对于DBA来说，这是一项常用的技术，它需要所有权以确保所有的地方都是由应用程序更新，或需要安装触发器来保证这种变化。
3、一些优化手段可能是MySQL所特有的。也就是说，如果底层软件被移植到多个
数据库上工作，那么很难确保除了增加索引外一些更复杂的优化技术可以通用。
使用缓存
这种优化需要人来分析应用的实际情况，然后将处理代价昂贵的部分从MySQL中剥离出来用第三方缓存替代，比如memcached或Redis。
优点
1、缓存对于一些MySql自身很难优化的查询来说会工作地很好，比如大规模的聚合或者分组的查询。
2、缓存对于提高系统的吞吐率来说可能是个不错的方案。比如对于多人同时访问应用时响应速度很慢的情况。
3、缓存可能更容易构建在另一个应用之上。比如：你的应用可能是另一个用MySQL存储数据的软件包的前端，而要对这个软件包做任何数据库方面的改动都非常难。
缺点
1、如果数据对外提供多种存取范式（例如，在不同的页面上用不同的形式展示），那么让缓存过期或者更新可能会很难，同时/或者可能需要容忍已过期的数据。一个可行的替代方案是设计一套更加精细的缓存机制，当然它也有缺点，即多次获取缓存会增加时延。
2、缓存一个产生代价昂贵的对象对于那些未命中缓存的用户（见优化MySQL的优势#1）而言可能会产生潜在的性能差异。一些好的性能实践表明你应该尽量缩小用户之间的差异性，而不仅仅是平均化（缓存倾向于这么做）。
3、幼稚的缓存实现无力应对一些微妙的漏洞，比如雪崩效应。就在上周我帮助了一个人，他的数据库服务器被多个试图同时再生同样缓存内容的用户请求冲垮。正确的策略是引入一定级别的锁来将缓存再生的请求序列化。
总结
一般情况下，我会建议用户先对MySQL进行优化，因为这是我认为开始阶段最合适的解决方案。但长期来看，大部分应用都会有一些用例需要一定程度上同时实现以上这些方案。
为了方便编写出线程安全的程序，Java里面提供了一些线程安全类和并发工具，比如：同步容器、并发容器、阻塞队列、Synchronizer（比如CountDownLatch）。今天我们就来讨论下同步容器。
一.为什么会出现同步容器？
在Java的集合容器框架中，主要有四大类别：List、Set、Queue、Map。
List、Set、Queue接口分别继承了Collection接口，Map本身是一个接口。
注意Collection和Map是一个顶层接口，而List、Set、Queue则继承了Collection接口，分别代表数组、集合和队列这三大类容器。
像ArrayList、LinkedList都是实现了List接口，HashSet实现了Set接口，而Deque（双向队列，允许在队首、队尾进行入队和出队操作）继承了Queue接口，PriorityQueue实现了Queue接口。另外LinkedList（实际上是双向链表）实现了了Deque接口。
像ArrayList、LinkedList、HashMap这些容器都是非线程安全的。
如果有多个线程并发地访问这些容器时，就会出现问题。
因此，在编写程序时，必须要求程序员手动地在任何访问到这些容器的地方进行同步处理，这样导致在使用这些容器的时候非常地不方便。
所以，Java提供了同步容器供用户使用。
二.Java中的同步容器类
在Java中，同步容器主要包括2类：
1）Vector、Stack、HashTable
2）Collections类中提供的静态工厂方法创建的类
Vector实现了List接口，Vector实际上就是一个数组，和ArrayList类似，但是Vector中的方法都是synchronized方法，即进行了同步措施。
Stack也是一个同步容器，它的方法也用synchronized进行了同步，它实际上是继承于Vector类。
HashTable实现了Map接口，它和HashMap很相似，但是HashTable进行了同步处理，而HashMap没有。
Collections类是一个工具提供类，注意，它和Collection不同，Collection是一个顶层的接口。在Collections类中提供了大量的方法，比如对集合或者容器进行排序、查找等操作。最重要的是，在它里面提供了几个静态工厂方法来创建同步容器类，如下图所示：
三.同步容器的缺陷
从同步容器的具体实现源码可知，同步容器中的方法采用了synchronized进行了同步，那么很显然，这必然会影响到执行性能，另外，同步容器就一定是真正地完全线程安全吗？不一定，这个在下面会讲到。
我们首先来看一下传统的非同步容器和同步容器的性能差异，我们以ArrayList和Vector为例：
1.性能问题
我们先通过一个例子看一下Vector和ArrayList在插入数据时性能上的差异：
public static void main(String[] args) throws InterruptedException { ArrayList<Integer> list = new ArrayList<Integer>(); Vector<Integer> vector = new Vector<Integer>(); long start = System.currentTimeMillis(); for(int i=0;i<100000;i++) list.add(i); long end = System.currentTimeMillis(); System.out.println("ArrayList进行100000次插入操作耗时："+(end-start)+"ms"); start = System.currentTimeMillis(); for(int i=0;i<100000;i++) vector.add(i); end = System.currentTimeMillis(); System.out.println("Vector进行100000次插入操作耗时："+(end-start)+"ms"); } } |
这段代码在我机器上跑出来的结果是：
进行同样多的插入操作，Vector的耗时是ArrayList的两倍。
这只是其中的一方面性能问题上的反映。
另外，由于Vector中的add方法和get方法都进行了同步，因此，在有多个线程进行访问时，如果多个线程都只是进行读取操作，那么每个时刻就只能有一个线程进行读取，其他线程便只能等待，这些线程必须竞争同一把锁。
因此为了解决同步容器的性能问题，在Java 1.5中提供了并发容器，位于java.util.concurrent目录下，并发容器的相关知识将在下一篇文章中讲述。
2.同步容器真的是安全的吗？
也有有人认为Vector中的方法都进行了同步处理，那么一定就是线程安全的，事实上这可不一定。看下面这段代码：
public class Test { static Vector<Integer> vector = new Vector<Integer>(); public static void main(String[] args) throws InterruptedException { while(true) { for(int i=0;i<10;i++) vector.add(i); Thread thread1 = new Thread(){ public void run() { for(int i=0;i<vector.size();i++) vector.remove(i); }; }; Thread thread2 = new Thread(){ public void run() { for(int i=0;i<vector.size();i++) vector.get(i); }; }; thread1.start(); thread2.start(); while(Thread.activeCount()>10) { } } } } |
在我机器上运行的结果：
正如大家所看到的，这段代码报错了：数组下标越界。
也许有朋友会问：Vector是线程安全的，为什么还会报这个错？很简单，对于Vector，虽然能保证每一个时刻只能有一个线程访问它，但是不排除这种可能：
当某个线程在某个时刻执行这句时：
for(int i=0;i<vector.size();i++)
vector.get(i);
假若此时vector的size方法返回的是10，i的值为9
然后另外一个线程执行了这句：
for(int i=0;i<vector.size();i++)
vector.remove(i);
将下标为9的元素删除了。
那么通过get方法访问下标为9的元素肯定就会出问题了。
因此为了保证线程安全，必须在方法调用端做额外的同步措施，如下面所示：
public class Test { static Vector<Integer> vector = new Vector<Integer>(); public static void main(String[] args) throws InterruptedException { while(true) { for(int i=0;i<10;i++) vector.add(i); Thread thread1 = new Thread(){ public void run() { synchronized (Test.class) { //进行额外的同步 for(int i=0;i<vector.size();i++) vector.remove(i); } }; }; Thread thread2 = new Thread(){ public void run() { synchronized (Test.class) { for(int i=0;i<vector.size();i++) vector.get(i); } }; }; thread1.start(); thread2.start(); while(Thread.activeCount()>10) { } } } } |
3. ConcurrentModificationException异常
在对Vector等容器并发地进行迭代修改时，会报ConcurrentModificationException异常，关于这个异常将会在后续文章中讲述。
但是在并发容器中不会出现这个问题。
领域驱动设计的核心－Domain Model（领域模型），这个大家都知道，可是，上次关于领域模型的设计分享，要追溯到两个月之前了，这中间搞了一些有的没有的东西，比如纠结于仓储等，说这些东西不重要，其实也蛮重要的，因为它是一个完整应用程序所必须要考虑的东西（Demo 除外），但是相对于领域模型，在领域驱动设计中它才是最重要的。
这篇博文我分享的思路是：一个具体的业务场景，一个现实项目的业务需求变化，应用领域驱动设计，看我是如何应对的？？？
注意：上面我用的是问号，所以，必不可少的会有一些“坑”，大家在读的过程中，要“小心”哦。
具体业务场景
具体业务场景？没错，就是我们熟悉的博客园站内短消息，详见：[网站公告]8月17日14:00-15:00（周日下午）发布新版站内短消息。
上面那次版本发布，已经过去一个多月的时间了，说是“新版”，其实就是重写之前短消息的代码，然后用领域驱动设计的思想去实现，界面换了个“位置”，功能和原来的没有太大变化。发布之后，出现了很多的问题，比如前端界面、
数据库优化、代码不规范等等。有些技术问题可以很快的解决，比如数据库的索引优化等，但是，有些问题，比如 SELECT FileName，因为程序代码是基于领域驱动设计的思想去实现的，那你就不能直接去写select filename1,filename2,filename2... from tablename这样的
SQL 代码，所以实现起来需要思考很多，这个是比较头疼的。
我为什么会说这些问题？因为这些问题，只有在实际应用项目中才会出现，你搞一个领域驱动设计的简单 Demo，会出现数据库性能问题吗？肯定不会，那也就不会去思考仓储的一些问题，更谈不上一些改变了，所以领域驱动设计的推进，只有你去实际用它，而不只是做一些演示的东西，在实际应用中，去发现问题并解决问题，我觉得这样才会更有价值。
关于短消息这个业务场景，其实我之前写的一些领域驱动设计博文，都是围绕着它展开的，很多园友认为这个业务场景是我虚构的，就像之前 netfocus 兄问我：“你说的这个短消息是不是类似于博客园的短消息？”，我回答：“是的！”，呵呵。后来我发现虚构的业务场景，有时候很难说明问题，比如之前 Jesse Liu 在一篇博文中，提到一个用户注册问题，关于这个问题，其实讨论了很久，但最后结果呢？我认为是没有结果，因为业务场景是虚构的，所以就会造成“公说公有理，婆说婆有理”的情况，以至于大家很难达成一些共识的点。
博客园短消息的业务场景，真实的不能再真实了，毕竟大家都在实际用，我就不多说了，就是简单的一个用户和另一个用户发消息，然后进行回复什么的，在之前的一些博文中也有说明，大家可以参考下：我的“第一次”，就这样没了：DDD（领域驱动设计）理论结合实践。
业务需求变化
现在的博客园短消息，为了方便用户看到之前回复的一些内容，我们在底部增加了“=== 下面是回复信息 === ”，示意图：
这种方式其实就是把之前回复内容放到新消息内容里面，然后作为一个新消息进行发送，除去消息内容“冗余”不说，还有个弊端就是，如果两个人回复的次数很多，你会发现，消息内容会变成“一坨XX”，不忍直视。
后来，我们也看不下去了，所以决定做一些改变，仿照 iMessage 或 QQ 那种消息模式，示意图：
这种方式和上面那“一坨XX”形成了鲜明对比，对话模式的消息显示，使用户体验度更好，就像两个人面对面说话一样，很轻松也很简洁，我想我们这种方式的改变，会让你“爱上”我们短消息的。
对，没错，这就是业务需求变化，我们在应用程序开发的过程中，需求是一直不断变化的，我们要做的就是不断完善和适应这种需求变化，当然每个人应对的方式不同，下面看一下我“愚蠢”的应对。
“愚蠢”的应对
我个人觉得这一节点内容非常重要，在领域驱动设计的过程中，也是很多人常掉进的“坑”，因为我们长期受“脚本模式”的影响，在业务需求变化后，应用程序需要做出调整，但是你会不自觉的“跑偏”，这就偏离了领域驱动设计的思想，最后使你的应用程序变得“不伦不类”。
当时为了很快的在应用程序中实现这种功能，我说的是技术上实现，完全没有用领域驱动的思想去考虑，我是怎么思考的呢？先从 UI 上考虑，主要是两个界面：
消息列表：收件箱、发件箱和未读消息列表。
消息详情：消息详情页。
消息列表实现
之前短消息不管发送，回复，还是转发，都是作为一个新短消息进行发送的，“消息的上下文”作为一个消息的附属体，放在新短息内容中，也就是说，你把之前发送的消息删掉，在新回复的短消息内容中，是仍然看到之前发送内容的，这个在列表的显示就是单独进行显示，但新的需求变化就不能这样进行操作了，这个就有点像两个人聊一个话题，里面都是我们针对这个话题进行讨论的内容，在列表显示的时候，首先，标题显示就是这个话题的标题，就像邮件回复一样，我们可以加上“消息标题(3)”，这个“3”，就表示两个人回复了3次。
其实用话题这个逻辑是有些不准确的，毕竟我们是短消息项目，我们可以这样想，我给 netfocus 发了一个标题为：“打个招呼”，内容为：“hello netfocus”的消息，然后他给我进行了回复：“hello xishuai”，可能后面还有一些消息回复内容，但都是针对我发的第一条消息回复，也就是说下面都是回复内容，那这个在消息列表显示的时候，标题就显示为“打个招呼(3)”，后面时间为最新回复时间，示意图：
上面是 netfocus 的收件箱示意图，收件箱列表显示的逻辑就是以发件人和标题为一个标识，比如 Jesse Liu 也给 netfocus 发了一个“打个招呼”的消息，虽然标题一样，但发件人不一样，所以列表显示两条消息。
那代码怎么实现这个功能呢？贴出代码看看：
public async Task<IEnumerable<MessageListDTO>> GetInbox(Contact reader, PageQuery pageQuery) { var query = efContext.Context.Set<Message>() .Where(new InboxSpecification(reader).GetExpression()).GroupBy(m => new { m.Sender.ID, m.Title }).Select(m => m.OrderByDescending(order => order.ID).FirstOrDefault()); int skip = (pageQuery.PageIndex - 1) * pageQuery.PageSize; int take = pageQuery.PageSize; return await query.SortByDescending(sp => sp.ID).Skip(skip).Take(take) .Project().To<MessageListDTO>().ToListAsync();//MessageListDTO 为上一版本遗留问题（Select FileName），暂时没动。 } |
GetInbox 是 MessageRepository 中的操作，其实原本收件箱的代码不是这样处理的，你会看到，现在的代码其实就是 Linq 的代码拼接，我当时这样处理就是为了可以方便查询，现在看确实像“一坨XX”，代码我就不多说了，上面列表显示功能是可以实现的，除去回复数显示，其实你会看到，这个就是对发件人和标题进行筛选，选取发送时间最新的那一条消息。
虽然这段 Linq 代码看起来很“简单”，但是如果你跟踪一下生成的 SQL 代码，会发现它是非常的臃肿，没办法，为了实现功能，然后就不得不去优化数据库，主要是对索引的优化，这个当时优化了好久，也没有找到合适的优化方案，最后不得不重新思考这样做是不是不合理？这完全是技术驱动啊，后来，我发现，在领域驱动设计的道路上，我已经完全“跑偏”了。
消息详情页实现
业务需求的变化，其实主要是消息详情页的变化，从上面那张消息详情页示意图就可以看出，刚才上面说了，收件箱列表显示是对标题和发件人的筛选，其实详情页就是通过标题和发件人找出回复消息，然后通过发送时间降序排列。具体操作是，在收件箱中点击一条消息，然后通过这条消息和发件人去仓储中找这条消息的回复消息，示例代码：
public async Task<IEnumerable<Message>> GetMessages(Message message, Contact reader) { if (message.Recipient.ID == reader.ID) { return await GetAll(Specification<Message>.Eval(m => m.Title == message.Title && ((m.Sender.ID == message.Sender.ID && m.Recipient.ID == message.Recipient.ID && (m.DisplayType == MessageDisplayType.OutboxAndInbox || m.DisplayType == MessageDisplayType.Inbox)) || (m.Recipient.ID == message.Sender.ID && m.Sender.ID == message.Recipient.ID && (m.DisplayType == MessageDisplayType.OutboxAndInbox || m.DisplayType == MessageDisplayType.Outbox)))), sp => sp.ID, SortOrder.Ascending).ToListAsync(); } else { return await GetAll(Specification<Message>.Eval(m => m.Title == message.Title && ((m.Sender.ID == message.Sender.ID && m.Recipient.ID == message.Recipient.ID && (m.DisplayType == MessageDisplayType.OutboxAndInbox || m.DisplayType == MessageDisplayType.Outbox)) || (m.Recipient.ID == message.Sender.ID && m.Sender.ID == message.Recipient.ID && (m.DisplayType == MessageDisplayType.OutboxAndInbox || m.DisplayType == MessageDisplayType.Inbox)))), sp => sp.ID, SortOrder.Ascending).ToListAsync(); } } |
不知道你是否能看懂，反正我现在看这段代码是需要思考一下的，呵呵。消息详情页基本上就是这样实现的，还有一些是在应用层获取“点击消息”，UI 中消息显示判断等一些操作。
消息发送、回复、销毁等实现
其实除了上面列表和详情页的变化，消息发送、回复和销毁实现也需要做出调整，因为消息领域模型没有任何变动，发送消息还是按照之前的发送逻辑，所以发送消息是没有变化的，回复消息也没有大的变化，只不过回复的时候需要获取一下消息标题，因为除了第一条发送消息需要填写标题，之后的消息回复是不需要填写标题的，需要添加的只不过是消息内容。消息销毁的改动相对来说大一点，因为之前都是独立的消息发送，所以可以对每个独立的消息进行销毁操作，但是从上面消息详情页示意图中可以看到，独立的消息是不能销毁的，只能销毁这个完整的消息，也就是详情页最下面的删除按钮，示例代码：
public async Task<OperationResponse> DeleteMessage(int messageId, string readerLoginName) { IContactRepository contactRepository = new ContactRepository(); IMessageRepository messageRepository = new MessageRepository(); Message message = await messageRepository.GetByKey(messageId); if (message == null) { return OperationResponse.Error("抱歉！获取失败！错误：消息不存在"); } Contact reader = await contactRepository.GetContactByLoginName(readerLoginName); if (reader == null) { return OperationResponse.Error("抱歉！删除失败！错误：操作人不存在"); } if (!message.CanRead(reader)) { throw new Exception("抱歉！获取失败！错误：没有权限删除"); } message.DisposeMessage(reader); var messages = await messageRepository.GetMessages(message, reader); foreach (Message item in messages) { item.DisposeMessage(reader); messageRepository.Update(item); } await messageRepository.Context.Commit(); return OperationResponse.Success("删除成功"); } |
这个是应用层中消息销毁操作，可以看到应用层的这个操作代码很凌乱，这就是为了实现而实现的代价，除了消息销毁，还有一个操作就是消息状态设置，也就是消息“未读”和“已读”设置，这个代码实现在应用层 ReadMessage 操作中，代码更加凌乱，我就不贴出来了，和消息销毁操作比较类似，消息状态设置只不过设置一些状态而已。
回到原点的一些思考
为什么我会详细描述我当时实现的思路？其实就是想让你和我产生一些共鸣，上面的一些实现操作，完全是为了实现而实现，不同的应用场景下的业务需求变化是不同的，但思考的方式一般都是想通的，也就是说如果你能正确应对这个业务需求变化，那换一个应用场景，你照样可以应对，如果你不能正确应对，那领域驱动设计就是“空头白话”，为什么？因为领域驱动设计就是更好的应对业务需求变化的。
其实上面的需求变化，我们已经变相的实现了，只不过没有发布出来，就像一个多月之前的发布公告中所说，“Does your code look like this？”，如果按照这种方式实现了，那以后的短消息代码，就是那一坨面条，惨不忍睹。
回到原点的一些思考，其实就是回到领域模型去看待这次的业务需求变化，关于这部分内容，我还没有准确的做法，这边我说一下自己的理解：
业务需求变化，领域模型变化了吗？
首先，在之前的实现中，消息列表显示这部分内容，应该是应用层中体现的，所以在领域模型中可以暂时不考虑，这个在仓储中应该着重思考下。那领域模型变化了什么？先说发送消息，这个变化了吗？我觉得没有，还是点对点的发送一个消息，这个之前是用 SendSiteMessageService 领域服务实现的，逻辑也没有太大的变化，那回复消息呢？其实我觉得这是最大的一个变化，如果你看之前的回复代码，我是没有在领域模型中实现回复消息操作的，为什么？因为我当时认为，回复消息其实也是发送消息，所以在应用层中回复消息操作，其实就是调用的 SendSiteMessageService 领域服务，这个现在看来，是不应该这样实现的。
我们先梳理一下回复消息这个操作的处理流程，这个其实上面有过分析，除了第一条消息是发送以外，之后的消息都是回复操作，这就要有一个标识，用来说明这条消息是回复的那一条发送消息，那这个怎么来设计呢？回复消息设计成实体好？还是值对象好？我个人觉得，应该设计成实体，原因大家想想就知道了，虽然它依附于发送消息存在，但是它也是唯一的，比如一个人给另外两个人回复同样内容的消息，那这两个回复消息应该都是独立存在的，那这个依附关系怎么处理呢？我们可以在消息实体中添加一个标识，用来表示它回复的是那条消息。
上面这个确定之后，那我们如何实现回复消息操作呢？我们可以用一个领域服务实现，比如 ReplySiteMessageService，用来处理回复消息的一些操作，这个和 SendSiteMessageService 领域服务可能会有些不同，比如一个人 1 天只能发送 200 条消息，但是这个逻辑我们就不能放在回复消息领域服务中，回复只是针对一个人的回复，所以这个可以不做限制，发送是针对任何人的，为了避免广告推广，这个我们必须要做一个发送限制，当然具体实现，就要看需求的要求了。
除了回复消息这个变化，说多一点，消息状态（未读和已读）和消息销毁，这个可能也会有细微的变化，比如消息状态，在消息列表中打开一个消息，其实就是把这条消息的回复内容都设置成已读了，我们之前的设计是针对独立的消息状态，也就是说每个消息都有一个消息状态，按照这种方式，其实我们可以把这个状态放在发送消息实体中，如果有人回复了，那这个消息状态就是设置为未读，回复消息没有任何状态，如果这样设计的话，有点像值对象的感觉，可以从消息实体中独立出来一个回复消息值对象，当然这只是我的一种思路。消息销毁和这个消息状态比较类似，这边就不多说了，除了这两个变化，其实还有一些细节需要考虑，这个只能在实现中进行暴露出来了。
对象读取的额外思考
这个其实是我看了仓储那惨不忍睹的实现代码，所引起的一些思考，你可以读一下，这样的一篇博文：你正在以错误的方式使用ORM。
仓储在领域驱动设计的作用，可以看作是实体的存储仓库，我们获取实体对象就要经过仓储，仓储的实现可以是任何方式，但传输对象必须是聚合根对象，这个在理论中没有什么问题，但是在实际项目中，我们从仓储中获取对象，一般有两种用途：
用于领域模型中的一些验证操作。
用于应用层中的 DTO 对象转化。
第一种没有什么问题，但是第二种，这个就不可避免的造成性能问题，也就是上面文中 Jimmy（AutoMapper 作者）所说的 Select N 问题，这个我之前也遇到过，最后的解决方式，我是按照他在 AutoMapper 映射的一些扩展，也就是上面代码中的 Project().To()，但这样就不可避免的违背了领域驱动设计中仓储的一些思想。
关于这个内容，我不想说太多，重点是上面领域模型的思考，仓储的问题，我是一定要做一些改变的，因为它现在的实现，让强迫症的我感觉到非常不爽，不管是 CQRS、ES、还是六边形架构，总归先尝试实现再说，有问题不可怕，可怕的是不懂得改正。
写在最后
在领域驱动设计的道路上，有很多你意想不到的情况发生，稍微不注意，你就会偏离的大方向，很遗憾，我没有针对这次的业务需求变化，做出一些具体的实现，但我觉得意识到问题很重要，这篇博文分享希望能与你产生一些共鸣。
1：http://localhost/index.php?m=模块&c=控制器&a=操作方法 [get模式] 2：http://localhost/index.php/模块[模块文件夹]/控制器/操作方法 [pathinfo模式] 3：http://localhost/模块[模块文件夹]/控制器/操作方法 [rewite重写模式] 4：http://localhost/index.php?s=/模块[模块文件夹]/控制器/操作方法 [兼容模式] 具体的url模式 在ThinkPHP/conf/convention.php文件下 大概在138行 默认的是pathinfo模式 'URL_MODEL' => 1, // URL访问模式,可选参数0、1、2、3,代表以下四种模式： // 0 (普通模式); 1 (PATHINFO 模式); 2 (REWRITE 模式); 3 (兼容模式) 默认为PATHINFO 模式 5：具体修改访问模式如下： config.php是我们当前自己的项目配置文件,我们可以通过修改文件达到配置变量的目录, 这个文件在系统运行过程中会覆盖convertion.php的配置变量 因为：我们在新建控制的器的时候需要引入 include 'convertiion.php'; include 'config.php' 后引入的文件会把先引入的文件中的配置给覆盖掉~ 配置如下： <?php return array( //'配置项'=>'配置值' //配置URL模式 'URL_MODEL'=>0 //默认的为1 所以现在改为第一种get模式。 ); |
//把目前的tp框架的生成模式改变成为开发模式
define("APP_DEBUG", true);
快捷函数 U();
使用方法如下： U("模块/控制器/方法") 根据url模式来生成地址！
开发调试模式:系统要加载26文件
生成模式：系统只要加载很少的文件。
查看系统运行日志：可知道系统加载了多少文件
定义：在一个发声思考测试中，测试的参与者在执行任务行为时实时的说出自己脑子中所想的内容
这看上去是一个很简单的要求，但是在实际过程中要求一个测试者不停地说出自己所想是非常困难的，所以测试的实施者必须不断的提醒测试者。
进行一个基本的发声思考
可用性测试，只需要做3件事情
招募代表性用户
让他们执行有代表性的任务
闭上嘴听测试用户说
发声的好处
首先这个方法有一大堆优势。其中最重要的是，发声为想法提供了一个可见的窗口，透过窗口你可以发现用户到底是如何使用和看待你的设计的。特别的，你可以发现他们产生误解的地方，这些往往是需要进行重新设计的，所有引起误解的元素都必须改变。更重要的是，你可以从中发现为什么用户会产生误解，为什么其他的设计方式会更易用。
发声的好处还有
低花费。不需要特殊的仪器，只需要你坐在测试对象旁边记录他所说的话。收集到足够多数量的用户测试信息可能会花费一整天的时间，但这一定是值得的
可信度高。大多数的实验者都缺乏经验所以大多数时候测试都不能够按照最正确的方式进行。但是除非你严重干涉误导测试者，即使在不标准的测试中你依然能够获得大量有价值的发现。相比之下，定量的可用性研究对于方法的精确度要求的更加严格，很小的错误也可能导致研究结果出现巨大偏差。定量的研究往往也花费更高。
灵活度高。在开发的任意时期你都可以进行这样的测试，从纸上的原型到已经成型的原型。发声思考特别适合
敏捷式的开发模式。你可以运用这种方法测试任意形式的用户界面，虽然用发声的方式测试声音交互界面有点奇怪，但是你可以参考这篇
文章里关于进行有实力测试障碍的人的测试。不论是网站，软件，局域网，消费类产品，企业级软件，
移动设计，发声测试都可以运用，因为他只依赖于可以思考的用户
有说服力。最老练的开发者，傲慢的设计师，吝啬的总经理在直接面对消费者的时候态度都会变得温和。让他们坐下来听听在发声测试中用户的想法并不会花费他们太多的时间，并且有可能促使他们重视可用性。
简单易懂。
发声思考的问题
花费低和不容易出错是定性研究方法诸如发声思考的巨大优势。但他们不好的一面是除非你进行的是一个巨大昂贵的实验，否则是不能形成定量数据的。当然你可以选择做一个巨大昂贵的实验，但是我的建议是这些精力和经费投资在更多的设计迭代过程中更值得。
其他问题
不自然。除非测试者是个怪人，大多数普通人不会坐在那里自言自语一整天。所以想要让测试者在测试过程中保持自言自语其实是一个比较困难的过程。幸运的是来参加测试的人一般都会比较积极的配合，以至于有时可能忘记自己仅仅是在进行一项测试。
想法过滤。测试者被要求说出他们脑中呈现的第一印象，而不是说出经过了思考之后的分析结果。但是与此同时，大多数人希望自己表现的像个聪明人，于是他们更倾向于在说出自己所想之前先思考一番。千万不要陷入了这个陷阱，获得测试用户最原始的想法是非常重要的。所以一般情况下，实验者必须不断的提醒用户不断的说。
误导用户行为。指导和解释说明在测试过程中是必要的，但假如是一个不专业的实验者来进行，那么他给予的信息很可能会改变用户原本的行为。有误导存在的情况下，用户的行为是没有代表性的，更无法提供设计依据。至少，你必须能够识别出在哪些测试中用户的行为是被误导了的，作废这些观测结果。最糟糕的情况就是你不知道自己在哪些地方做错了，这样你提供给设计团队的意见很有可能就是错误的
不一定通用。只要你同时使用其他的方法，不通用事实上并不是一个真正的缺点。发声思考可以在大多数情况下使用，但也并非全部情况下通用。一旦你在可用性测试这方面有了一定的经验，你会有其他很多测试方法可以选择
不要因为这些问题就退缩，如果你还没有使用过这个方法，你可以现在就为自己正在进行的设计项目进行一次。这个方法是如此的简单易行，每周一次都是完全可行的。所以如果你这一周犯了错误，下一周你一定可以做的更好。
Menifest.xml中加入：
<application>中加入： <uses-library android:name="android.test.runner" /> <application>外面加入： <uses-permission android:name="android.permission.RUN_INSTRUMENTATION" /> <instrumentation android:name="android.test.InstrumentationTestRunner" android:targetPackage="name.feisky.android.test" android:label=" Test for my app"/> |
编写单元测试代码：必须继承自AndroidTestCase类 package name.feisky.android.test; import android.test.AndroidTestCase; import junit.framework.Assert; public class MyTest extends AndroidTestCase { private static final String Tag="MyTest"; } |
熟悉
测试理论的人都知道，路径覆盖是
白盒测试中一种很重要的方法，广泛应用于
单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢，能不能将其推而广之呢。一般而言，在单元测试中，路径就是指函数代码的某个分支，而实际上如果我们将软件系统的某个流程也看成路径的话，我们将可以尝试着用路径分析的方法来设计
测试用例。采用路径分析的方法设计测试用例有两点好处：一是降低了测试用例设计的难度，只要搞清了各种流程，就可以设计出高质量的测试用例来，而不用太多测试方面的经验；二是在测试时间较紧的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。
首先是将系统运行过程中所涉及到的各种流程图表化，可以先从最基本的流程入手，将流程抽象成为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，这样既可以逐渐加深对流程的理解，还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。
找出了所有的路径，下面的
工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高；二是路径的重要程度，如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。
为每条路径设定好优先级后，接下来的工作就是为每条路径选取测试数据，构造测试用例。一条路径可以对应多个测试用例，在选取测试数据时，可以充分利用边界值选取等方法，通过表格将各种测试数据的输入输出对应起来，这样就完成了测试用例的设计。
对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、
系统测试等后续测试过程中，希望能给大家一点启示。我会将自己尝试过的一些感受以及具体例子跟在本贴之后。
如果想让本方法很好的用在实际的工作中,那么流程就必须明确的规范的（就是有画出相应业务或者功能走向图）,这样就可以极大的加快了用例编写的速度和质量，但是如果碰到没有明确流程图的时候，可能会花不少的时间去捉摸功能点的流程走向问题，这又让工作进度慢了下来（流程不明确是因为需求没有明确表述和设计没有相应流程描述）,所以在实际工作中想使用这种方法来加快和改进测试用例的进度和质量，还要说服项目组尽可能的规范需求和设计的文档规范性，毕竟软件质量的控制不是我们一组人就能做到的。
拿到这个流程时，第一眼看上去，是不是有点晕晕的呢，确实如此，因为这不能称为标准的流程图，我们需要做一些改进，不妨事先约定，画流程图时，在有判定条件处，就往下走，而就往左走，以下是简化后的流程：
摘要: 鉴于cnblogs的排版问题，PDF格式下载点击这里。关键字驱动的过去和未来.pdf 版权声明：本文可以被转载，但是在未经本人许可前，不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载，请在转载是保留此版权声明，并保证本文的完整性。也请转贴者理解创作的辛劳，尊重作者的劳动成果。作者：陈雷 (Jackei)Blog：http://jack...
阅读全文
最近因为
工作需要在学习DB2数据库，本教程讲解DB2数据库在inux下的安装步骤。
安装前请查看 DB2版本和许可证 说明来增加了解，先弄明白改安装什么版本，这里我用的是最新的Express-C版本，这个版本是提供给个人
学习用的版本。
管理客户端从v9.7版本之后就不再带有控制中心了，而是使用 Data Studio Client。
Linux版本下的DB2数据库采用的官方免费版本，
操作系统用的CentOS6.2。
安装过程：
1、下载：db2_v101_linuxia32_expc.tar.gz
2、解压，解压完成后会在当前目录下有一个 ./expc 文件夹
[root@localhost opt]# tar -zxvf db2_v101_linuxia32_expc.tar.gz
发布地址： http://www.cnblogs.com/zxlovenet/p/3972766.html
3、进入这个目录
[root@localhost opt]# cd expc/
4、执行安装
[root@localhost expc]# ./db2_install
5、添加组和用户：
组（用户名）
db2iadm1(db2inst1) db2fadm1( db2fenc1） [root@localhost expc]# groupadd -g 2000 db2iadm1 [root@localhost expc]# groupadd -g 2001 db2fadm1 [root@localhost expc]# useradd -m -g db2iadm1 -d /home/db2inst1 db2inst1 [root@localhost expc]# useradd -m -g db2fadm1 -d /home/db2fenc1 db2fenc1 [root@localhost expc]# passwd db2inst1 [root@localhost expc]# passwd db2fenc1 |
6、安装 license（产品许可证） PS:如果是ExpressC版本就不用做
[root@localhost adm]# pwd
/opt/ibm/db2/V10.1/adm
[root@localhost adm]# chmod -R 775 *
[db2inst1@localhost adm]$ ./db2licm -a /tmp/seagull/db2v10/license/db2ese_c.lic
[root@localhost instance]# pwd /opt/ibm/db2/V10.1/instance [root@localhost instance]# chmod -R 775 * [root@localhost instance]# ./db2icrt -p 50000 -u db2fenc1 db2inst1 [root@localhost instance]# su - db2inst1 [db2inst1@localhost ~]$ db2sampl Creating database "SAMPLE"... Connecting to database "SAMPLE"... Creating tables and data in schema "DB2INST1"... Creating tables with XML columns and XML data in schema "DB2INST1"... 'db2sampl' processing complete. [db2inst1@localhost ~]$ db2start SQL1026N The database manager is already active. [db2inst1@localhost ~]$ db2 connect to sample Database Connection Information Database server = DB2/LINUX 10.1.2 SQL authorization ID = DB2INST1 Local database alias = SAMPLE [db2inst1@localhost ~]$ db2 "select * from staff" |
8、创建 das 管理服务器
为了远程客户端能够用控制中心来控制数据库服务器，需要在数据库服务器上安装 das,当然，如果只是远程连接而不是远程管理，可以不用装，这里我安装了一下。
[root@localhost expc]# groupadd -g 2002 db2asgrp [root@localhost expc]# useradd -m -g db2asgrp -d /home/db2as db2as [root@localhost expc]# passwd db2as [db2as@localhost ~]$ su - db2as # 这里测试新建用户 [db2as@localhost ~]$ su # 这里进入root权限 [root@localhost ~]# cd /opt/ibm/db2/V10.1/instance/ [root@localhost instance]# ./dascrt -u db2as DBI1070I Program dascrt completed successfully. [root@localhost instance]# su - db2as [db2as@localhost ~]$ db2admin start SQL4409W The DB2 Administration Server is already active. |
9、设置端口号
vim /etc/services
在最后增加一行 # PS：VIM快捷键，在命令模式下输入“G”跳刀最后一行。
db2inst1 50000/tcp
10、db2 配置，要切换到用户 db2inst1
su - db2inst1
db2set DB2_EXTENDED_OPTIMIZATION=ON
db2set DB2_DISABLE_FLUSH_LOG=ON
db2set AUTOSTART=YES
db2set DB2_STRIPED_CONTAINERS=ON
db2set DB2_HASH_JOIN=Y
db2set DB2COMM=tcpip
db2set DB2_PARALLEL_IO=*
db2set DB2CODEPAGE=819 # PS:这个地方比较重要
# db2 update database manager configuration using svcename db2inst1
11.将SVCENAME设置成/etc/services中的端口号或者服务名了吗？
[db2inst1@localhost ~]$ db2 get dbm cfg|grep SVCENAME
TCP/IP Service name (SVCENAME) =
SSL service name (SSL_SVCENAME) =
发布地址： http://www.cnblogs.com/zxlovenet/p/3972766.html
找到SVCENAME，如果当前值不是服务器端的端口号或者服务名，进行更新设置。
[db2inst1@localhost ~]$ db2 update dbm cfg using SVCENAME db2inst1
# db2 update dbm cfg using INDEXREC ACCESS
[db2inst1@localhost ~]$ db2 get dbm cfg|grep SVCENAME
TCP/IP Service name (SVCENAME) = 50000
SSL service name (SSL_SVCENAME) =
# PS：svcename 在客户端连接时需要用到
12.在启动DB2之前需要先关闭防火墙，不然的话根本就不能连接（这个地方的疏忽纠结了好久），在root用户下执行：service iptables stop
13.开启DB2，执行：db2start ，如果已经开启状态，那就先停止，执行：db2stop 。
PS:参考链接如下
http://www.db2china.net/home/space.php?uid=92501&do=blog&id=25771
http://blog.csdn.net/xiaolang85/article/details/3887459
设置查看：
PS:重启机器后遇到了一个问题，就是关闭防火墙无反应，开启关闭数据库无反应，远程不能连接到数据库，解决办法是重启了服务器，然后按照顺序关闭了防火墙，然后重启了DB2数据库。