qq_44949002的博客

消息队列一： 为什么使用消息队列？二： 使用消息队列有什么缺点?三： 消息队列如何选型?四： 如何保证消息队列是高可用的？五： 如何保证消息不被重复消费?六.： 如何保证消费的可靠性传输?七：如何保证消息的顺序性？八：消息的匹配九：消息的超时十：消息的保持十一：消息的错误处理十二、消息的吞吐量一： 为什么使用消息队列？(1)解耦传统模式:传统模式的缺点：系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！中间件模式:

1.使用场景：优惠券的倒计时提醒，消息推送，聊天，这些都是客户端主动的发送消息给服务器与服务器在发送到服务端的场景。 在不使用协议技术的情况下现在的机制都是一请求一响应（就是前端一请求后台响应）；现在整个网络都是构建在 tcp 长链接 可靠协议（有3次握手），和udp不可靠协议（没有3次握手）：tcp长链接，响应之后链路不会断开但是服务端或者客户端只要有一方断开这个链路就会断开; http是短链接：一请求一响应链路断开 java中对 tcp 的方案：bio （同步阻塞式io）， nio （异步非

一：优惠券抢券的情况比如有：15000请求 10000优惠券1.如果在单体架构上这种情况就有可能是无锁的状态 - 发生超发解决方案加锁：synchronize2.如果是在分布式架构的业务加锁就锁不住了解决方案：redis分布式锁---------------数据库锁的方案：悲观锁：表锁 - 锁表行锁 - 锁行共享锁：（读锁）A事务对某一行添加了共享锁，其他事务就不能再对该行添加排它锁了，但是任然可以添加共享锁使用排它锁（方案）：（写锁 ）A事务对某一行添加了排他锁，

在实现lua脚步的时候本质上是有风险的，因为redis并不是完全可靠的比如生成的订单和扣减的库存都往里面丢，假如redis出问题了数据是有可能会丢失掉的，那么这个怎么解决呢？我们在redis判断库存同时异步的修改数据库。当客户端大量的抢卷请求，请求抢卷服务去扣减redis的优惠券库存，在写到mq中，由优惠券服务去监听mq，然后修改数据库优惠券的库存，生成优惠券的领取记录。疑问：那最后不还是操作了数据库嘛？这个操作数据库和上层mq进行了解耦，mq在这里有两个作用：1.请求销锋-- 通过redis的方式.

@Cacheable通常用于查询业务，先去缓存服务器查询，如果有结果直接返回，如果没有，再调用目标方法执行业务，并且将目标方法的返回值重建到缓存中在这里插入图片描述先查询了redis发现redis没有于是就查询了数据库，当我点击多次的查询的时候也不在查询数据库了我们发现在redis中keys是stucache::stulist ，get 获取类似也可以发现是string这说明value完全序列化到里面了，也就是业务数据1.2 ：我们发现每次都要设置cachenames于是我..

1.redisTemplate和stringRedisTemplate的区别是：redisTemplate是带序列 化的，redis是没办法对序列化的东西自增的。比如：redisTemplate.opsForHash().entries()就无法自增。2.redis的分布式锁lua脚本 我们的lua脚本是写在java中的在发给redis，如果这个lua脚本被频繁的执行，都要发一次rdis执行脚本还不如先缓存到redis，redis在返回一个签名，这个签名是和lua脚本是一一对应的关.

什么是交换机？创建交换机一般都是在启动类创建，需要配置@Configuration，表示声明当前类是一个配置类（相当于一个Spring配置的xml文件）要配合@Bean来使用。2.发布消息到交换机，广播事件本质上最后会把写的字符串转成字节数组，用这个方法convertAndSend会自动转换@Autowiredprivate RabbitTemplate rabbitTemplate;rabbitTemplate.convertAndSend(“hotal_exchange”,“ho

架构封装得思考何时调用开发者的方法，开发者的思想是如何处理1.定义交换机的名字和事件常量public interface EventConstact { /** * 交换机的名称 */ String EXCHANGE_NAME = "event-exchange"; /** * 事件类型常量 */ String EVENT_LOGIN = "login";//用户登录事件 String EVENT_HOTAL_INS

消息中心的设计与实现一、引言运用场景：1、消息的主动提醒（客户端被动接收）2、客户模块（及时通讯）3、单一登录（一个账号只能在一个设备登录）消息中心的实现方案：1、客户端轮询2、TCP长连接（常用）Java的长连接的方案Java - Blocking I/O - JDK1.0 (同步阻塞式IO)Java - Non Blocking I/O - JDK1.4（同步非阻塞式IO）第三方的组织 - Mina、Netty（NIO）Java - Async I/O -JDK1.7

今天我们一起来探讨：全量的消息队列究竟有哪些？ Kafka、RocketMQ、RabbitMQ的优劣势比较，以及消息队列的选型1.解耦解耦是消息队列要解决的最本质问题。2.最终一致性最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。最终一致性不是消息队列的必备特性，但确实可以依靠消息队列来做最终一致性的事情。2.广播消息队列的基本功能之一是进行广播。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。

一、引言什么RabbitMQ？RabbitMQ是基于amqp协议，实现的一种MQ理念的服务。类似的服务 RocketMQ、ActiveMQ、Kafka等为什么在分布式项目中需要一款消息中间件？消息中间件能够实现一些Feign（同步调用）无法实现的效果：1、服务的异步调用2、消息的广播（事件总线）3、消息的延迟处理4、分布式事务5、请求削峰（处理高并发）二、RabbitMQ的Docker安装1）拉取镜像docker pull rabbitmq:3.8.5-management

一、引言1、什么是Redis？Redis是一款基于内存的键-值型NoSQL数据库。NoSQL - 非关系型数据库特点：可以进行快速的数据读写，官方给的数据 11W/s 读 8W/s 写。Memcache2、Redis在实际开发中的运用场景1）作为分布式系统的缓存服务器2）应对数据高速读写的业务3）作为分布式锁使用（Zookeeper、Redis）4）数据共享5）ID自增序列二、Docker安装Redis1）在合适位置准备好redis.conf配置文件./redis