RabbitMQ

项目摘要 vhr 是一个基于 SpringBoot+Vue 技术栈开发的前后端分离项目，项目使用 SpringBoot2.1.8 来开发，集成了当前企业级开发中众多的热门技术点，如消息中间件、Redis 缓存、SpringBoot+Vue+ElementUI 技术栈等等。 技术选型 核心框架：SpringBoot2.1.8 安全管理：Spring Security 持久层框架：MyBatis 缓存：Redis 数据库：MySQL8 消息队列：RabbitMQ 即时通信：WebSocket 文件存储：FastDFS 前端框架：Vue+ElementUI+Vuex 前端网络请求：axios 技术要点 基于 Spring Security 搭建动态权限管理系统。 前端 Vue 采用动态路由，千人千面。 结合 RabbitMQ 搭建独立的邮件服务器。 基于 WebSocket 实现在线聊天功能。 Redis 做缓存并协助处理消息幂等性问题。 采用 FastDFS 做文件存储系统。 ... 开发文档 作者为这个项目已经写了五十余篇开发文档，详细记录了项目的发开历程，从数据库设计到业务功能实现，都做了详细介绍， 文档足足有 141 页 ，我截一部分图给大家参考下： 另外，为了方便大家学习，文档还提供了在线网站版： 这个文档目前还在不断更新中。所有这一切，只为了大家能够快速掌握这个项目。

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 有人说，程序员总是对好的东西如数家珍，对不好的东西置若罔闻。2015 年，当微服务炒作开始飞起，每个人都在议论它的好处： 弹性； 伸缩性； 易于部署； 清晰的边界。 我们公司也从单体转向了微服务，但最后在二者之间找到了一个平衡点。微服务的一些好处是切实存在的，但它的一些缺点和潜在风险也不可忽视。 从单体到微服务 我于 2017 年加入公司，当时我们的团队大约有 20 名工程师，我们的应用程序是一个部署在 ECS 上的 Django 单体。 在过去两年里，我们开发了很多新服务，以下是一个不完整的清单： 票据服务：管理客户票据； 收费服务：管理 Stripe 的收费和支付； 定价服务：管理服务定价； 匹配服务：为企业经理和供应商之间牵线搭桥； 消息服务：管理聊天功能； 通知服务：管理推送通知、应用内通知和邮件； 审核服务：供应商审核客户； Netsuite 同步服务：将数据同步到 Netsuite； Salesforce 同步服务：将数据同步到 Salesforce； Stripe 同步服务：Stripe 和我们的系统之间的一个传输层； RDS 监控服务：确保我们的 Postgres 数据库正确备份； Datadog 监控服务：监控 Datadog 代理运行正常； GitHub

