分布式消息系统的设计要点(2)
一个开源软件的生态是非常重要的,对于mq来说也是如此。主要体现在两个方面,一个是支持的的开发语言多样(需要提供producer和consumer两方的包),一个是针对周边软件的支持。比如spring,spark,hadoop,flink等,减少集成成本。 这方面除了比较新的mq系统,都做的不错。 消息系统的作用 消息系统在目前的分布式系统中设计中,作用越来越大。它的使用场景,包括但不限于: 削峰 用于承接超出业务系统处理能力的请求,使业务平稳运行。这能够大量节约成本,比如某些秒杀活动,并不是针对峰值设计容量。 缓冲 在服务层和缓慢的落地层作为缓冲层存在,作用与削峰类似,但主要用于服务内数据流转。比如批量短信发送。 解耦 项目尹始,并不能确定具体需求。消息队列可以作为一个接口层,解耦重要的业务流程。只需要遵守约定,针对数据编程即可获取扩展能力。 冗余 消息数据能够采用一对多的方式,供多个毫无关联的业务使用。 健壮性 消息队列可以堆积请求,所以消费端业务即使短时间死掉,也不会影响主要业务的正常进行。 End 根据消息的体量和用途,目前可以将分布式mq大体分为两类。 一类用于业务系统,保证极高的可靠性。要求不能够丢失消息,比如订单、支付等,有较高的SLA服务水准。这种情况,对mq的功能要求也比较多,包括消息的可查性。 另外一类用于大数据相关的系统,典型的特点就是吞吐量非常大。异常情况下,丢失几条消息,无伤大雅。 但消息系统,可能关注的只是mq本身。怎么保证生产端、消费端、mq本身三者的可用性,是需要业务进行权衡的。 比如,前段时间xjjdog开源的okmq,就是用来解决一个特定场景的高可用问题。 开源一个kafka增强:okmq-1.0.0 【编辑推荐】
点赞 0 (编辑:ASP站长网) |