BlogJava-庄周梦蝶-随笔分类-工作随笔

Java程序员常用工具集

dennis — Tue, 17 Apr 2012 09:05:00 GMT

我发现很多人没办法高效地解决问题的关键原因是不熟悉工具，不熟悉工具也还罢了，甚至还不知道怎么去找工具，这个问题就大条了。我想列下我能想到的一个Java程序员会用到的常用工具。

一、编码工具

1.IDE：Eclipse或者IDEA，熟悉尽可能多的快捷键，《Eclipse常见快捷键列表》
2.插件：
(1) Findbugs，在release之前进行一次静态代码检查是必须的
(2) Clover，关心你的单元测试覆盖率
(3) Checkstyle 代码风格检查

3.构建和部署工具:ant或者maven，现在主流都是maven了吧，使用nexus搭建maven私服，再加上持续集成jenkins。代码质量不用愁。

4.版本管理工具： svn或者git

5.diff和patch

6.设置你的eclipse或者IDEA，如formatter,save actions以及code template等。代码风格，直接用google的也可以啊。《Google style guide》

7.掌握一个文本编辑器，Emacs或者VIM，熟悉常用快捷键。这在你需要在线编辑代码，或者编写其他语言代码时候特别有用。《神器圣战》

二、JDK相关

1.jstat : 观察GC情况，如：

jstat -gcutil pid 2000

2.jmap，查看heap情况，如查看存活对象列表：

jmap -histo:live pid |grep com.company |less

或者dump内存用来分析：

jmap -dump:file=test.bin pid

3.分析dump的堆文件，可以用jhat:

jhat test.bin

分析完成后可以用浏览器查看堆的情况。这个工具的分析结果还比较原始，你还可以用Eclipse MAT插件进行图形化分析，或者IBM的Heap Analyzer.

4.jvisualvm和jconsole： JVM自带的性能分析和监控工具，怎么用？请自己看文档。

5.jstack：分析线程堆栈，如

jstack pid > thread_dump

查看CPU最高的线程在干什么的方法结合top和jstack：http://www.iteye.com/topic/1114219

6.更多JVM工具，参见官方文档：http://docs.oracle.com/javase/6/docs/technotes/tools/

7.学习使用btrace分析java运行时问题。《Btrace使用简介》

8.GC日志分析工具：GC viewer、GC-console或者自己挑吧。

9.性能分析工具，除了自带的jvisualvm外，还可以用商业的jprofiler。

10.JVM参数大全

11.《JVM调优标准参数陷阱》，iteye神贴。

三、Linux工具

1.熟悉常用的shell命令，

2.设置ssh免登陆

3.使用htop替换top。

4.熟悉下strace,gdb甚至 systemtap来分析问题。

5.熟悉vmstat,iostat,sar等性能统计工具。

5.自动化部署脚本，py-fabric或者自荐下我的clojure-control。

四、其他

1.掌握一门脚本语言，Python或者Ruby，高效解决一些需要quick and dirty的任务：比如读写文件、导入导出数据库、网页爬虫等。注意不是python.com，咔咔。

2.使用Linux或者Mac os系统作为你的开发环境。

3.升级你的“硬件工具”，双屏大屏显示器、SSD、8G内存甚至更多。

4.你懂的：https://code.google.com/p/goagent/

五、如何查找工具？

1.搜索引擎，google或者baidu，《搜索技巧》

2.万能的stack overflow：http://stackoverflow.com/

3.虚心问牛人。

六、最重要的是⋯⋯

一颗永不停止学习的心。

dennis 2012-04-17 17:05 发表评论

找bug记(2)

dennis — Thu, 01 Sep 2011 16:02:00 GMT

这篇blog迟到了很久，本来是想写另一个跟网络相关bug的查找过程，偷偷懒，写下最近印象比较深刻的bug。这个bug是我的同事水寒最终定位到的。
前几个月同事报告称有一个线上MQ集群会同一时间抛出ArrayIndexOutOfBoundsException这个异常，也就是数组越界。查看源码，除去一些无关紧要的细节大概是这样子：

public class ConnectionSelector{
    private AtomicInteger sets=new AtomicInteger(0);

