因业务发展需要现在的系统不足以支撑现在的用户量，于是我们在一周之前着手项目的性能优化与分布式部署的相关动作。 概况 现在的系统是基于RabbitHub（一套开源的开发时框架）和Rabbit.WeiXin（开源的微信开发SDK）开发的一款微信应用类系统，主要业务是围绕当下流行的微信元素，如：微官网、微商城、微分销、营销活动、会员卡等。 关于RabbitHub详情请戳： .NET 平台下的插件化开发内核（Rabbit Kernel） RabbitHub开源情况及计划 关于Rabbit.WeiXin详情请戳： .
RocketMQ 5.0： 云原生“消息、事件、流”实时数据处理平台，覆盖云边端一体化数据处理场景。
RocketMQ 消费异常，但是重试间隔时间太长（HTTP协议重试策略），需要快速定位到系统异常问题，所以需要手动在控制台发送消息并且发送。
背景：公司最早的一个版本的订单管理，是通过PHP+mysql的方案去实现的，这样会有什么问题呢，假设如果放到一个实例里面，全部用一个单机事务去解决，这样是能比较方便的解决数据一致性问题。但是存在两个问题，一是无法进行多实例部署，用户量增长以后，无法快速应对。二是，PHP中做事务，如果PHP遇到异常，有时并不会自动终止事务，导致DB被锁住，这是第一个版本。之后，我们推出了第二个版本V2，这个版本的时候，我们已经开发好了，库存管理系统，优惠券管理系统，PHP中，已经不直接通过DB去修改库存和优惠券，而是通过接口访问的方式去请求SERVER进行修改。这个版本，实际上已经从逻辑上，把订单系统和库存管理，优惠券管理系统已经独立出来了。数据层面已经可以独立部署，不再依赖一个单机事务去实现数据一致性功能了。但这个版本虽然解决了数据分布的问题，但同时引入了一个新的问题，就是数据在订单，库存，优惠券之间无法保证一致性。举个例子：下个订单，调用库存成功，锁定优惠券失败，生成订单失败。这时候就会导致优惠券数据不一致性情况出来，未下单的优惠券也被锁住了。有同事可能会问：订单如果创建失败，那直接回滚优惠券操作，即去解锁优惠券系统即可实现数据一致性。不错，很多时候，是可以这么操作，但如果你回滚的时候，失败了呢？你是继续在这等着直到成功，还是继续等着？呵呵。。
如果使用 Docker 技术来架构微服务体系，服务发现就是一个必然的课题。目前主流的服务发现模式有两种：客户端发现模式，以及服务端发现模式。 客户端发现模式 客户端发现模式的架构图如下： 客户端发现模式的典型实现是Netflix体系技术。客户端从一个服务注册服务中心查询所有可用服务实例。客户端使用负载均衡算法从多个可用的服务实例中选择出一个，然后发出请求。比较典型的一个开源实现就是 Netflix 的 Eureka。 Netflix-Eureka Eureka 的客户端是采用自注册的模式，客户端需要负责
继我上一篇博客后 分布式消息队列RocketMQ学习教程① 上一篇博客最主要介绍了几种常用的MQ，所以本博客再简单介绍一下RocketMQ的原理和简单的例子，基于Java实现，希望可以帮助学习者
基于 Docker 的容器技术是在2015年的时候开始接触的，两年多的时间，作为一名 Docker 的 DevOps，也见证了 Docker 的技术体系的快速发展。本文主要是结合在公司搭建的微服务架构的实践过程，做一个简单的总结。希望给在创业初期探索如何布局服务架构体系的 DevOps，或者想初步了解企业级架构的同学们一些参考。
官方文档: https://rocketmq.apache.org/zh/docs/introduction/02concepts
前言 基于 Docker 的容器技术是在2015年的时候开始接触的，两年多的时间，作为一名 Docker 的 DevOps，也见证了 Docker 的技术体系的快速发展。本文主要是结合在公司搭建的微服务架构的实践过程，做一个简单的总结。希望给在创业初期探索如何布局服务架构体系的 DevOps，或者想初步了解企业级架构的同学们一些参考。 Microservice 和 Docker 对于创业公司的技术布局，很多声音基本上是，创业公司就是要快速上线快速试错。用单应用或者前后台应用分离的方式快速集成，快速开发，快速
一：有一个很大的商品订单表，每天新增数十万条数据。每条数据有个到期时间，需要在到期时间后做一些处理，譬如关闭订单，改变状态之类的。
这个场景是非常常见，毕竟纯粹的单表的CRUD比较少，大部分时候都是操作了某个表、某个业务，然后需要多个表进行更改。
前言 循环依赖分为2类: RPC服务间（dubbo、http）循环依赖 应用间循环依赖 Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，防止Spring初始化完成。这种情况我们就叫做RPC服务间循环依赖。出现了循环依赖，必须有一方先启动。所以这种问题是一定需要解决的。 应用间循环依赖大致情况如下: A应用调用B应用的服务，B应用也会调用A应用的服务，无论是间接调用还是直接调用。 这种循环依赖刚开始不会出现问题 ，但随着代码变更，有可能会发展为RPC服务间循环依赖。 可以通过check=
在前一篇文章爬虫架构|利用Kafka处理数据推送问题（1）中对Kafka做了一个介绍，以及环境搭建，最后是选择使用阿里云的Kafka，这一篇文章继续说使用阿里云的Kafka的一些知识。 一、发布者最佳实践 发布的完整代码（根据自己的业务做相应处理）： package com.yimian.controller.kafka; import java.util.Date; import java.util.Properties; import java.util.concurrent.Future; impo
消息队列，缓存，分库分表是高并发解决方案三剑客，而消息队列是我最喜欢，也是思考最多的技术。
转自：https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka 淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用MySQL作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订
什么是事务？回答这个问题之前，我们先来看一个经典的场景：支付宝等交易平台的转账。假设小明需要用支付宝给小红转账 100000 元，此时，小明帐号会少 100000 元，而小红帐号会多 100000 元。如果在转账过程中系统崩溃了，小明帐号少 100000 元，而小红帐号金额不变，就会出大问题，因此这个时候我们就需要使用事务了。请参见图 6-1。
2018 年，做为架构负责人，接到一个架构需求：实现一个简单易用的 RocketMQ SDK 。
我们的系统完成某项操作之后，会推送事件消息到业务方的接口。当我们调用业务方的通知接口返回值为成功时，表示本次推送消息成功；当返回值为失败时，则会多次推送消息，直到返回成功为止(保证至少成功一次)。
公有 PaaS 平台并没有达成共识，没有统一应用的 PaaS 服务 API，因此不便于应用在各平台之间移植。谷歌、亚马逊与微软三大巨头在 PaaS 领域分庭对立，在强大的技术实力与基础资源的支撑下，构建了与自身文化相对应的公有云 PaaS 平台。相对于三大巨头，于2007 年起家的 Heroku，正是由于看到了大平台厂商对应用代码的“侵入性”，以及对开发人员的“绑架”，因而独辟蹊径地开发了一套可移植的 PaaS 平台。
分布式消息系统作为实现分布式系统可扩展、可伸缩性的关键组件，需要具有高吞吐量、高可用等特点。而谈到消息系统的设计，就回避不了两个问题：
RocketMQ作为一款分布式的消息中间件（阿里的说法是不遵循任何规范的，所以不能完全用JMS的那一套东西来看它），经历了Metaq1.x、Metaq2.x的发展和淘宝双十一的洗礼，在功能和性能上远超ActiveMQ。
为了防止消息重复消费导致业务处理异常，消息队列RocketMQ版的消费者在接收到消息后，有必要根据业务上的唯一Key对消息做幂等处理。本文介绍消息幂等的概念、适用场景以及处理方法。
文章摘要：借用小厮的一句话“消息队列的本质在于消息的发送、存储和接收”。那么，对于一款消息队列来说，如何做到消息的高效发送与接收是重点和关键
在我们的日常编程中，对消息队列的需求非常常见，使用一个简洁、高效的消息队列编程模型，对于代码逻辑的清晰性，对于事件处理的高效率来说，是非常重要的。这篇文章就来看看 ZWave 中是通过什么机制为我们提供了一个便捷的消息队列处理机制。
消息队列不知道大家看到这个词的时候，会不会觉得它是一个比较高端的技术，反正我是觉得它好像是挺牛逼的。
消息队列中间件可以说是Java开发中最常使用的一块技术了，基本上上了规模的系统都会使用消息队列来优化系统架构。那么为什么要使用消息队列？我们使用消息队列来解决什么问题呢？
本章节为大家讲解ThreadX的一个重要的通信机制----消息队列，初学者要熟练掌握，因为消息队列在实际项目中应用较多。
Message queue概述： 多个独立的进程之间可以通过消息缓冲机制来相互通信，这种通信的实现是以消息缓冲区为中间介质，通信双方的发送和接收操作均以消息为单位。 消息队列一旦创建后即可由多进程共享，发送消息的进程可以在任意时刻发送任意个消息到制定的消息队列上，并检查是否有接收进程在等待它所发送的消息，若有则唤醒它。而接收信息的进程可以在需要消息的时候到制定的消息队列上获取消息，如果消息还没有到来，则转为睡眠状态等待 消息队列是IPC对象的一种 消息队列有消息队列ID来唯一标识 消息队列就是一个消息的列别
公司用到的很多技术，自己之前都没学过(尬)，于是只能慢慢补了。这次给大家写写我学习消息队列的笔记，希望对大家有帮助。
在裸机编程中，经常会使用全局变量进行功能间的通信，如某些功能可能由于一些操作而改变全局变量的值，另一个功能对此全局变量进行读取，根据读取到的全局变量值执行相应的动作，达到通信协作的目的。而实时操作系统往往采用邮箱、消息队列、信号用于线程间的通信。
如果胖友还没了解过分布式消息队列 Apache RocketMQ ，建议先阅读下艿艿写的 《芋道 RocketMQ 极简入门》 文章。虽然这篇文章标题是安装部署，实际可以理解成《一文带你快速入门 RocketMQ》，哈哈哈。
MQ (MessageQueue) ，中文是消息队列，字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。消息队列是一种基于生产者-消费者模型的通信方式，通过在消息队列中存放和传递消息，实现了不同组件、服务或系统之间的异步通信。
消息的生产者将消息送到消息队列以后，由消息的消费者从消息队列中获取消息，然后进行业务逻辑的处理，消息的生产者和消费者是异步处理的，彼此不会等待阻塞，所以叫做异步架构。
分布式消息队列中间件是一种在分布式系统中负责消息传递的软件。它允许系统中的不同组件通过发送和接收消息来进行通信。分布式消息队列中间件可以提高系统的可伸缩性、可靠性和解耦性。本文将介绍如何从0到1手写一个简单的分布式消息队列中间件。
对于消息队列的操作，我们可以类比为这么一个过程：假如 A 有个东西要给 B，因为某些原因 A 不能当面直接给 B，这时候他们需要借助第三方托管（如银行），A 找到某个具体地址的建设银行，然后把东西放到某个保险柜里（如 1 号保险柜），对于 B 而言，要想成功取出 A 的东西，必须保证去同一地址的同一间银行取东西，而且只有 1 号保险柜的东西才是 A 给自己的。
前面文章介绍了Linux下进程的创建，管理，陆续介绍了进程间通信的方式：管道、内存映射、共享内存等。这篇文章继续介绍Linux的进程间通信方式消息队列。
消息队列：它主要用来暂存生产者生产的消息，供后续其他消费者来消费。它的功能主要有两个：a.暂存(存储)、b.队列(有序：先进先出)。其他大部分场景对数据的消费没有顺序要求，主要用它的暂存能力 。从目前互联网应用中使用消息队列的场景来看，主要有以下三个： 1. 异步处理数据 2. 系统应用解耦 3. 业务流量削峰
消息队列：消息队列的本质是由Linux内核创建用于存放消息的链表，并且其功能是用来存放消息的，所以又称之为消息队列。 在Linux的不同进程中，包括有血缘的进程和无血缘的进程，都可以通过Linux消息队列API所得到的消息队列唯一标识符对消息队列进行操作。
来了来了，消息队列系列总算来咯。对于搜索引擎相关的知识大家消化的怎么样呀？其实对于搜索引擎来说，我们学习的内容还是挺全面的，也算是比较深入了。而对于消息队列来说，我不准备写得太深入，因为对于这个东西，实战并不算多，主要的原因咱们在今天这篇文章结束的时候再详细的来说吧。
消息队列，一般我们会简称它为MQ(Message Queue)，嗯，就是很直白的简写。
消息队列这个概念其实在我之前的文章：手把手教姐姐写消息队列，自己动手用go写一个简易版的消息队列，有兴趣的小伙伴们可以看一下这篇文章。回归正题，我们再来介绍一下什么是消息队列。
精彩早知道 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务（见第二篇：大型网站架构系列：分布式消息队列（二）） 常用消息队列（见第二篇：大型网站架构系列：分布式消息队列（二）） 参考（推荐）资料（见第二篇：大型网站架构系列：分布式消息队列（二）） 本次分享总结（见第二篇：大型网站架构系列：分布式消息队列（二）） 一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
