Wang的专栏

在分布式系统中，消息队列作为异步通信的重要组件，其可靠性和稳定性至关重要RocketMQ 是阿里巴巴开源的一款高性能、高可靠性的分布式消息中间件，广泛应用于各种场景，如交易订单处理、日志收集、流计算等RocketMQ 通过多种机制确保消息的可靠性投递，包括持久化存储、主从复制、事务消息、消息确认、消息的持久化、复制与同步、顺序性、事务性、消费确认、失败重试以及监控和报警等机制开发者可以根据实际需求选择合适的配置和策略，以确保系统的稳定性和可靠性。

1 ） 什么是消息积压在分布式消息系统中，消息积压是指消息生产速度超过消息消费速度，导致未处理的消息在消息队列中累积的现象这种现象可能会导致系统性能下降、资源占用增加，甚至影响系统的正常运行2 ）消息积压通常由以下几个原因消费者数量不足，无法跟上生产者的生产速度单个消费者的处理能力有限，无法高效处理大量消息消费者存在性能瓶颈，如 CPU、内存或网络带宽不足生产者发送消息的速度过快，超过了消费者的处理能力生产者并发度高，短时间内产生大量消息网络延迟或不稳定，导致消息传输效率低下。

1 ) KongKong 是微服务中的一个网关组件，它具有高可用和扩展性能提供易于使用的 restfulAPI 来操作和配置api管理系统这个很关键也很方便啊，对它的操作完全都可以通过api来实现，并且也有相应的管理界面，当然没有管理界面也可以所有的功能都可以通过api来实现，同时，它也可以通过负载均衡的功能，把请求均匀分发到各个服务器上来应对大量的请求Kong 它的原意为金刚, 是用来形容强健、力量、坚固和稳定。

微服务中的有一个非常关键的组件: API网关和配置中心一样，在没有采用微服务架构的时候我们可以自己搭建自己的API网作作为统一的 API 出口和安全验证在微服务架构之下，服务被拆的非常的零散，在降低了耦合度的同时也给服务的统一管理增加了难度，就如下边这张图在旧的服务治理下，像身份验证, 限速, 安全, 日志等等这些通用的功能需要在每一个服务中单独实现, 这使得系统的维护就没有一个全局的视图来统一的管理这些功能Api 网关致力于解决这些问题，它为微服统一管理这些通用的功能。

相比 K8s 集群的其他功能，私有镜像的自动拉取，看起来可能是比较简单的而镜像拉取失败，大多数情况下都和权限有关所以，在处理相关问题的时候，我们往往会轻松的说：这问题很简单，肯定是权限问题但实际的情况是，我们经常为一个问题，花了多个人的时间却找不到原因这主要还是我们对镜像拉取，特别是私有镜像自动拉取的原理理解不深顺序上来说，私有镜像自动拉取会首先通过阿里云 Acr credential helper 组件。

服务器会为每个消息创建索引（哈希索引），应用可以通过 topic，key 来查询这条消息内容，以及消息被谁消费。如果调用 send 同步方法发送失败，则尝试将消息存储到 db，由后台线程定时重试，保证消息一定到达 Broker。死信队列：当消息重试次数超过最大重试次数后，消息会被放入死信队列中，死信队列的名称格式为 %DLQ%对于精于发送顺序消息的应用，由于顺序消息的局限性，可能会涉及到主备自动切换问题，所以如果。4.3. 使用顺序消息生产者，创建顺序消息生产者时，需要指定消息的顺序类型。

Broker 重启可能会导致正在发往这台机器的的消息发送失败，RocketMQ 提供了一种优雅关闭 Broker 的方法，通过执行以下命令会清除 Broker 的写权限，过 40s 后，所有客户端都会更新 Broker 路由信息，此时再关闭 Broker 就不会发生发送消息失败的情况，因为所有消息都发往了其他 Broker。每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采用同步双写方式，主备都写成功，向应用返回成功。Broker 启劢时，如何加载配置。

1 ） 客户端 API 形式DefaultMQProducer、TransactionMQProducer、DefaultMQPushConsumer、DefaultMQPullConsumer 都继承于 ClientConfig 类，ClientConfig 为客户端的公共配置类客户端的配置都是 get、set 形式，每个参数都可以用 spring 来配置，也可以在代码中配置，例如 namesrvAddr 这个参数可以这样配置，其他参数同理2 ）客户端的公共配置参数名默认值说明。

1 ) 简单消息过滤```java/** * 订阅挃定topic下tags分别等亍TagA戒TagC戒TagD*/consumer.subscribe("TopicTest1", "TagA || TagC || TagD");```- 如以上代码所示，简单消息过滤通过指定多个 Tag 来过滤消息，过滤的动作在服务器进行2 ) 高级消息过滤

