说说MQ在你项目中的应用(二)商品支付
本文总结了消息队列（MQ）在支付订单业务中的应用，重点分析了RabbitMQ的优势。通过异步处理、系统解耦和流量削峰等功能，RabbitMQ确保了支付流程的高效与稳定。具体场景包括用户下单、支付请求、商品生产和物流配送等环节。相比Kafka，RabbitMQ在低吞吐量、高实时性需求下表现更优，提供了更低延迟和更高的可靠性。
MQ四兄弟：如何保证消息可靠性
本文介绍了RabbitMQ、RocketMQ、Kafka和Pulsar四种消息中间件的可靠性机制。这些中间件通过以下几种方式确保消息的可靠传输：1. 消息持久化，确保消息在重启后不会丢失；2. 确认机制，保证消息从生产者到消费者都被成功处理；3. 重试机制，处理失败后的重试；4. 死信队列，处理无法消费的消息。每种中间件的具体实现略有不同，但核心思想相似，都是从生产者、中间件本身和消费者三个角度来保障消息的可靠性。
MQ四兄弟：如何实现延时消息
本文介绍了几种常见的消息队列系统（RabbitMQ、RocketMQ、Kafka和Pulsar）实现延时消息的方式。RabbitMQ通过死信队列或延时插件实现；RocketMQ内置延时消息支持，可通过设置`delayTimeLevel`属性实现；Kafka不直接支持延时消息，但可以通过时间戳、延时Topic、Kafka Streams等方法间接实现；Pulsar自带延时消息功能，提供`deliverAfter`和`deliverAt`两种方式。每种方案各有优劣，适用于不同的应用场景。
分布式系统架构4：容错设计模式
这是小卷对分布式系统架构学习的第4篇文章，重点介绍了三种常见的容错设计模式：断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延，舱壁隔离模式通过资源隔离避免全局影响，重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景，并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高，但小卷坚持每日更新以促进个人成长。
AspNetCore全局异常处理
在ASP.NET Core开发中，全局异常处理至关重要，它能集中处理未捕获的异常，确保应用稳定与良好的用户体验。通过统一错误响应、避免敏感信息泄露、提高用户体验和日志记录等功能，全局异常处理增强了应用的健壮性。异常中间件和异常过滤器是实现这一目标的两种主要手段，前者适用于全局异常捕捉，后者则更灵活地针对特定控制器或动作方法进行异常处理。
Net使用EasyNetQ简化与RabbitMQ的交互
EasyNetQ是专为.NET环境设计的RabbitMQ客户端API，简化了与RabbitMQ的交互过程。通过NuGet安装EasyNetQ，可轻松实现消息的发布与订阅，支持多种消息模式及高级特性。文中提供了详细的安装步骤、代码示例及基础知识介绍，帮助开发者快速上手。关注公众号“Net分享”获取更多技术文章。
大厂都在用的分布式事务方案，Seata+RocketMQ带你打破10万QPS瓶颈
分布式事务涉及跨多个数据库或服务的操作，确保数据一致性。本地事务通过数据库直接支持ACID特性，而分布式事务则需解决跨服务协调难、高并发压力及性能与一致性权衡等问题。常见的解决方案包括两阶段提交（2PC）、Seata提供的AT和TCC模式、以及基于消息队列的最终一致性方案。这些方法各有优劣，适用于不同业务场景，选择合适的方案需综合考虑业务需求、系统规模和技术团队能力。
阿里面试：聊聊 CAP 定理？哪些中间件是AP？为什么？
本文深入探讨了分布式系统中的“不可能三角”——CAP定理，即一致性（C）、可用性（A）和分区容错性（P）三者无法兼得。通过实例分析了不同场景下如何权衡CAP，并介绍了几种典型分布式中间件的CAP策略，强调了理解CAP定理对于架构设计的重要性。