   public void selectConnection(List<Connection> connList){
          if(connList==null)｛
                return null;
           ｝
          final int size = connList.size();
            if (size == 0) {
                return null;
            }
           return connList.get(sets.incrementAndGet() % size);
}

   }

    很显然，这里的本意是实现一个轮询的连接选择器，返回一个选中的连接。使用AtomicInteger递增并对链表大小取模，返回结果索引位置的连接。异常抛出的位置就是我代码中标红的位置。

    显然，这里有两种可能，一种情况下是说在执行那一行代码的时候，connList的大小缩小了（也就是说连接可能被其他线程移出），那么导致取模的结果越界。另一种可能是取模的结果本身确实超过了列表范围。

    第一种情况是完全可能的，因为服务器的连接可能随时断开或者重连，但是这种情况相对非常少见，因此我们这里并没有对这个选择过程做同步，主要是从性能的角度出发，偶尔的失败可以接受。很遗憾的是，我被我的思维惯性误导了，从来没有怀疑过第二种情况，总是认为是不是真的连接恰巧断开导致这个异常，但是却无法解释这个异常发生后就一直错误下去，无法自行恢复。
    为什么说思维惯性误导呢？这里的问题其实是负数取模的问题，对一个负数进行取模，结果会是正数还是负数？答案是结果因语言而异。
    我很早以前在使用Ruby的时候做过测试，负数取模结果为正数，例如在irb里尝试下：

>> -1000%3
=> 2
>> -2001%4
=> 3

这个印象持续至今，在clojure里结果也是这样子：

Clojure 1.2.1
user=> (mod -1000 3)
2
user=> (mod -2001 4)
3

可以再试试python:

Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> -10000%3
2
>>> -2001%4
3

这三种语言的结果完全一致，结果都为正数。这个惯性思维延续到java却不成立了，可惜我根本没做测试，让我们试下：

   public static void main(final String[] args) {
        System.out.println(-1000 % 3);
        System.out.println(-2001 % 4);
    }

打印结果为：

-1
-1

果然，在java里负数取模的结果为负数，而不是我习惯性地认为是正数。因此最终的定位到的原因就是sets这个变量递增超过Integer.MAX_VALUE后越界变成负数了，取模的结果为负数，导致抛出数组越界的异常，这也解释了为什么同一个集群都在同一时间出问题，因为这个集群内的机器启动时间相邻并且调用这个方法次数相对平均。~~修正问题很简单，加个Math.abs就好。~~

Update:加个abs是不够的，因为Math.abs的javadoc提醒了：

Note that if the argument is equal to the value of Integer.MIN_VALUE, the most negative representable int value, the result is that same value, which is negative.

也就是说对Integer.MIN_VALUE做abs结果仍然是负数。尽管在这个场景中失败一次可以接受，但是最好的办法还是回复中steven提到的抵消符号位的做法：

(sets.incrementAndGet() & 0x7FFFFFFF) % size

    这个问题更详细的讨论后来我找到这篇博客，作者讨论几种语言和计算器的这个问题的结果，给出了一些结论。不过我觉的这个结论可能也不是那么可靠，特别是对c/c++来说，很大程度上应该还是依赖于实现，最可靠的办法还是强制结果为正。

    这个bug的几个教训：
1、首先是第一次出现的时候没有引起足够重视，重启解决问题后没有深究。有句玩笑话：99％的程序问题都可以通过重启解决。但是事实上问题仍然存在，该发生的终究还会发生。不管你信不信，它就是发生了，这是一个奇迹。
2、注意大脑的思维惯性，经验主义和教条主义都不可取。最近在读一本好书《暗时间》，大脑误导我们的手段可是多种多样。
3、最后就是这个负数取模的结果因语言而异，不要依赖于特定实现。

dennis 2011-09-02 00:02 发表评论

写DSL的步骤

dennis — Mon, 25 Jul 2011 11:30:00 GMT

1.选定宿主语言，最好选用元编程能力强悍的语言作为宿主语言。
2.确定DSL的样子，让脑袋空白，不去考虑任何实现问题，纯粹思考你想要实现的dsl是什么样子
3.用你想要的DSL写一个最基本的例子，只包括最基本的功能。
4.开始实现DSL，尽快让你的DSL例子以dirty and quick的方式跑起来。
5.写更多DSL的例子，慢慢包括你想要的所有功能，并一一实现，在这个过程中你可能改变DSL的样子，原来模糊的东西渐渐清楚。
6.大功告成，review你的代码并添加自动化测试，将代码中dirty和bad smell的部分一一剔除。
7.让你的DSL接受实际应用的考验吧。

dennis 2011-07-25 19:30 发表评论

