开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：消息队列和应用工具产品体系-阿里云消息队列产品简介】
课程地址：https://edu.aliyun.com/course/3112075/lesson/19035
消息队列和应用工具产品体系-阿里云消息队列产品简介
内容介绍：
一．阿里云消息队列MQ家族
二．自研、商用、开源“三位一体”的RocektMQ
三．完美支持历年的双11海量流量
四．自研、商用、开源“三位一体”的RocektMQ
五．实现分布式业务的最终一致性
六．实时计算和分布缓存
一．阿里云消息队列 MQ 家族
上面小节简单介绍了消息队列的基本概念，这一小节来学习阿里云的消息队列产品体系，下图是阿里巴巴现有的消息队列 MQ 家族的主要成员，包括六种产品。
其中消息队列的RocketMQ 主要用于互联网业务场景，是阿里巴巴自主研发并开源的消息队列,也是接下来的课程重点。消息队列 Kalfka 主要用于大数据生态环境，是最早开源的消息队列产品之一，在大数据领域具有非常完善的生态环境。
微消息队列 MQTT 主要应用于移动互联网和物联网场景，它结合了消息队列的 RocketMQ 和轻量级的消息通信协议MQTT，相较于RocketMQ，具有支持终端数量多，网络通信开销小等特点。
消息队列 RabbitMQ也是一款开源的消息类产品，它的最大特点是使用特殊进行开发，单服务器并发性能非常好，同时拥有自己的 AMQP 协议。而阿里云的RabbitMQ 产品,100%兼容AMQP 协议，是历史系统移植上云非常好的选择。
消息服务MNS是一套专门为云上系统开发HTTP接入协议的消息队列，其基本功能和消息队列RocketMQ类似,事件总线 EventBridge 是一款 Serverless 的事件总线系统，支持阿里云服务,自定义应用，应用以标准化、中心化方式接入,并能够以标准化系列运用,在应用之间传递路由世界。
二．自研、商用、开源“三位一体”的 RocektMQ
阿里云MQ家族中最重要的产品，消息队列RocketMQ 版,阿里内部使用消息队列系统最早可以追溯到2007年,在淘宝架构进行分布式架构调整的五彩石项目，当时阿里巴巴集团的中间件技术部门自主研发了消息队列Notify产品。
2010年左右，阿里巴巴的业务快速发展，急需一款支持顺序消息和海量消息堆积的消息队列中间件产品，因此又诞生了MetaQ1.0。经过多年的内部使用，MetaQ 升级到了3.0，稳定性和可用性都达到了一般商用软件的技术标准。于是在2012年，阿里巴巴正式将这款产品进行开源，并更名为RocketMQ，成为了继 Kalfka、阿帕奇MQ之后另一个高质量商用级的开源消息队列产品，引起了业界的广泛关注。
在2015年，在开源版本Rocket MQ的基础上，阿里云推出云上的商业版本消息 AliwareMQ，从而实现了自研、商用、开源的三个一体软件产品研发生态。在这种三位一体的生态环境下，阿里巴巴内部的技术沉淀既可以通过开源社区提供给广大开发者，也可以通过云平台提供给大量的企业级应用程序进行验证，反过来，开源社区针对开源版本开发了丰富的第三方组件支持,以及云平台上更为广阔的技术场景验证，又为阿里巴巴内部使用提供了新的设计思路和参考数据。这样，这种自研、商用、开源的生态环境实现了三方共赢和利益最大化。
三．完美支持历年的双11海量流量
双11秒杀、抢红包、企业开门红等大型活动时，会带来较高的流量脉冲，如果没有相应的保护措施，会导致系统超负荷运动甚至崩溃，而如果限制太多，则会导致请求大量失败从而影响用户体验。RocketMQ 是阿里巴巴双11的官方指定消息产品，用来支撑阿里巴巴集团所有的消息服务，从诞生以来，经历十余年的高可用与高可靠的严苛挑战，是阿里巴巴交易链路的核心产品。
RocketMQ 的服务可用性可以高达99.95%，同时使用多地域、多可用区、分布式的极端化方式部署，可以确保消息队列服务的高可用，能够做到即使整个机房不可用，仍然可提供正常的消息服务。同时，RocketMQ 的数据可靠性达到了十个九，数据持久化，采用了同步双写，数据冗余快速切换技术，确保了数据的可靠性。
在历年双11购物狂欢节中，零点的峰值流量可以达到千万级 TPS 总数据量可以达到万亿级数据洪峰，创造了全球最大的业务消息并发及业务流转记录。Rocket MQ 在保证高性能的前提下，支持了亿级消息堆积而不影响集群的正常工作。
在流量需峰迭谷及微服务解耦的场景下，也提供了强大的支持。2020年双11交易峰值达到了每秒58.3万，消息中间件的 RocketMQ 继完美制撑的整个集团的大促及业务场景的平稳。
四．异步解耦各业务中心
淘宝的营架构极其复杂，成百上千的业务模块之间互相关联，如果业务与业务之间完全采用同步调用模式，则各模块之间的耦合度和关联度会非常高，一旦某个模块出现问题，会导致整个调用链路出现问题。以交易系统为例，交易系统作为淘宝和天猫主站最核心的系统，每笔交易订单数据的产生均会引起包括物流、购物车、积分、支付、直充、SNS、旅游集团分析等等几百个下游业务系统的关注，整个业务系统庞大而复杂，如果采用同步调用方式，不但架构负担重，可靠性难以保证，而且整体的执行流程也会非常的缓慢。
通过Rocket MQ 将各关联的业务模块改为异步订阅发布模式，避免了各业务模块之间的过分关联和耦合，实现了业务模块之间异步通信和应用解耦。交易系统产生订单之后，只需要向消息队列发送订单产生消息即可返回，而后端的多个子应用系统则会在合适的时机、以异步方式消费订单消息。
这样，既可以保证主业务的连贯性，同时也可以避免因子业务执行时间过长或失败导致的主业务卡顿或无法正常执行。另外，这种设计模式对业务扩展性也非常良好，当有新的业务流程需要添加或修改时，不需要对其他的功能模块进行调整，只需要修改消息队列即可实现功能的替换或扩展。
五．实现分布式业务的最终一致性
业务之间关联并不是很紧密的系统，可以通过消息队列来实现解耦合和异步调用。而在需要保证数据一致性的某些场合，如交易、支付、红包等系统中，消息队列也有合适的用法，在介绍消息队列在一致性场合应用前，先来了解下强一致性和最终一致性。
强一致性：指当更新操作完成后，所有数据立刻更新，任何一次读操作，都能读到该数据最近一次的写入值，系统中所有的进程，看到的操作顺序，都和全局时钟下的顺序一致，即在任意时刻，所有节点中的数据相同。任何后续进程的访问，都会返回最新的更新值，这是对用户最友好的状态，即用户上次写入的数据，下次保证读入该数据，但在分布式系统中有一个著名的CAP，即任何一种分布式的一致性算法都无法做到在一致性、分区容错性和可用性之间全部满足，最多只能满足两个属性，而分区容错性是分布式系统的根本，因此只能在一致性和可用性之间进行选择。
对企业级互联网应用来说，可用性是最重要的技术指标，因此在企业级互联网应用中，通常采用的是支持可用性和分区容错性，也就是支持CAP原则中的AP原则，而放弃强一致性，转而采用最终一致性来代替强一致性。
最终一致性又称贝斯理论，即所有的数据副本在经过一段时间的同步之后，最终都一定达到一致的状态。最终一致性的本质：需要系统保证最终的数据能够达到一致，而不需要实时保证系统数据的强一致性。交易、支付、红包等产品实际上都需要保证数据的最终一致性。在引入消息队列RocketMQ之后，使用消息队列Rocket MQ的分布式事务通过消息可持久化，即使某些调用暂时失败，但由于消息已经被持久化，所以在若干次重试之后依然可以保证一致性。这样既可以实现系统之间的启用，又可以保证分布式事物的最终一致性。
六．实时计算和分布缓存
消息队列同样可以应用大数据场景、实时计算场景和分布式缓存系统。在典型的大数据场景中，系统需要从成百上千的数据源中实时收取大量数据，然后再将数据进行处理后存储或直接推入实时计算框架进行实时计算，这就需要数据收集组件具有强大的数据吞吐能力，同时当后端的数据计算出现延迟时，要求数据收集组件具有强大的消息堆积能力，而消息队列组件的技术特点正好能满足这两种需求。因此，在大数据应用场景下，开发者通常会使用消息队列来收集和汇总实时数据，然后再将汇总后的数据推送到大数据处理框架或实时计算框架中。
在大数据处理中，Kalfka 和 RocketMQ 都是常用的消息队列，而 Kalfka 和 Rocket MQ 的技术对比，在后面会进行学习。
另外，消息队列还可应用于分布式缓存系统。在大型互联网应用中，为避免数据库的独操作造成性能瓶颈，通常会采用缓存形式，将常用的热点数据提前加载到缓存中，以避免集中读取造成的性能损失。而在超大型系统中，集中式的缓存同样会造成系统单点的出现和缓存读取的性能瓶颈，这种情况下，超大型系统一般会采用分布式缓存的模式。将数据实时复制到多个分布式系统，应用能就近读取缓存，以提高并发性。
在分布式缓存的设计过程中，如何保证缓存数据的一致性是整个系统最大的技术难点，而消息队列的数据高可靠性和数据严格排队的技术特点是分布式缓存数据同步设计中理想的中间件产品选择。
