RabbitMQ

安装RabbitMQ 看我之前的文章 修改配置文件 vim /usr/lib/rabbitmq/lib/rabbitmq_server-3.6.5/ebin/rabbit.app 修改：loopback_users 中的 <<"guest">>, 改成[] 这样远程能访问 心跳检测修改为10 heartbeat 为10 修改防火墙 firewall-cmd --zone=public --add-port=5672/tcp --permanent firewall-cmd --zone=public --add-port=15672/tcp --permanent #下面都是集群配置用到的端口 firewall-cmd --zone=public --add-port=25672/tcp --permanent firewall-cmd --zone=public --add-port=4369/tcp --permanent firewall-cmd --reload 启动RabbitMQ 试试好不好用 /etc/init.d/rabbitmq-server start rabbitmq-plugins enable rabbitmq_management 输入网址 xxx:15672 账户密码都是guest 进入镜像集群配置 以下是我的机器配置,换成自己的即可 主机ip

前言 通过前面的几篇文章，讲解了一个短信服务的架构设计与实现。然而初始方案并非100%完美的，我们仍可以对该架构做一些优化与调整。 同时我也希望通过这篇文章与大家分享一下，我的架构设计理念。 源码地址：https://github.com/SkyChenSky/Sikiro.SMS/tree/optimize （与之前的是另外的分支） 架构是设计的还是演变的？ 架构 该词出自于建筑学。软件架构定义是指软件系统的基础结构，是系统中的实体及实体（服务）之间的关系所进行的抽象描述。而架构设计的 目的 是为了解决软件 系统复杂度 带来的问题。 复杂度 系统复杂度主要有下面几点： 高可用 高性能 可扩展 安全性 维护成本 用户规模 业务规模 系统的复杂度导致的直接原因是业务规模。为了用户流畅放心的使用产品，不得不提高系统性能与安全。当系统成为人们生活不可缺一部分时，避免机房停电、挖掘机挖断电缆导致的系统不可用，不得不去思考同城跨机房同步、异地多活的高可用方案。 答案并非二选一 我认为架构，需要在已知可见的业务复杂度与用户规模的基础上进行 架构设计 ；伴随着技术积累与成长而对系统进行 架构优化 ；用户的日益增长，业务的不断扩充，迫使了系统的复杂度增加，为了解决系统带来新的复杂度而进行 架构演变。 因此，架构方案是在已有的业务复杂度、用户规模、技术积累度、人力时间成本等几个方面的 取舍 决策

微服务架构并不是一种新方法；多年来，它的核心思想一直以 SOA（面向服务的体系结构），Web 服务以及模块化和分层架构的形式存在。现在SpringCloud微服务架构无论是在工作中还是在面试中都是必不可少的一部分，作为一名程序员开发人员，这些都是必须会的！ 今天LZ在逛博客园的看到四份有关SpringCloud微服务架构的学习笔记，干货满满的，需要的小伙伴可以帮忙一键三连+评论，加小助手vx:bjmsb2019或者vx:1249448307即可！ Day1 微服务基础知识 随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服 务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 Day2 服务调用+服务注册+微服务架构+服务熔断 Day3 微服务网关：在学习完前面的知识后，微服务架构已经初具雏形。但还有一些问题：不同的微服务一般会有不同的网 络地址，客户端在访问这些微服务时必须记住几十甚至几百个地址，这对于客户端方来说太复杂也难以 维护。 Day4 在实际的企业开发中，消息中间件是至关重要的组件之一。 消息中间件主要解决应用解耦，异步消 息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。不同的中间件其实现方式，内 部结构是不一样的。如常见的RabbitMQ 和 Kafka ，由于这两个消息中间件的架构上的不同，像

1.安装好rabbitmq 2.新建一个springBoot项目：rabbitmq_demo 3.添加pom依赖： <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> </dependencies> 4.application.properties： server.port=8080 spring.application.name=rabbitmq_demo spring.rabbitmq.host=localhost spring.rabbitmq

1、消息如何保证100%的投递？ 2、幂等性概念 3、Confirm确认消息 4、Return返回消息 5、自定义消费者 消息 100% 的投递 消息如何保障 100%的投递成功？ 什么是生产端的可靠性投递？ u 保障消息的成功发出 u 保障MQ节点的成功接收 u 发送端收到MQ节点（Broker）确认应答 u 完善的消息进行补偿机制 BAT/TMD互联网大厂的解决方案： u 消息落库，对消息状态进行打标 u 消息的延迟投递，做二次确认，回调检查 幂等性概念 幂等性是什么？ u 我们可以借鉴数据库的乐观锁机制 u 比如我们执行一条更新库存的SQL语句 u Update t_repository set count = count -1,version = version + 1 where version = 1 u Elasticsearch也是严格遵循幂等性概念，每次数据更新，version+1（博主博客前面有提到） 消费端-幂等性保障 在海量订单产生的业务高峰期，如何避免消息的重复消费问题？ 消费实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息 业界主流的幂等性操作 唯一ID+指纹码机制，利用数据库主键去重 利用Redis的原子性去实现 唯一ID+指纹码 机制 唯一ID+指纹码机制，利用数据库主键去重 Select count(1) from T