(3). Commit Log 中存储了所有的元信息，包含消息体，类似于 Mysql、Oracle 的 redolog，所以只要有 Commit Log 在，Consume Queue 即使数据丢失，仍然可以恢复出来。如果系统中堆积的消息过多，读数据要访问磁盘会不会由于随机读导致系统性能急剧下降，答案是否定的。单队列幵行消费采用滑动窗口方式并行消费，如图所示，3~7 的消息在一个滑动窗口区间，可以有多个线程并行消费，但是每次提交的 Offset 都是最小 Offset，例如 3。4 ）服务器消息过滤。

RocketMQ 选择了第一种方式，mmap+write 方式，因为有小块数据传输的需求，效果会比 sendfile 更好。Consumer 消费消息过程，使用了零拷贝，零拷贝包含以下两种方式。上图是 RocketMQ 网络部署特点。1 ) 物理部署结构。2 ) 物理部署结构。4 ） 存储目录结构。

要了解 RocketMQ 的多个关键特性的实现原理，并对消息中间件遇到的各种问题进行解决我们引用 JMS 规范 与 CORBA Notification 规范，规范为我们设计系统指明了方向但是仍有不少问题规范没有提及，对于消息中间件又至关重要RocketMQ 并不遵循任何规范，但是参考了各种规范不同类产品的设计思想。

RocketMQ 是一款分布式、队列模型的消息中间件，具有以下特点：能够保证严格的消息顺序提供丰富的消息拉取模式高效的订阅者水平扩展能力实时的消息订阅机制亿级消息堆积能力选用理由：强调集群无单点，可扩展，任意一点高可用，水平可扩展。海量消息堆积能力，消息堆积后，写入低延迟。支持上万个队列消息失败重试机制消息可查询开源社区活跃成熟度（经过双十一考验)

注意，这里在 server 192.168.0.102;这两台服务器上启动 chat.exe 程序。需要提前 go build 并进行相关部署，此处不在赘述，下面会有说明。代码实现解决，ctrl/chat.go。常见 nginx 反向代理方案。1 ）windows 下。2 ） 局域网通信协议。1 ） 使用消息总线。3 ） 实现调度应用。2 ）Linux 下。

在即时通讯（IM）系统中，实现多媒体消息（如文本、表情包、拍照、图片、音频、视频）的实时传输是一项核心功能随着HTML5和WebSocket技术的发展，现代Web应用能够支持更高效、更实时的通信方式本文将详细探讨如何使用Go语言结合WebSocket技术，在IM系统中实现多媒体消息的发送和接收。

在即时通讯（IM）系统开发中，好友列表和群组管理是两个核心功能，它们为用户提供了便捷的交流平台使用Go语言（通常简称为Go）来构建这些功能，可以充分利用其高并发、简洁易读以及强大的标准库支持等优势本文将概述如何使用Go语言设计和实现一个IM系统中的好友列表显示和群组管理功能。

IM系统允许用户通过网络实时发送和接收消息它通常包括用户注册、登录、消息发送、接收、存储以及用户状态管理等核心功能其中，登录功能是用户访问IM服务的第一步，它确保了系统的安全性和用户数据的准确性。

整个IM系统的一般架构如下我们这张图展示了整个IM系统的一般架构可见分为四层那最上面这一层是前端，包括哪些东西呢？它包括两部分，第一部分是跟用户直接交互的比如说各种IOS APP, 各种安卓 APP还有各种 web APP 在浏览器里面打开的以及windows上面跑的那种客户端第二部分是跟我们程序相关的SDK，API，Websocket这些我们都统称为前端第二个是接入层，这里展示了几种常用的接入协议实际上还会用到Mqtt, Xmpp 等各种协议这是接入层。

使用Go语言打造支持，同时十万人在线的IM系统系统单机支持十万人，如果分布式部署后，支持数百万都是可以的IM 系统，比如说我们的微信，QQ，因IM系统，它具备非常独特的几个特性第一个特性，它本身是结合社交产品电商产品以及办公类产品的标配第二个特性，我们的产品，它的技术含量非常高打个比方，我们的微信群里面，每天可能没什么聊天的话语但是突然之间因为一些突发事件，那整个微信群就数十条上百条聊天记录一下子就爆了这时候对我们整个系统的应对突发事件的这个能力要求就非常高了。

