m0_61253599的博客

原创 Golang基于DTM的分布式事务TCC实战

子事务屏障技术依赖本地数据库中创建子事务屏障相关的表（barrier），在源代码的示例中默认的数据库和表分别为（我们创建上面的库表，如果需要自定义库表名称。表：barrier（子事务屏障依赖表）表：user_account。库：dtm_barrier。基于docker部署。

原创 Golang基于DTM的分布式事务SAGA实战

SAGA是“长时间事务”（Long Lived Transaction）运作效率的方法，大致思路是把一个大事务分解为可以交错运行的一系列子事务的集合。原本提出 SAGA 的目的，是为了避免大事务长时间锁定数据库的资源，后来才逐渐发展成将一个分布式环境中的大事务，分解为一系列本地事务的设计模式。

原创 Gin框架接入pyroscope完美替代pprof实现检测内存泄露

并且设置上context超时控制，做好超时熔断措施，做好监控警告，下游基础设施如果达到瓶颈，我们可对下游基础进行主从 水平扩容等。我们在使用golang 高并行处理下游任务的时候，一定要对下游基础设施要有敬畏之心，调用时限制。之前我们生产项目中出现过一次严重的内存泄露，例子如下图所示，该接口qps非常高。这个时候可以点击pprof groutine很好定位哪一块出现了内存泄露。数量已经爆表了，我的mac风扇开始转了。我们可以看到各种指标。pyroscope监控。我们点击Single。

原创 分布式事务

GO语言分布式事务管理服务,支持TCC、SAGA、XA、二阶段消息（2PC）。勿用担心悬挂、空补偿、幂等等异常问题，首创子事务屏障技术代为处理。:阿里开源分布式事务框架，Seata-go暂时只支持TCC,X协议。cap理论与base理论是分布式缓存，分布式事务的基石。golang分布式事务框架。

原创 rocketMQ5.0定时/延迟消息实战

在新的版本中定时消息等价于延迟消息定时消息：例如，当前系统时间为2022-06-09 17:30:00，您希望消息在下午19:20:00定时投递，则定时时间为2022-06-09 19:20:00，转换成时间戳格式为1654773600000。延时消息：例如，当前系统时间为2022-06-09 17:30:00，您希望延时1个小时后投递消息，则您需要根据当前时间和延时时长换算成定时时刻，即消息投递时间为2022-06-09 18:30:00，转换为时间戳格式为1654770600000。

原创 rocketMQ5.0事务消息实战

docker ps查看rocketMQ 容器名称。

原创 高并发场景下慎用replace into来进行数据库操作

REPLACE INTO 操作虽然简单易用，但在使用时需要注意其带来的各种影响，包括锁粒度、性能开销、数据一致性、事务处理和并发控制等方面。在高并发和大数据量环境下，建议评估其性能影响，并根据实际需求选择合适的替代方案，如使用 INSERT ... ON DUPLICATE KEY UPDATE 来避免不必要的删除操作。

转载 （转）Redis最佳实践：7个维度+43条使用规范，带你彻底玩转Redis

腾讯redis业务专家已授权：出处。

原创 分库分表学习笔记（二）

在大众点评分库分表实践中，C端用户个人UserID后四位进行订单表分库分表，按照一致性hash ，对UserID进行mod32分到32个库里，分好库之后再按照将UserID后四位除以32 ，再Mod 32进行分表。，数据库是按照页为单位，每次加载16kb到内存，加载的数据越多之前的数据查询的缓存按照LRU驱逐出去，导致整个库表查询耗费cpu,内存以及磁盘IO性能达到了极大的影响。：数据库引擎可能需要更多的内存来处理大数据量的操作，如果内存不足，系统可能会频繁使用磁盘作为虚拟内存，进一步降低性能。

原创 分库分表学习笔记（一）

用户量开始上升，通过索引优化，根据用户数据量建立索引区分度更高的索引，联合索引，覆盖索引等操作，减少回表操作，减少磁盘IO,可以降低mysql的cpu消耗，以及减少mysql缓冲数据的驱逐,LRU策略。数据库的瓶颈已经因QPS太高造成的CPU瓶颈，之前的性能跟不上了，阿里云RDS可以在中间件级别实现主从分离，从库分担读的压力，多加几个从库。分担读的压力，从而降低QPS，CPU压力。，检查数据库的配置，数据库配置4核心8g比较低,升级更高的配置。：用户量少的时候，单库单表可以扛住整个系统的需求。

原创 go中 panic&recover&defer机制

在defer机制里 站在引用老哥的肩膀上学了一下defer的底层机制，recover常用的场景defer，recover,panic，goroutine之间有什么联系呢recover的作用域，recover在什么时候才会起作用。