最近对kafka的移植工作

dennis — Sat, 07 May 2011 02:46:00 GMT

    Kafka这个linkedin开源的MQ，我在过去的blog简单介绍过。最近3周来，我的工作就是做它的一个Java移植版本，kafka是用scala写的，基于维护和定制的角度，这个拷贝的版本还是用Java。说拷贝，也不尽然，原理相同，但实现完全换过，从数据结构到通讯框架、通讯协议、程序组织，乃至一些重要功能点上都做了改进和更新。我将这个Java版本取名为metamorphosis,也就是卡夫卡的代表作《变形记》的英文名。

    在原版本上，目前做了如下改进：
1、协议替换为文本协议，整个协议类似memcached，文本协议的优点自不必说。通讯框架也是采用内部使用的通讯框架，减少工作量。

2、存储结构上也采用自定义结构，更简洁紧凑。

3、kafka原来只支持consumer和broker之间的服务查找和负载均衡，meta加入了producer和broker之间的服务查找和负载均衡。

4、Consumer API没有采用kafka的stream方式，而是同时实现同步获取和异步订阅两种方式，更接近JMS和Notify。

5、改进了服务器端文件recover的性能，采用并发多线程recover的方式（可选）。

6、添加了实时统计功能和协议，类似memcached的stats协议,响应透明号召。

7、客户端的连接复用。

    以后要做的事情，可能包括：
1、实现类似Mysql的master/slave方案，可能还要分为同步和异步两种模式。

2、分区扩展时候的数据自动迁移功能，做到无痛水平扩展。

3、高可用方案的另一个实现。

4、嵌入Http server做web管理。

    工作在本周初步告一段落，接下来是要做集成测试和压测等，我在两台8核16G的机器上分别部署服务器和客户端（订阅者发布者同在一台），做的一个简单压测数据如下：并发100个线程发送5000万消息并同时消费，1K大小的消息TPS可以达到3.8万，4K大小的消息TPS可以达到1.8万，服务器load都维持在一个较低的水平。从这个数据来看，超过我一开始的预期。后续可能做下kakfa的测试对比下。

dennis 2011-05-07 10:46 发表评论

工作随笔——2010-07-24

