12 | 架构设计流程：评估和选择备选方案

Kafka没用过，但是上网看了相关对比，认为阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka不能满足或者ActiveMQ等其他消息中间件不能满足，所以选择自己开发（RocketMQ设计的真的很牛） 1、数据可靠性 kafka使用异步刷盘方式，异步Replication RocketMQ支持异步刷盘，同步刷盘，同步Replication，异步Replication 2、严格的消息顺序 Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序 RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序 3、消费失败重试机制 Kafka消费失败不支持重试 RocketMQ消费失败支持定时重试，每次重试间隔时间顺延 4、定时消息 Kafka不支持定时消息 RocketMQ支持定时消息 5、分布式事务消息 Kafka不支持分布式事务消息 阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息 6、消息查询机制 Kafka不支持消息查询 RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id） 7、消息回溯 Kafka理论上可以按照Offset来回溯消息 RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息 ………

心得: 架构设计流程-评估和选择备选方案 1 评估和选择备选方案的方法 按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。 2 RocketMQ 和 Kafka 有什么区别？ （1） 适用场景 Kafka适合日志处理；RocketMQ适合业务处理。 （2） 性能 Kafka单机写入TPS号称在百万条/秒；RocketMQ大约在10万条/秒。Kafka单机性能更高。 （3） 可靠性 RocketMQ支持异步/同步刷盘;异步/同步Replication；Kafka使用异步刷盘方式，异步Replication。RocketMQ所支持的同步方式提升了数据的可靠性。 （4） 实时性 均支持pull长轮询，RocketMQ消息实时性更好 （5） 支持的队列数 Kafka单机超过64个队列/分区，消息发送性能降低严重；RocketMQ单机支持最高5万个队列，性能稳定（这也是适合业务处理的原因之一） 3 为什么阿里会自研RocketMQ？ （1） Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够 （2） 阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高 （3）当业务成长到一定规模，采用开源方案的技术成本会变高（开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容等） （4） 阿里在团队、成本、资源投入等方面约束性条件几乎没有

案例很典型，所在项目，先选了3，1.0上线后效果不错，后期业务扩展，投入跟不上，3的缺点不断暴露，到后来大家就在吐槽为啥要造轮子。开始否决3，重构, 选择了1，运维话语权弱，被忽略了。至于为啥不选2，就是面子上过不去，拿不出手。项目不光是为了业务，也为了架构师，领导的面子，被拿来和公司内其他项目做横向比较时，比较好吹。至于运维的哥们，也乐意学些新东西，提升自我价值。所以，选择1大家都开心，除了项目的投入变大

kafka针对海量数据，但是对数据的正确度要求不是十分严格。 而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适，然后就自研了RocketMQ。

我觉得应该选取kafka方案，运维以scala为理由觉得运维复杂站不住脚，实际上在Kafka运维时很少需要了解Scala，而且目前基于Kafka的开发也基本上使用Java API。另外认为kafka是用于日志传输，所以不适合系统的业务事件是个更大的误区，Kafka本身在最早实现时的确是为了传输日志，但后来经过多年发展，其适用范围早不限于日志，并且很多采取Kafka的公司并非用它来处理日志，kafka背后的Confluence公司提供了很多基于kafka来简化系统实现的例子，值得架构师参考。

1、就备选方案选择来说，方案2确实可行，但就我们使用Kafka经验来讲，Kafka确实很成熟，运维成本较低。架构师在选择方案时，需要对方案中涉及到的工具烂熟于心。 2、关于RocketMQ和Kafka区别，有些回答罗列了很多功能的差异，个人觉得无太大意义。大家都在发展，功能的差异会很快抹平的。我想说点区别是，1、架构上RocketMQ不依赖zk，而Kafka重度依赖zk；2、RocketMQ没有完全开源的，有一些功能需要自己重写；而Kafka应用广泛，社区支持力度大，这样对运维压力和成本会小很多。

几乎所有的人都说kafka是异步刷盘会导致消息可靠性出问题。但是我想说kafka如果配置了每写一条消息就强制刷盘，再加上配置kafka集群中所有副本全部同步之后再返回写入成功。在这种配置下消息的可靠性是可以保障的。 只不过是这种配置下性能低而已。 请问华仔，这种配置下kafka是可以保证消息的可靠性的对吧？

kafka同步刷盘同步复制早支持了，同步复制不会有乱序。kafka很稳定的，几个产品都用过，简单场景没啥问题。rocketmq开源版本貌似master挂掉后slave无法自动切换为master，可读不可写！阿里中间件博客有时候有点...

这个应该有多个原因吧，个人感觉有下面几条，1）业务特性需要，最初kafka不支持事务性消息，而rocketmq支持，2）rocketmq支持broker端的消息过滤 3）淘宝的java能力比scala强很多 ，为了运维稳定，就学习了kafka的优点，进行了重写 ，毕竟运维才是软件的核心生命周期

方案2是整体最优解，各个利益方都收益。代码上线只是开始，后续漫长的使用优化维护需要很大的精力。 对于rocketmq和kafka，不少留言提到是因为阿里有钱，这还真不是。阿里有钱，怎么没有自己搞spring、ibatis、java、linux呢？归根还在于简单和适合原则，kafka和阿里需要的高可用、高稳定、消息不可丢失、可蓄洪、可重放等场景不匹配，同时开发新的成本又在可接受范围之内才自己开发的。 如果google的大数据三套件，是在没有已有方案的情况下去自己实现的。