原创 go设计模式———适配器模式

/ ChinaPlug 是中国插头的接口// ChinaSocket 是中国插座的接口// EuroSocket 是欧洲插座的接口。

原创 go设计模式———抽象工厂模式

抽象工厂接口定义了创建家具的方法。具体工厂和实现了这个接口，负责创建具体风格的家具。产品接口Table和Chair定义了家具的通用行为。具体产品和实现了具体风格的家具。通过这种方式，客户端代码只与抽象工厂接口和产品接口交互，不需要关心具体的产品实现细节。只要替换工厂类，就可以很方便地切换不同风格的家具，而不需要修改客户端代码。

原创 go的defer机制

•。

原创 go设计模式———工厂模式

工厂模式是一种创建型设计模式，主要用于创建对象而不直接指定具体的类。它将对象的创建过程封装在一个工厂类中，这样可以在不修改客户端代码的情况下，改变创建的对象类型或实现。简单来说，工厂模式就像是一个“工厂”，根据需求生产不同的“产品”。• 根据传入的 modeType 参数（“airplane”、“train” 或 “bus”），工厂方法返回相应的具体出行工具实例，并传入价格和到达时间。：实现出行工具接口，比如飞机、高铁和大巴。：根据客户的需求创建具体的出行工具实例。用于创建具体的出行工具实例。

原创 go设计模式——单例模式

因此，尽管单例模式可以简化某些设计，但在使用时需要谨慎，以避免对代码的灵活性和可维护性产生不良影响。• 日志记录器通常需要在应用程序的不同部分被调用，但希望所有日志都通过同一个实例处理，以便统一管理日志的输出目标、格式等。你想要在程序中创建一个“月亮”对象，并确保在整个程序运行期间，只有一个这样的“月亮”对象存在。为了实现这一点，你使用了。通过单例模式，可以确保连接池实例在整个应用程序中是唯一的，并且被多个客户端共享。• 在并发编程中，线程池用于管理线程的复用，以避免频繁创建和销毁线程带来的开销。

原创 分布式缓存———数据一致性问题

导致对同一个key缓存的操作，可能缓存更新后还是旧版本数据，从而对我们业务造成影响。在看分布式数据一致性问题前，可以先看看分布式理论。影响分布式缓存数据一致性大致有以下几类问题。分布式系统的三座大山的问题。

原创 docker-compose 安装canal

【代码】docker-compose 安装canal。

原创 分布式事务TCC

TCC是位于用户代码层面，而不是在基础设施层面，这为它的实现带来了较高的灵活性，可以根据需要设计资源锁定的粒度。TCC 在业务执行时只操作预留资源，几乎不会涉及锁和资源的争用，具有很高的性能潜力TCC分布式事务解决方案是在业务层面实现的原子性一致解决方案，原子性所有的事务要么一起成功要么一起失败。是最终一致方案比较有代表的，通常用来处理对于用户感知度比较强的分布式场景，比如转账，冲话费。不能转账已到账然后cancel。NPC。N：Network Delay，网络延迟。

原创 Gin框架接入Prometheus,grafana辅助pprof检测内存泄露

我们在使用golang 高并行处理下游任务的时候，一定要对下游基础设施要有敬畏之心，调用时最好设置上context超时控制，做好超时熔断措施，做好监控警告，下游基础设施如果达到瓶颈，我们可对下游基础进行主从 水平扩容等。我们想给Prometheus新增监听任务新增ginapp项目只需要在原来的配置文件下面新增ginapp相关metric。之前我们生产项目中出现过一次严重的内存泄露，例子如下图所示，该接口qps非常高。配置之后我们看以在dashboard看到。数量已经爆表了，我的mac风扇开始转了。

原创 grom接入Prometheus,grafana

docker-compose.yml，与prometheus.yml 配置文件。在granfa配置好相关datasoure可以看到相关数据库连接串指标。// SetMaxOpenConns 设置打开数据库连接的最大数量。我们用go的高并发 限制运行协程数量最大100.在prometheus可以看到相关指标信息。在同级目录下分别创建。

原创 RocketMQ5.0消费者负载均衡实战-顺序消息负载均衡

在看本篇文章之前可以看一下非顺序消息消息负载均衡相关。

原创 RocketMQ5.0消费者负载均衡实战

广播消费可以理解为一个topic被多个不同下游服务订阅消费：基于consumer group来区别不同的服务（消费者）。共享消费可以理解为consumer GroupA为k8s service的概念，消费consumer为pod，将外部的请求通过lb，随机分配给不同的pod。看起来几乎平均分配。生产者产生1000条消息,启动两个消费者服务订阅相同的topic，consumerGroup分别为group1，group2。消息粒度负载均衡策略保证同一个队列的消息可以被多个消费者共同处理，但是该策略使用的消息。