dennis — Sat, 24 Jul 2010 12:51:00 GMT

    转眼间快到8月，已经过去了两个季度，是时候稍微总结下干了什么，以后想干什么。从春节到现在，我仍然是做淘宝的消息中间件Notify的开发，中间额外去做了一个多月的另一个项目的开发，重拾了web开发的一些东西。

    这半年来Notify的改进集中在通讯层的改造，引入AMQP的订阅模型，以及将重要消息从oracle迁移到mysql做HA方案，这一过程是一个慢慢稳定系统的过程。新版本刚出来的时候有不少BUG，有些BUG很严重，幸运的是没有造成严重的后果，再一次提醒我小心，小心，再小心；小心是一方面，工作有没有做到位是另一个方面，暴露出来的问题还是单元测试不全面，以及麻痹大意心态下的不警惕，对关键代码认识不清，code review也没有做到位等等。

    Notify做到现在，剩下的问题是一些很难解决，又非常关键性的问题，如消息的去重，消息的顺序性，以及消息的可靠存储。我说的这些问题都是在分布式集群环境下需要解决的问题，如果仅仅是单台服务器，这些问题的解决还算不上特别困难。消息的去重，基本的思路是在客户端和服务器之间各自维持一个状态，用于保存当前消息的处理情况，依据这个情况来做消息的去重，但是状态的保存对服务器和客户端来说都是一个额外的负担，并且很难做到可靠的存储，如果状态丢了，去重的目的就没办法做到。ActiveMQ里是在服务器和客户端都维持了一个bitmap做重复的检测，但是这个bitmap大小必然是受限的，并且无法持久保存的。消息的在集群环境下的顺序性，涉及到集群环境下的事件的时间顺序问题，除了使用分布式锁来保证一致性之外，暂时也没有好的思路去解决。消息的可靠存储，今年我们的目标至少是脱离oracle，目前实现的HA mysql双写的实现已经开始部署到交易这样的核心系统上，第三个季度将慢慢地全部切换过去。下一步的目标是将消息存储到key-value系统上，但是需要解决的是索引的问题，因为消息的恢复涉及到查询，并且需要根据一些特殊条件做查询以应付诸如尽快恢复重要消息这样的功能，因此目前的一些key-value系统要么在索引功能上太弱，要么在集群功能上太弱，要么在大数据量存储上有局限，因此不是特别切合我们的场景，因此一个可行的方案是将消息的header继续存储在关系数据库，方便做查询，而将数据较大的body存储在key-value上，减轻数据库的负担。今年，我们还是希望能在以上3个方向某个方向做出突破。

   这半年来技术上的收获，第一个季度业余时间都去打游戏了，没方什么心思在学习和工作上，后来去学习了下ASM，总算对java的byte code，以及jvm执行byte code过程有了个理解，然后利用ASM去搞了aviator这个项目。接下来开始做服务器的SEDA改造，这个过程完成了部分，但是不满意，SEDA的模型过于理论化，模型是好的，但是在stage controller的实现上目前没有可供参考的经验，做到资源的自动控制更需要实际的测试和实践，基本的指导原则只能作为参考。另外，最近下决心去重构整个项目，从一个一个类看起，看到不爽的地方马上去做重构，这个过程，我又去重看了下《重构》中的原则，在谈论诸如分布式、海量数据存储、云计算这样的大词之前，我需要的做的仍然是将代码写好，写的漂亮。也许是时候回到本源，再去重读下《设计模式》，重读下《重构》，既然我还在写java代码，那还是希望写的更好点。
   另外，我现在喜欢上了clojure语言，并且正儿八经地找了本书好好学习，从源码和bytecode入手去理解它的实现。我为什么喜欢clojure?
   首先，它是LISP的方言之一，LISP的优点它全有，LISP的缺点它能想办法避免。Clojure也有宏，也有quote，也有将procedure as data的能力，Clojure的数据结构都是immutable，此外还是persistence，避免了immutable数据大量拷贝带来的开销。Clojure的数据结构还天生是lazy的，表达能力上一个台阶。Clojure在语法上更多变化，某些程度上降低了括号的使用频率，这一点有利有弊。Clojure的内在原则是一致的，核心语法非常简单，它没有多种范式可供选择，因此没有scala那样复杂的类型系统，没有为了包容java程序员引入的OO模型（有替代品），使用clojure最好的方式是函数式地，但是它的扩展能力允许你去尝试各种范式。

   其次，Clojure对并发的支持更符合一般程序员的理解，它只是将锁替换成了事务，利用STM去保存可变状态，但是却避免锁带来的缺点——死锁、活锁、竞争条件。它没有引入新的模型，这对习惯于用锁编程的同学来说，STM没有很大差异，你可以将它理解成内存型数据库。

   第三，最重要的一点，Clojure是实现于JVM之上的，Java上的任何东西它都能直接利用，并且利用type hint之类的手段可以做到性能上没有损失。尽管Java语言有千般不是，但是寄生于整个平台之上的开源生态系统是任何其他社区都很难比拟的，放弃Java平台这个宝库，暂时还做不到。过去学习scheme，学习common lisp，更多的目的是开阔眼界，现在能实际地使用，还能有比这更幸福的事情吗？

   下半年技术上想学习什么呢？除了clojure之外，我想去看下haskell，了解下什么是mond，除此之外，就是收收心将《算法导论》读完吧。另外，收起对awk和shell编程的偏见，好好熟悉下这两个工具，dirty and quickly的干活有时候还是很重要的。

    我还是个典型的码农，喜欢写代码，喜欢尝试新东西，至少热情和好奇心还残存一些，那么就继续当好码农吧。

dennis 2010-07-24 20:51 发表评论

写代码与情绪