现有项目需要做一个长连接通讯，我打算采用netty+通讯队列实现， 通讯队列最初打算用rabbitMQ或者kafaka,但是考虑到实施的同事的项目部署的问题，就该为现有的redis了，采用的是redis队列 @Component public class RedisClient { private static Logger logger = LoggerFactory.getLogger(RedisClient.class); @Autowired private RedisTemplate<Object, Object> redisTemplate; /** ---------------------------------- redis消息队列 ---------------------------------- */ /** * 存值 * @param key 键 * @param value 值 * @return */ public boolean lpush(String key, Object value) { try { redisTemplate.opsForList().leftPush(key, value); return true; } catch (Exception e) { logger.error("e:",e); return false; }

一、简介 Redis 它的英文全名是 Remote Dictionary Server ，翻译成中文叫做远程字典服务。是由C语言编写的，遵守BSD协议，完全开源免费的一款NoSql数据库。 BSD是" Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。 BSD 开源协议 是一个给于使用者很大自由的协议。可以自由的使用，修改 源代码 ，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件： 1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。 2． 如果 再发布 的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。 3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发 商业软件 发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 二、redis特点 redis是一个高性能的key-value数据库 redis性能极高，一般情况下

QuickStart 基于SpringCloud体系实现，简单购物流程实现，满足基本功能：注册、登录、商品列表展示、商品详情展示、订单创建、详情查看、订单支付、库存更新等等。 github源码地址： https://github.com/backkoms/simplemall 每个业务服务采用独立的MYSQL数据库，初期考虑用到如下组件： 服务注册、发现: eureka 配置管理:spring config , spring security 集群容错: hystrix（待实现） API网关: zuul（待实现） 服务负载:feign+ribbon api文档输出:swagger2 代码简化:lombok 消息队列:rabbitmq 分布式锁: redis （待实现） 链路跟踪:spring cloud sletuh ->zipkin 安全认证:oauth2/JWT(待实现) 服务监控:spring-boot-admin 各模块介绍 模块名称 端口 简介 admin-server 9002 服务监控中心，监控所有服务模块 conf-server 9004 分布式配置中心，结合spring-security/rabbitmq同时使用 eureka-server 9003 服务注册中心，提供服务注册、发现功能 sleuth-server 9001

最近业务中有有这样一个场景，就是用户在商城下单之后，如果30分钟没有付款，那么就需要将这个订单处理掉，要么直接删除，要么直接标识为失效状态，为什么要这么做？ 1、库存，用户在下单之后，会锁定一个库存，如果用户一直不支付，那么就会占用库存，影响别的用户购买， 2、随着业务的发展，用户量的增加，我们的订单数据会越来越多，那么我们要及时的清理无效的订单，提升系统的性能； 曾经的纯洁无瑕 首先说下，我曾经那些纯洁无瑕的想法，第一次看到这种需求的时候，如果要清理失效的订单，那我直接写一个定时任务，5分钟或者10分钟跑一次，删除过期的订单，增加库存。 定时任务确实可以解决上面的问题，但是存在一个现实的问题，那就是数据库压力，甚至影响整个系统的性能，如果你是几百、几千个订单还好，要是十几万、甚至上百万，那么此方法肯定是行不通的。 进阶版本 既然发现了上面的方法不行，那么就重新想办法，有什么办法可以不用查询数据库，就可以知道哪些订单快要过期，再这样的思考下，我用Redis做了一个消息队列，当生成订单的时候，生成一个延迟10分钟消息，10分钟结束的时候，就会从Redis的队列中将这个订单取出来，然后这样我就可以将这个订单删除，增加库存。 Redis做消息队列存在的问题 之前用一个全新的Redis做消息队列，存储的数据也不多，感觉还好，当随着业务增加，Redis存储超过90%的时候

手写一个消息队列和延迟消息队列 1）消息队列的使用场景 1.1）商品秒杀 1.2）系统解耦 1.3）日志记录 2）消息中间件 RabbitMQ 3）手写一个消息队列和延迟消息队列 1）消息队列的使用场景 1.1）商品秒杀 在做秒杀活动时，会发生短时间内出现爆发式的用户请求，如果不采取相关的措施，会导致服务器忙不过来，响应超时的问题，轻则会导致服务假死，重则会让服务器直接宕机，给用户带来的体验也非常不好。如果这个时候加上了消息队列， 服务器接收到用户的所有请求后，先把这些请求全部写入到消息队列中再排队处理，这样就不会导致同时处理多个请求的情况 ；如果消息队列长度超过可以承载的最大数量，那么我们可以抛弃当前用户的请求，通知前台用户“页面出错啦，请重新刷新”等提示，这样就会有更好的交互体验。 1.2）系统解耦 使用了消息队列之后，我们可以把系统的业务功能模块化，实现系统的解耦。例如，在没有使用消息队列之前，当前台用户完善了个人信息之后，首先我们需要更新用户的资料，再添加一条用户信息修改日志。但突然有一天产品经理提了一个需求，在前台用户信息更新之后，需要给此用户的增加一定的积分奖励，然后没过几天产品经理又提了一个需求，在前台用户信息更新之后，不但要增加积分奖励，还要增加用户的经验值，但没过几天产品经理的需求又变了，他要求完善资料无需增加用户的积分了，这样反反复复、来来回回的折腾

欢迎访问我的个人博客 http://home.znfang.ml 说明 重发机制是在mq中很重要的一部分，消费者可以通过ack或者nack就可以很轻松实现消息重新入队列，然后进行重发，但是生产者也有可能在网络动荡的情况下，投递不成功，这个时候就需要消息重发。虽然rabbitmq提供了事务功能，但是如果开启事务，就太影响性能了。本文参考 littersmall的博文 ,利用spring-boot的定时功能，在本地缓存，从而实现对失败的消息进行重发。完整的项目代码请参考本人 spring-boot练习代码 实现过程 pom依赖 在pom文件中引入rabbitmq依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> yaml文件 在yaml文件中添加以下配置，一定要开启手动确认和手动返回 spring: rabbitmq: host: localhost port: 5672 username: guest password: guest publisher-confirms: true publisher-returns: true msgWithTime 为了进行消息重发，需要重新定义一个结构

问：你们现在系统里有用消息队列么？ 答：有 这是一个面试官给你埋坑的开始！！大量的系统都有引入使用消息队列，也是目前业内比较流行的。还有比如 ZooKeeper、Redis、Dubbo 等等，都是目前比较热门的技术。在这里要小心了！面试官此时想慢慢过渡到你具体的业务场景中去了，关心你3个点：解耦、异步和削峰。 问：为什么要在系统中使用消息队列呀？ 答：emmm... 老板做好架构设计、技术选型之后，然后就让我们落地实现 兄弟！千万别脱离了需求分析、架构设计、技术选型和资源评估，只是关心技术的落地实现，往往是没经过深度思考的朋友才干的事儿。只是为了用而用，不知道在此架构设计下为啥会用某些技术。 问：系统中引入了消息队列，会不会有啥隐患？ 答：还没遇到过... 这里就惨了！！如果没做过深度技术调研，盲目地直接在系统中引入不熟悉的技术，这就坑爹了，也是挖坑小能手经常干的事儿。比如，可能会遇到这两个问题：第一，链路变长，造成请求响应时间变长，影响用户体验。第二，MQ本身高可用很重要，不然造成整个系统的瘫痪。 问：消息队列的产品有 RabbitMQ、RocketMQ、Kafka 等，你们选用哪个？技术调研后的依据是啥？ 答：&%#@*…！/(ㄒoㄒ)/~~ 那，我们还能不能好好搞懂 MQ？ 答案是可以的，小编整理了一套技术资料不仅能精准消除技术盲点、累计面试经验，更可以攻克MQ、JVM

来源：KL博客 http://www.kailing.pub/article/index/arcid/188.html 1、前言碎语 博主公司一个项目在开发中使用某些功能的时候，受限于spring低版本的限制，故索性将整个模块升级为spring boot，在这里做个记录，希望能帮助到有相同场景的朋友。 整个改造过程非常简单，耗时大概在2个小时左右，主要解决项目中的各种版本冲突，不过下面我会介绍一个神器。 2、老项目情况 1.项目使用spring-context作为容器，使用 RabbitMQ 提供RPC服务 2.spring.springframework 版本比较低，3.1.x的版本，升级后会变成4.3.x 3.项目使用 maven 构建 以上是项目的基本情况，针对如上情况，下面会详细描述改造过程中需要的关注点。 第一步：添加spring boot依赖 <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.7.RELEASE</version> <scope>import</scope> <type>pom</type