一、编码工具
1.ide：或者，熟悉尽可能多的快捷键，《》
2.插件：
(1) ，在release之前进行一次静态代码检查是必须的
(2) ，关心你的单元测试覆盖率
(3) 代码风格检查
3.构建和部署工具:或者，现在主流都是maven了吧，，再加上持续集成。代码质量不用愁。
4.版本管理工具： 或者
5.
6.设置你的eclipse或者idea，如formatter,以及code template等。代码风格，直接用google的也可以啊。《》
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
分析完成后可以用浏览器查看堆的情况。这个工具的分析结果还比较原始，你还可以用插件进行图形化分析，或者ibm的.
4.jvisualvm和jconsole： jvm自带的性能分析和监控工具，怎么用？
5.jstack：分析线程堆栈，如
jstack pid > thread_dump
查看cpu最高的线程在干什么的方法结合top和jstack：
6.更多jvm工具，参见官方文档：7.学习使用btrace分析java运行时问题。《》
8.gc日志分析工具：、或者
9.性能分析工具，除了自带的jvisualvm外，还可以用商业的。
11.《》，iteye神贴。
三、linux工具
1.
2.
3.使用替换top。
4.熟悉下甚至p来分析问题。
5.自动化部署脚本，或者自荐下我的。
四、其他
1.掌握一门脚本语言，或者，高效解决一些需要quick and dirty的任务：比如读写文件、导入导出数据库、网页爬虫等。注意不是python.com，咔咔。
2.使用linux或者mac os系统作为你的开发环境。
3.升级你的“硬件工具”，双屏大屏显示器、ssd、8g内存甚至更多。
4.你懂的：
五、如何查找工具？
1.搜索引擎，google或者baidu，《》
2.万能的stack overflow：
3.虚心问牛人。
六、最重要的是⋯⋯
一颗永不停止学习的心。
dennis 2012-04-17 17:05
]]>首先是我们的的“复制品”metamorphosis做了1.4版本，实现了同步复制方案，broker本身也做了很多优化，总体而言meta是一个非常成熟可用的产品了。甚至可以说是我在淘宝做的最好的一个产品。有些朋友总是问我们为什么不直接用kafka，而要另写一个？这里做个统一的解答。
（1）kafka是scala写的，我对scala不熟悉，也不待见，考虑到维护和语言熟悉程度，用java重写仍然是最好的选择。
（2）其次，kafka的整个社区非常不活跃，发展太慢，而我又不愿意去学习scala来参与社区发展，那么唯一的出路就是自己写。
（3）kafka的一些工作不能满足我们的要求，比如一开始它连producer的负载均衡都没有，它的消费者api设计还是比较蛋疼的。它也不支持事务，没有考虑作为一个通用的mq系统来使用。并且它也没有高可用和数据高可靠的方案。
（4）我们做了什么呢？
a.用java彻底重写整个系统，除了原理一致，整个实现是彻底重新实现的。
b.我们提供了生产者的负载均衡（仍然是基于zk），重新设计了消费者api，更符合 jms的使用习惯。
c.我们提供了事务实现，包括producer和consumer端的，包括本地事务和符合xa规范的分布式事务实现。
d.我们提供了两种数据高可靠方案：类似mysql的异步复制和同步复制方案。通过将消息复制到多个节点上来保证数据的高可靠。
e.我们提供了http协议的实现，并且本身使用协议也是类似memcached的文本协议，内部也增加了很多统计项目，可以以memcached的stats协议的方式来获取纯文本的统计信息。整个系统运维很方便。
f.提供了很多扩展应用：广播消费者的实现，多种offset存储的实现（默认的zookeeper，还有文件和mysql)，tail4j用于作为agent发送日志，log4j appender扩展用于透明地使用log4j发送消息，hdfs writer用于将消息写入hdfs，storm spout用于将消息接入storm做实时分析，基本上形成一套完整的工具链和扩展。
g.一些其他功能点：group commit提升数据可靠性和吞吐量，连接复用，集群下的顺序消息发送，消息数据的无痛迁移和水平扩展，web管理平台等。
meta未来会走开源的路子，不过不会是我来推动的，估计是在今年会有进展。
我最近还写了一些小项目值得一提，首先是这个轻量级的表达式执行引擎发布了2.2.1版本，主要是这么几个改进：
（1）支持多维数组变量的访问，如a[0][0]
（2）添加expression#getvariablenames()用于返回表达式的变量列表
（3）添加aviatorevaluator#exec方法来简化调用
（4）bug修正等。
maven直接升级：
<dependency>
<groupid>com.googlecode.aviatorgroupid>
<artifactid>aviatorartifactid>
<version>2.2.1version>
dependency>
<groupid>com.googlecode.aviatorgroupid>
<artifactid>aviatorartifactid>
<version>2.2.1version>
dependency>
其次，这个handler socket的客户端，由新浪微博的@赵鹏城实现了inc/dec协议，添加了incr和decr方法用于更新计数，感谢他的贡献，如果你需要这两个功能可以自己从github拉取源码并构建打包，暂时不准备发布到maven。
第三，关注高可用的transaction manager实现的可以关注下我的项目，这是一个基于这个开源jta实现，提供基于bookkeeper的高可用的tm项目。将事务日志写到高可用的bookkeeper上，并利用zookeeper来做到故障的透明迁移，某个tm挂了，可以在其他机器上从bookkeeper拉取日志并恢复。代码已经稳定并做了性能测试，没有做进一步的破坏性测试。是一个比jotm和atomikos更靠谱的开源jta实现，并且性能也好上很多，代码质量更不用说，建议有兴趣的可以看一下。我也为它贡献了，日志写入性能提升了近一倍。
最后，我在clojure上做了一些事情，首先是为项目贡献了两个patch：利用curator做zookeeper交互和添加storm.ui.context.path选项，前者被作者接受，后者暂时只对我们有用。前者让storm跟zk的交互更可用，后者是为storm ui添加了可选的相对路径。你都可以在尝试，curator的patch在storm 0.6.2上发布，现在还是snapshot状态。昨天晚上牙痛睡不着，半夜写了个，用于统计分析clojure stm运行状况，诸如事务运行次数和时间，事务的重试原因和次数等，可以针对每个dosync的form做统计，有兴趣也可以看下。不过我其实更想将这个功能加入到clojure核心，会尝试提交下pull request。
还有个工作上的变迁，我将在2月1号正式从呆了近三年的淘宝离职，加入一支充满活力的创业团队。从稳定的大公司出来，去加入一家初创公司，不能说没有风险，但是我还是想去接受新的挑战，愿意更新我的知识结构，愿意向牛人们学习。我在某个blog上说我今年遇到了人生中最大的挑战和转折，并不是说这个事情，而是我的儿子今年患了一场重病，庆幸在很多人的帮助和关心下，他勇敢地挺了过来，度过最困难的一关，现在还在继续治疗。我要感谢很多人，感谢淘宝，感谢我的tl华黎和锋寒，感谢我的同事和朋友林轩，感谢我们的hr，感谢三年后打交道的很多同事。没有他们，我今年真的过不了关，没有他们，我也不能进入淘宝并呆上快三年。
最后的最后，我要特别感谢我的儿子，谢谢你的降生，谢谢你今年的勇敢，谢谢你给我们全家带来的快乐，谢谢你继续陪着我们 ，也希望你新年继续勇敢地坚持下去，我们必将战胜一切。
dennis 2012-01-15 12:50
]]>前几个月同事报告称有一个线上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);
}
}
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
=> 2
>> -2001%4
=> 3
这个印象持续至今，在clojure里结果也是这样子：
clojure 1.2.1
user=> (mod -1000 3)
2
user=> (mod -2001 4)
3
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
[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);
}
system.out.println(-1000 % 3);
system.out.println(-2001 % 4);
}
打印结果为：
-1
-1
-1
果然，在java里负数取模的结果为负数，而不是我习惯性地认为是正数。因此最终的定位到的原因就是sets这个变量递增超过integer.max_value后越界变成负数了，取模的结果为负数，导致抛出数组越界的异常，这也解释了为什么同一个集群都在同一时间出问题，因为这个集群内的机器启动时间相邻并且调用这个方法次数相对平均。
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
]]>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
]]>在原版本上，目前做了如下改进：
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
]]>这半年来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
]]>看过很多讨论程序员工作效率的文章，据称研究表明要进入这种状态是至少要15分钟的时间，因此频繁地打断工作会阻碍你的工作效率，毕竟酝酿情绪也是需要时间的嘛。我有思考过怎么去尽量多地保持这种状态，排除那种对工作厌烦的情绪，毕竟拿着工资不干活心里还是会不安，况且看到周围那么多高效率的人，压力是难免的，让人担心的不是每天只有两个小时的高效工作，而是那段什么都不想干的时间。最后让我发现一个方法，说起来很简单，就是在出现这种低效状态的时候，强迫自己打开eclipse，而不是 firefox，强迫自己去写几行代码，如果这段时间内没有被其他事情打断，那么你还是容易进入一种不那么高效和愉悦的工作状态，至少能做到专心致志。当然，跟自己的情绪对抗可能不是世界上最困难的事情，也是其中之一，不过请你相信，只要你打开eclipse开始写代码并进入思考状态，那么你至少是可以暂时遗忘那些负面情绪的，甚至你的情绪可能因为解决了某个难题而高昂起来。
这个方法肯定不是什么新发现，我估计很多人会有同样的经验，今早在看《joel说软件》其中一篇文章《开火与运动》也谈到了同样的问题，joel也提到相同的经验：开了头就好。你不知道要费多少劲才能将一辆带齿轮的山地车运转起来，不过一旦它转起来之后，一切都跟骑一辆没有齿轮的自行车没什么两样。joel还延伸了更多，开火的策略不仅仅是工作效率的问题，也是竞争策略，当你向敌人开火的时候，同时向敌人靠过去，活力会迫使敌人低下头而不能向你开火。竞争也是如此，压迫性的不断推出新东西让你的竞争对手疲于奔命，反而遗忘产品的根本性的目的，这些新东西可能只是为了替换过去不易用的东西，为什么不易用的东西在过去也会被推出来？那只是了为每天进步不断开火，让敌人忘记开火。
dennis 2010-01-09 11:09
]]>年初从广州公司辞职后，到了厦门一家创业公司，这不是一次很愉快的经历，回想起来我的问题不小。首先不该贸然地想去转换一个语言平台，写c 实在不是很好的编程的体验，乃至于我根本提不起工作热情；其次，心态不成熟，遇到问题和困扰的时候还是比较被动地解决，事实上完全没必要搞成这样，主动提出并且离开公司并不是什么丢人的事情。这次经历告诉我做决定的时候最好再慎重一点，毕竟自己不是一个人了，养家糊口是实实在在的责任。
在厦门的失败经历后，我投简历到了淘宝，尽管对于待遇并不是很满意，出于对淘宝的向往和有点理想主义的小情怀还是来到了杭州。刚来的时候，工作很顺利，生活比较糟糕，老婆孩子接到杭州后才好了点，生活比较有规律了。在淘宝，我所做的仍然是开发，写代码还是我的最爱，不过做的离业务的比较远，这正符合我的期望。负责的是一个消息中间件的开发，这个产品本身已经成型，并且应用在了淘宝的核心系统当中，现在每天通过这个mq发送的消息量已经接近两亿，整个系统拥有数个集群，近30台机器。工作不单纯是开发，包括一些方案的设计和日常的维护工作，总体来讲还是很愉悦的体验。不足的地方，我仍然还是将自己视为一个纯粹的技术人员，对淘宝本身的业务、对其他系统的架构设计的了解都比较少，甚至于认识的人还是很局限，不过这个跟我的性格有关了。
技术上，这一年自我感觉没多大进步，除了将读完之外(我准备再度几遍)，一些零零散散的技术书籍也看了不少，很少留下深刻的印象，比较有价值的是《》和《程》上下两卷。前者使我开始有意识地将自己一些重复性的工作自动化，提高自己的工作效率，后者让我对网络框架的设计模式有了相对全面的认识，也促进了我对java网络编程的认识。今年也开发了个java memcached client——,并在大家的鼓励下持续地在改进，总算有不少用户在用，没有枉费精力和时间，也算今年的一个小小自得的地方。这里要特别感谢下曹晓刚，没有他的鼓励和他们公司的使用，还只是个人玩具。09年下半年又将不少精力放在了erlang，过去学习是跟风，这次总算在项目中了有了个小应用，并且将《erlang程序设计》和otp设计原则来回读了几遍，对erlang的兴趣越来越大，甚至于想是不是该去找份专职做erlang的工作。对技术的学习，我还是没有一个明确的规划，任凭兴趣在几个领域里转来转去，这不是好现象，明年希望能更有计划和针对性地去学习，能跟自己的工作契合得更紧密一些。明年也希望能将《算法导论》读完，今年读了1/4，发现我的数学都已经抛到了java国了，算法复杂度的推导总是看不懂，因此又去搞了几本数学书，从头再看看。
回顾完了，说说明年的愿望：
技术上：读完《算法导论》，继续深入erlang，探索erlang在工作中的实际应用，加强对其他系统的了解以及大型网站构建方面的学习
生活上：希望能全家一起去旅游一次，希望能将老爸老妈接过来玩一段时间。
dennis 2009-12-24 17:29
]]>首先显然是高可用性，我们当然希望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
]]>