dennis — Sat, 09 Jan 2010 03:09:00 GMT

    你不得不承认，写代码的效率跟周期性的情绪相关。以我为例，总存在着周期性的情绪波动，那段时间内基本不想写代码，上班就是收收邮件，看看网页，遗憾的是每个月都有那么几天。事实上，我认为在一天8小时的工作中，能有2、3个小时能达到忘我状态的工作，那已经是非常不错的事情。如果你是程序员，你肯定知道我说的忘我状态是什么。我在这里说的局限了，其实任何工作都可能进入这种忘我状态，这种状态下你的思维非常活跃，全神贯注，哪怕有人跟你说话你也会听而不闻，这种状态在你读一本非常有趣的小说的时候也会出现。这种状态下的你效率会非常高，例如我前段时间内就在一周内写了13000多行代码，600多个测试用例，为我们的系统重新实现了一个通信层。

   看过很多讨论程序员工作效率的文章，据称研究表明要进入这种状态是至少要15分钟的时间，因此频繁地打断工作会阻碍你的工作效率，毕竟酝酿情绪也是需要时间的嘛。我有思考过怎么去尽量多地保持这种状态，排除那种对工作厌烦的情绪，毕竟拿着工资不干活心里还是会不安，况且看到周围那么多高效率的人，压力是难免的，让人担心的不是每天只有两个小时的高效工作，而是那段什么都不想干的时间。最后让我发现一个方法，说起来很简单，就是在出现这种低效状态的时候，强迫自己打开eclipse，而不是 firefox，强迫自己去写几行代码，如果这段时间内没有被其他事情打断，那么你还是容易进入一种不那么高效和愉悦的工作状态，至少能做到专心致志。当然，跟自己的情绪对抗可能不是世界上最困难的事情，也是其中之一，不过请你相信，只要你打开eclipse开始写代码并进入思考状态，那么你至少是可以暂时遗忘那些负面情绪的，甚至你的情绪可能因为解决了某个难题而高昂起来。
   这个方法肯定不是什么新发现，我估计很多人会有同样的经验，今早在看《joel说软件》其中一篇文章《开火与运动》也谈到了同样的问题，joel也提到相同的经验：开了头就好。你不知道要费多少劲才能将一辆带齿轮的山地车运转起来，不过一旦它转起来之后，一切都跟骑一辆没有齿轮的自行车没什么两样。Joel还延伸了更多，开火的策略不仅仅是工作效率的问题，也是竞争策略，当你向敌人开火的时候，同时向敌人靠过去，活力会迫使敌人低下头而不能向你开火。竞争也是如此，压迫性的不断推出新东西让你的竞争对手疲于奔命，反而遗忘产品的根本性的目的，这些新东西可能只是为了替换过去不易用的东西，为什么不易用的东西在过去也会被推出来？那只是了为每天进步不断开火，让敌人忘记开火。

dennis 2010-01-09 11:09 发表评论

2009年小结

dennis — Thu, 24 Dec 2009 09:29:00 GMT

    趁着下班前的半小时，回顾下2009年我都干了什么，有什么收获，有什么不足。
    09年最重要的事情是我的儿子出生了，小家伙的到来带给全家很多欢乐，烦恼也不少，比如半夜总要被吵醒，晚上的读书也没办法那么专心读了。此外，我还在学习怎么当爸爸，写过这篇《新爸爸指南》，记录下新生儿遇到的种种问题，逐渐经历自己生命的又一个阶段，这个历程很美好。
    年初从广州公司辞职后，到了厦门一家创业公司，这不是一次很愉快的经历，回想起来我的问题不小。首先不该贸然地想去转换一个语言平台，写C++实在不是很好的编程的体验，乃至于我根本提不起工作热情；其次，心态不成熟，遇到问题和困扰的时候还是比较被动地解决，事实上完全没必要搞成这样，主动提出并且离开公司并不是什么丢人的事情。这次经历告诉我做决定的时候最好再慎重一点，毕竟自己不是一个人了，养家糊口是实实在在的责任。
   在厦门的失败经历后，我投简历到了淘宝，尽管对于待遇并不是很满意，出于对淘宝的向往和有点理想主义的小情怀还是来到了杭州。刚来的时候，工作很顺利，生活比较糟糕，老婆孩子接到杭州后才好了点，生活比较有规律了。在淘宝，我所做的仍然是开发，写代码还是我的最爱，不过做的离业务的比较远，这正符合我的期望。负责的是一个消息中间件的开发，这个产品本身已经成型，并且应用在了淘宝的核心系统当中，现在每天通过这个MQ发送的消息量已经接近两亿，整个系统拥有数个集群，近30台机器。工作不单纯是开发，包括一些方案的设计和日常的维护工作，总体来讲还是很愉悦的体验。不足的地方，我仍然还是将自己视为一个纯粹的技术人员，对淘宝本身的业务、对其他系统的架构设计的了解都比较少，甚至于认识的人还是很局限，不过这个跟我的性格有关了。
    技术上，这一年自我感觉没多大进步，除了将sicp读完之外(我准备再度几遍)，一些零零散散的技术书籍也看了不少，很少留下深刻的印象，比较有价值的是《卓有成效的程序员》和《C++网络编程》上下两卷。前者使我开始有意识地将自己一些重复性的工作自动化，提高自己的工作效率，后者让我对网络框架的设计模式有了相对全面的认识，也促进了我对Java网络编程的认识。今年也开发了个Java Memcached Client——Xmemcached,并在大家的鼓励下持续地在改进，总算有不少用户在用，没有枉费精力和时间，也算今年的一个小小自得的地方。这里要特别感谢下曹晓刚，没有他的鼓励和他们公司的使用，xmc还只是个人玩具。09年下半年又将不少精力放在了Erlang，过去学习是跟风，这次总算在项目中了有了个小应用，并且将《Erlang程序设计》和OTP设计原则来回读了几遍，对Erlang的兴趣越来越大，甚至于想是不是该去找份专职做Erlang的工作。对技术的学习，我还是没有一个明确的规划，任凭兴趣在几个领域里转来转去，这不是好现象，明年希望能更有计划和针对性地去学习，能跟自己的工作契合得更紧密一些。明年也希望能将《算法导论》读完，今年读了1/4，发现我的数学都已经抛到了Java国了，算法复杂度的推导总是看不懂，因此又去搞了几本数学书，从头再看看。

   回顾完了，说说明年的愿望：
