一：带着问题思考? （WHAT,WHY,WHO,WHEN,WHERE,HOW,HOW MUCH） 1：消息如何保障100%的投递成功? 二：什么是生产端的可靠性投递？WHAT 1：保障消息的成功发出 2：保障MQ节点的成功接收 3：发送端接收到MQ节点（Broker）确认应答 4：完善的消息进行补偿机制 三：大厂解决方案 HOW 1：消息落库，对消息状态进行打标 2：消息的延迟投递，做二次确认，回调检查 四：可靠性投递消息落库，对消息状态进行打标 (方法一) 角色：Sender,Confirm Listener,MQ Broker MSG\_DB(status: 0-未确认 1-已确认 2-投递次数超过3次) Step 1: 角色：( Sender) 记录业务数据库biz\_ db,记录消息数据库msg \_db(且记录消息状态为0) Step 2: 角色：( Sender) 发送消息send Message ----- 角色: (MQ Broker) St

一：RabbitMQ概念 RabbitMQ是一个开源的消息代理和队列服务器，用来通过普通协议在完全不同的应用之间共享数据，RabbitMQ是使用Erlang语言来编写的，并且RabbitMQ是是基于AMQP协议的 1: RabbitMQ消息特点 开源、性能优秀，稳定性保障 提供可靠性消息投递模式(confirm),返回模式(return) 与SpringAMQP完美整合，API丰富 集群模式丰富、表达式配置、HA模式、镜像队列模型 保证数据不丢失的前提做到高可靠性 可用性 2: RabbitMQ高性能的原因 Erlang语言在最初交换机领域的架构模式，这样是的RabbitMQ在Broker之间进行数据交互的性能是非常优秀的 Erlang的优点: Erlang有和原生Socket一样的延迟效果，Socket有Netty高性能传输速度 3: AMQP高级消息队列协议 英文: Advanced Message Queuing protocol 具有现代特征的二进制协议。

消息队列也通常称为消息中间件，提到消息队列，大部分互联网人或多或少都听过该名词。对于后端工程师而言，更是日常开发中必备的一项技能。随着大数据时代的到来，apache 旗下的 kafka 一度成为消息队列的代名词，提起消息队列大家自然而然就想到了 kafka。近而网上有太多太多介绍消息队列 kafka 功能或者内部实现的文章。 然而消息队列本身是工程领域内一种解决问题的通用方案。它的背后有着一些通用的设计思想和经典模型，这些是消息队列的精髓和灵魂。它们独立于任何一种消息队列的具体实现(例如 kafka)，但每种消息队列(除了 kafka 外，还有 rocketMQ、pulsar 等)的实现中到处体现着这些设计思想。本文主要从抽象层面来简单谈谈消息队列背后的一些设计思想，辅助理解消息队列这一类组件。 本文主要解决三个问题： 1. 消息队列适合什么场景？ 2. 消息队列有哪些主流产品、各自的优缺点？ 3. 消息队列背后的设计思想(整体核心模型、数据存储考量、数据获取方案对比、消费者消费模型) 1.消息队列适合哪些场景？ 消息队列：它主要用来暂存生产者生产的消息，供后续其他消费者...

本文主要讨论这么几个问题： （1）啥时候数据库和缓存中的数据会不一致 （2）不一致优化思路 （3）如何保证数据库与缓存的一致性 一、需求缘起 上一篇《[缓存架构设计细节二三事](http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ &mid=404087915&idx=1&sn=075664193f334874a3fc87fd4f712ebc&scene=21 wechat_redirect)》（点击查看）引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库”这个点是大家讨论的最多的。 上篇文章得出这个结论的依据是，由于操作缓存与操作数据库不是原子的，非常有可能出现执行失败。 假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致【如

1. 什么是数据的一致性 “数据一致”一般指的是：缓存中有数据，缓存的数据值 = 数据库中的值。 但根据缓存中是有数据为依据，则”一致“可以包含两种情况： 缓存中有数据，缓存的数据值 = 数据库中的值（需均为最新值，本文将“旧值的一致”归类为“不一致状态”） 缓存中本没有数据，数据库中的值 = 最新值（有请求查询数据库时，会将数据写入缓存，则变为上面的“一致”状态） ”数据不一致“：缓存的数据值 ≠ 数据库中的值；缓存或者数据库中存在旧值，导致其他线程读到旧数据 2. 数据不一致情况及应对策略 根据是否接收写请求，可以把缓存分成读写缓存和只读缓存。 只读缓存：只在缓存进行数据查找，即使用 “更新数据库+删除缓存” 策略； 读写缓存：需要在缓存中对数据进行增删改查，即使用 “更新数据库+更新缓存”策略。 2.1 针对只读缓存（更新数据库+删除缓存） 只读缓存：新增数据时，直接写入数据库；更新（修改/删除）数据时，先删除缓存。后续，访问这些增删改的数据时，会发生缓存缺失，进而查询数据库，更新缓存。 新增数据时 ，写入数据库；访问数据时，

消息队列连环炮 1. 项目里怎么样使用 MQ 的？ 2. 为什么要使用消息队列？ 3. 消息队列有什么优点和缺点？ 4. kafka,activemq,rabbitmq,rocketmq 都有什么去呗？ 5. 如何保证消息队列高可用？ 6. 如何保证消息不被重复消费？ 7. 如何保证消息的可靠性传输？ 8. 如何保证消息的顺序性？ 9. 写一个消息队列架构设计？ 消息队列技术选型 解决的问题： 解耦 异步 削峰 不用 MQ 系统耦合场景 A 系统产生了一个比较关键的数据，很多系统需要 A 系统将数据发过来，强耦合（B,C,D,E 系统可能参数不一样、一会需要一会不需要数据，A 系统要不断修改代码维护） A 系统还要考虑 B、C、D、E 系统是否挂了，是否访问超时？是否重试？ 使用 MQ 系统解耦场景 ![437e657877a346518

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。 当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发的Notify、MetaQ、RocketMQ等。 本文不会一一介绍这些消息队列的所有特性，而是探讨一下自主开发设计一个消息队列时，你需要思考和设计的重要方面。过程中我们会参考这些成熟消息队列的很多重要思想。 本文首先会阐述什么时候你需要一个消息队列，然后以Push模型为主，从零开始分析设计一个消息队列时需要考虑到的问题，如RPC、高可用、顺序和重复消息、可靠投递、消费关系解析等。 也会分析以Kafka为代表的pull模型所具备的优点。最后是一些高级主题，如用批量/异步提高性能、pull模型的系统设计理念、存储子系统的设...

简介 RabbitMQ是一个由erlang开发的消息队列。消息队列用于应用间的异步协作。 基本概念 Message：由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key、priority、delivery-mode（是否持久性存储）等。 Publisher：消息的生产者。 Exchange：接收消息并将消息路由到一个或多个Queue。default exchange 是默认的直连交换机，名字为空字符串，每个新建队列都会自动绑定到默认交换机上，绑定的路由键名称与队列名称相同。 Binding：通过Binding将Exchange和Queue关联，这样Exchange就知道将消息路由到哪个Queue中。 Queue：存储消息，队列的特性是先进先出。一个消息可分发到一个或多个队列。 Virtual host：每...