我们的 redis 一般都是集群来给我们程序提供服务的，单体的redis现在也不多见看到上面是主节点redis和下面是6个重节点redis，主节点和重节点的通讯都是畅通没问题的这个时候，我们有 gorouting 写我们的数据，那它就会用到我们的setNX写完数据内部是自动同步的，就是你的这个数据通过主节点同步到这些从节点了下面又有我们的 gorouting 去读我们的从节点，但是，我们是在高并发和网络不确定的情况下可能会遇到一些问题。

随着云计算和大数据技术的飞速发展，分布式系统已经成为现代IT架构的重要组成部分在分布式系统中，数据的一致性是一个至关重要的挑战，特别是在并发访问和修改共享资源的场景下分布式锁是一种跨进程、跨机器节点的互斥锁，用于控制多个节点对共享资源的访问。其核心目标是确保在分布式系统中，同一时刻只有一个节点能够访问特定的共享资源，从而实现数据的一致性。分布式锁的实现方式多种多样，包括基于数据库、缓存（如Redis）、分布式协调服务（如Zookeeper）等。

在分布式系统中，并发控制和数据一致性是至关重要的问题当多个服务或进程需要访问和修改共享资源时，我们必须确保在同一时间只有一个服务或进程能够执行操作，以防止数据竞争和不一致，这就是分布式锁要解决的问题Redis 作为一个高性能的键值存储系统，经常被用作实现分布式锁的工具。Redis 的 SETNX、EXPIRE、DEL 等命令可以组合起来实现一个简单的分布式锁，但是，直接使用这些命令可能会引入一些复杂的逻辑和潜在的错误因此，许多开发者选择使用现成的库来简化分布式锁的实现在 Go 语言中，

乐观锁（Optimistic Lock）是一种并发控制策略，与悲观锁相对，它基于一种“乐观”的假设，即在大多数情况下，数据访问不会产生并发冲突乐观锁尽量减少锁的使用，从而提高了系统的并发性能，尤其适用于读多写少的场景乐观锁并不在数据访问前进行加锁，而是在数据更新时才检查数据是否被其他事务修改过这种机制假设读操作远多于写操作，而且在大部分情况下，数据在读取和更新之间的这段时间内不会被其他事务修改如果在更新时发现数据已被其他事务修改，则乐观锁通常会抛出异常或返回错误，由应用程序决定如何处理冲突。

悲观锁，作为并发控制领域的重要概念，广泛应用于数据库管理系统、多线程编程以及其他需要协调资源访问的场景中悲观锁（Pessimistic Lock），顾名思义，基于一种“悲观”的假设，即认为在数据处理过程中，很可能会发生并发冲突因此提前对数据加锁，以防止其他事务或线程的并发修改这种机制牺牲了一定的并发性能，以换取数据的一致性和安全性悲观锁的核心思想在于“先获取锁，再操作”在获取锁的过程中，如果资源已被其他进程锁定，则当前进程必须等待锁释放。

我们先看一个场景，到了双11，我们的商户又开始卖商品啦但是，我们的库存是有限的，如果超卖了，可能平台就会涉及相关法律责任了所以，我们的库存扣除问题，一定是一个非常经典的问题先看上图，我们库存服务部署在一台机器上，现在有 2个 Goroutine这个库存是被并发读取的，但是读取后扣除明显是一个异步的问题用 Goroutine 来模拟并发, 2个Goroutine 分别是G1, G2 都去下单，扣减库存一共100件，2个Goroutine查询的时候很可能都还是100。

不过，如果您的需求是希望消费者也以某种形式参与到事务的最终确认中，比如基于消息的消费结果来决定是否提交事务，这在RocketMQ的标准事务消息模型中并不直接支持。在提供的消费者示例中，尽管它看起来是一个普通的消费者，但实际上它处理的是生产者通过事务消息流程提交后的内容，这符合事务消息的消费逻辑。因此，对于事务消息的消费者来说，其主要职责是消费那些已经被事务提交成功的消息，而不需要直接参与事务的提交或回滚过程。消费者代码看起来与普通消息的消费者相似，但消费的消息实际上是生产者已经提交成功的事务消息。

比如这个订单服务，无论你是先发送消息，还是先新建订单，它其实都是发送的不可靠消息就是说如果这个消息，像mysql事务那样，只要订单服务不确认，下游就没办法消费如果你这个订单服务挂了，就可以取消这个消息，就不用做这个本地消息表了本地消息表，要有一个这个循环的这么一个查询，高并发的时候，你本地的数据库本身压力就大