原创 golang并发控制

Channel: 使用channel控制子协程，有缓冲的channel控制并发数量，无缓冲channel同步调用。WaitGroup : 使用信号量机制控制子协程。Context: 使用上下文控制子协程。

原创 RocketMQ5.0 队列

服务端5.x版本：队列名称为一个集群分配的全局唯一的字符串组成，和物理节点解耦。

原创 RocketMQ5.0死信队列

消费逻辑的最终兜底机制，。您可以通过消费死信队列的消息进行业务恢复。

原创 RocketMQ5.0课笔记-架构设计

rocketmq云原生架构。

原创 RocketMQ5.0课笔记-消息场景

rocketmq高可用的方案设计。rocketMQ的负载均衡。

原创 RocketMQ5.0消费挤压处理方式

RocketMQ 无法避免消息重复（Exactly-Once），所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgId，也可以是消息内容中的唯一标识字段，例如订单Id等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）

原创 RocketMQ5.0 Consumer Group

消费者分组（Consumer Group）是指一组消费同一类消息的消费者实例。每个消费者分组有一个唯一的名称，用于标识该分组。消费者分组的设计使得消息能够被多个消费者实例并行消费，同时确保每条消息只被一个消费者实例处理一次。：在集群消费模式下，同一个消费者分组中的多个消费者实例共同消费消息，每条消息只会被其中一个消费者实例消费。这种模式适用于负载均衡的场景。：在广播消费模式下，同一个消费者分组中的每个消费者实例都会消费所有的消息。这种模式适用于每个消费者都需要处理所有消息的场景。

原创 RocketMQ5.0消费者与消费者的负载均衡

RocketMQ 消费者分为以下几类PushConsumer 、 SimpleConsumer 以及 PullConsumer

原创 k8s架构图

原创 rocketMQ 5.0消费重试与流控机制

原创 RocketMQ5.0 生产者

生产者消息类型：

原创 docker 部署rocketMQ

ps:docker在同一个network方式下rocketmq下面可以通过容器名称直接访问。docker 默认会创建 bridge链接方式的rocketmq局域网。查看docker创建那些network。起用dashborad。指定容器name访问。

原创 RocketMQ中的参数约束和建议

（取值范围：无限制）

原创 rocketmq普通消息-消息类型

引用Send消息发送方发出一条消息后，会在收到服务端之后才发下一条消息的通讯方式，被广泛应用于各种场景，如重要的通知消息、短消息通知等。用途1.• 适用于需要确保消息可靠到达的场景，如系统报警、重要通知、事件提醒等。同步发送确保消息发送成功后，系统能得到立即确认，保证消息不会丢失。2.• 订单系统中的订单创建、订单支付等关键操作需要确保数据一致性和可靠性。通过同步发送，系统可以在发送消息后立即确认消息已成功写入消息队列，从而保证订单数据的一致性和完整性。3.

原创 CAP理论 与 BASE理论

BASE理论的核心思想是，通过放宽对一致性的要求，可以获得更高的可用性和分区容忍性。CAP理论的核心在于，在分布式系统中，只能在一致性、可用性和分区容忍性这三个属性中最多同时满足两个。：在可用性和分区容忍性之间做出权衡，但不保证数据一致性。：强调通过牺牲强一致性来获得更高的可用性和分区容忍性，适用于需要高可用性的场景，并保证最终的一致性。：强调在一致性、可用性和分区容忍性之间的权衡，分布式系统只能在这三者中最多同时满足两个。：系统的状态可以是软的，不一定是固定的，允许数据副本之间存在一定程度的不一致。

原创 分布式事务方案 2pc/3pcTCC SAGA 消息最终一致性

b站讲的通俗易懂的 分布式事务方案。

原创 mqtt-EMQX 代理

如果你的应用需求超出了资源受限设备的能力范围，EMQX 提供的高性能和扩展性可能非常有用。• 由于其高级功能和集群支持，EMQX 的部署和管理可能比 Mosquitto 更加复杂，这在资源受限环境中可能增加额外的运维负担。• EMQX 可能会消耗更多的内存和 CPU 资源，尤其是在高负载和复杂配置的情况下。虽然 EMQX 提供了许多先进的功能，但它的资源需求通常高于轻量级的 MQTT 代理，如 Mosquitto。• EMQX 支持高可用部署，包括主备模式和分布式集群，以确保服务的可靠性和稳定性。