技术上：读完《算法导论》，继续深入Erlang，探索Erlang在工作中的实际应用，加强对其他系统的了解以及大型网站构建方面的学习
生活上：希望能全家一起去旅游一次，希望能将老爸老妈接过来玩一段时间。

dennis 2009-12-24 17:29 发表评论

一个优秀的MQ产品的特点。

dennis — Thu, 17 Sep 2009 16:09:00 GMT

    MQ在分布式系统中扮演着重要角色，异步的消息通信全要靠它，而异步通信正是提高系统伸缩性的不二良方。说说我认为的一个优秀的MQ产品需要具备的特征。

    首先显然是高可用性，我们当然希望MQ能支撑7x24小时应用，而不是三天两头当机，我们要追求的是99.9%的可靠服务时间。要做到高可用性，显然我们需要做MQ的集群，一台当了，不影响整个集群的服务能力，这里涉及到告警、流控、消息的负载均衡、数据库的使用、测试的完备程度等等。

    其次是消息存储的高可靠性。我们要保证100%不丢消息。要做到消息存储的高可靠性，不仅仅是MQ的责任，更涉及到硬件、操作系统、语言平台和数据库的一整套方案。许多号称可靠存储的MQ产品其实都不可靠，要知道，硬件错误是常态，如果在硬件错误的情况下还能保证消息的可靠存储这才是难题。这里可能需要用到特殊的存储硬件，特殊的数据库，分布式的数据存储，数据库的分库分表和同步等等。你要考虑消息存储在哪里，是文件系统，还是数据库，是本地文件，还是分布式文件，是搞主辅备份呢还是多主机写入等等。

    第三是高可扩展性，MQ集群能很好地支持水平扩展，这就要求我们的节点之间最好不要有通信和数据同步。

    第四是性能，性能是实现高可用性的前提，很难想象单机性能极差的MQ组成的集群能在高负载下幸免于难。性能因素跟采用的平台、语言、操作系统、代码质量、数据库、网络息息相关。MQ产品的核心其实是消息的存储，在保证存储安全的前提下如何保证和提高消息入队的效率是性能的关键因素。这里需要开发人员建立起性能观念，不需要你对一行行代码斤斤计较，但是你需要知道这样做会造成什么后果，有没有更好更快的方式，你怎么证明它更好更快。软件实现的性能是一方面，另一方面就是平台相关了，因为MQ本质上是IO密集型的系统，瓶颈在IO，如何优化网络IO、文件IO这需要专门的知识。性能另一个相关因素是消息的调度上，引入消息顺序和消息优先级，允许消息的延迟发送，都将增大消息发送调度的复杂性，如何保证高负载下的调度也是要特别注意的地方。


   第五，高可配置性和监控工具的完整，这是一个MQ产品容易忽略的地方。异步通信造成了查找问题的难度，不像同步调用那样有相对明确的时序关系。因此查找异步通信的异常是很困难的，这就需要MQ提供方便的DEBUG工具，查找分析日志的工具，查看消息生命周期的工具，查看系统间依赖关系的工具等等。可定制也是MQ产品非常重要的一方面，可方便地配置各类参数并在集群中同步，并且可动态调整各类参数，这将大大降低维护难度。

   一些不成熟的想法，瞎侃。

dennis 2009-09-18 00:09 发表评论