我们的业务场景是可以允许我们一段时间有不一致的消息的状态的，并没有说必须特别高的这个消息的一致性比如说在TCC这个架构中，如果采用了消息的最终一致性，整体架构设计要轻松好多即便我们库存服务挂了，或者我们积分服务挂了也没有关系，只要我们有中间的这个消息，那就是没有问题的因为你在消息消费中，如果你你没有消费成功，那么消息就会一直存在在这个消息队列里。

T: Try 预处理, 尝试执行，完成所有的业务检查，做好一致性，预留必要的业务资源，做好准隔离性C: Confirm 确认，如果所有的分支Try都成功了, 就到了这个阶段, Confirm 是真正执行业务的过程, 不做任何业务检查, 只使用 try 阶段预留的业务资源C: Cancel 取消，所有的分支中，如果有一个失败了，则走到 Cancel 的阶段，Cancel 就释放了 Try 阶段预留的业务资源所以，Confirm 和 Cancel 是互斥的，只会执行一个，按照TCC的协议，Confirm

二阶段提交（Two-Phase Commit，2PC）是一种分布式事务协议，用于在分布式系统中确保多个参与者的操作具有原子性即所有参与者要么全部提交事务，要么全部回滚事务，以维持数据的一致性它分为两个阶段进行：第一阶段：准备阶段（Prepare Phase），第二阶段：提交阶段（Commit Phase）

在当今的互联网时代，分布式系统已成为支撑大规模服务、高并发和高性能应用的基石它们通过网络连接多台计算机，协同工作，共同完成任务，但这也引入了诸如数据一致性、网络延迟、容错性等挑战解决这些问题的关键在于设计和实施有效的分布式协议分布式很重要，因为微服务中需要用到分布式。

CAP理论C: 一致性，是站在分布式的角度，要么读取到数据，要么读取失败，比如数据库主从，同步时的时候加锁，同步完成才能读到同步的数据，同步完成，才返回数据给程序，这样就能解决数据不一致的问题，简单来说，就是保证数据最新A: 可用性，任何客户端请求，都能得到响应式数据，不会出现响应错误，但可能不包含最新的写入数据，简单来说，就是保证数据不出错P: 分区容错性，由于分布式系统都是通过网络通信的，网络是不可靠的，当任意数量的消息丢失或延迟到达的时候，系统仍然提供服务, 不会挂掉，简单说，就是一直运行，不管

参考最新官方文档：https://rocketmq.apache.org/zh/docs/quickStart/03quickstartWithDockercompose以及：https://rocketmq.apache.org/zh/docs/deploymentOperations/04Dashboard综合以上两个文档来搭建环境

以上是简单的环境搭建和生产消息，以及延迟消费消息的 demo 示例实际场景中，结合以上demo，对一些异步发送消息的场景进行灵活运用和升级。

在分布式系统和微服务架构中，消息队列（Message Queue）是一个核心组件，用于在不同的应用程序或服务之间异步传递消息在 Go 语言中，有多种实现消息队列的方式，包括使用开源的消息队列服务（如 RabbitMQ、Kafka、RocketMQ）和 基于 Go 语言的消息队列库。

在当今的微服务架构中，API网关扮演着至关重要的角色，它作为系统的统一入口负责处理所有内外部请求，实现路由转发、负载均衡、安全控制、限流熔断等多种功能Kong，作为一个开源、高性能、可扩展的API网关，凭借其强大的插件系统和易于部署的特性，成为了众多企业和开发者的首选Kong的插件架构使得其功能扩展变得非常简单，用户可以根据自己的需求选择合适的插件来满足业务需求在微服务架构日益盛行的今天，API网关成为了连接客户端与后端服务的关键组件。

基于前文：[https://active.blog.youkuaiyun.com/article/details/139213323](https://active.blog.youkuaiyun.com/article/details/139213323)- 我们基于此SDK提供的API封装一个公共方法来用于生产环境封装 nacos-sdk-go- 我们封装一个 nacos.go 文件, 这个是通用的工具库

Nacos 概述文档：https://nacos.io/docs/latest/what-is-nacos/搭建：https://nacos.io/docs/latest/quickstart/quick-start-docker/有很多种搭建方式，我们这里使用 docker 来搭建Nacos 的搭建这里，我们选择单机模式，简单些，仅仅做一些示例创建 docker-compose.yaml

现在，我们使用consul客户端的api来把GRPC服务实现注册到consul上，非Go-Micro的形式其实，consul官方提供了对应的接口调用来实现，golang中的consul/api包对其进行了封装我们使用consul/api来进行展示。

现在，我们使用consul客户端的api来实现注册到consul上，非Go-Micro的形式其实，consul官方提供了对应的接口调用来实现，golang中的consul/api包对其进行了封装我们使用consul/api来进行展示。