开源基础软件社区

1介绍我们实际系统中有很多操作，不管你执行多少次，都应该产生一样的效果或返回一样的结果。例如：前端页面重复提交选中的数据，服务端只产生对应这个数据的一个反应结果，只保存一次数据。我们发起一笔付款请求，也只能扣用户账户一次钱，即使遇到网络重发或系统bug重发，也应该只扣一次金额。消息通知，也应该只能收到一次，如果收到多次的扣款通知短信，会让用户误解的。创建商品订单，一次业务请求只能创建一个，创建多个...

1介绍在之前的一篇文章《一次缓存雪崩的灾难复盘》中，我们比较清晰的描述了缓存雪崩、穿透、击穿的各自特征和解决方案，想详细了解的可以移步。最近在配合HR筛选候选人，作为大厂的业务方向负责人，招人主要也是我们自己团队在用，而缓存是必不可少的面试选项之一。下面我们就来聊一聊在特定业务场景下缓存击穿和雪崩的应对场景！2问题背景一个核心的应用或者服务（比如微信、钉钉、百度APP），高峰QPS是百万甚至是千万★分析...

1介绍在之前的章节中，我们介绍了消息的发送和消息通信的原理。但是这边有一个比较核心的关键点，那就是如果已经把消息传递给Broker。在Broker在被消费之前，如何保证消息的稳定性，避免消息丢失和数据。这时候就需要数据持久化数据来进行保障了。根据之前我们MQ系列2：消息中间件的技术选型章节做的分析，RabbitMQ支持1W+级别的吞吐，Kafka和Rocket支持10W+级别的吞吐，想要实现这么大的吞吐，必须具备一个很强悍的存储功能。...

1前言通过前面的一些文章我们知道，Redis的各项能力是基于内存实现的，相对其他的持久化存储（如MySQL、File等，数据持久化在磁盘上），性能会高很多，这也是高速缓存的一个优势。但是问题来了，每一台机器内存终归是有限的，即使是集群模式，总的内存空间也是有限的，不能无限制的消耗。而在Redis的使用过程中，很有可能出现使用消耗超过内存实际大小的情况。比如以下几种情况：未设置过期时间，Redis的Key将一直存在，直至我...

1前言在《微服务系列》中，我们讲过很多限流，熔断相关的知识。老生长谈的一个话题，服务的能力终归是有限的，无论是内存、CPU、线程数都是，如果遇到突如其来的峰量请求，我们怎么友好的使用限流来进行落地，避免整个服务集群的雪崩。峰量请求主要有两种场景：1.1突发高峰造成的服务雪崩如果你的服务突然遇到持续性的、高频率的、不符合预期的突发流量。你需要检查一下服务是否有被错误调用、恶意攻击，或者下游程序逻辑问题。...

1前言我们来回顾下在这个系列的第一篇深刻理解高性能Redis的本质中介绍过Redis的几种基本数据结构，它服务于各种不同的业务场景而设计的，比如：动态字符串(REDISSTRING)：整数(REDISENCODINGINT)、字符串(REDISENCODINGRAW)双端列表(REDISENCODINGLINKEDLIST)压缩列表(REDISENCODINGZIPLIST)跳跃表(REDISENCODINGSKIPLIST)哈希表(REDISHASH)整数集合(REDISENCODINGINTSET)除了这些常见数据类型，还有一些不常用的数据类型，如B...

1前言我们在第一篇深刻理解高性能Redis的本质的时候就介绍过Redis的几种基本数据结构，它是基于不同业务场景而设计的：动态字符串(REDISSTRING)：整数(REDISENCODINGINT)、字符串(REDISENCODINGRAW)双端列表(REDISENCODINGLINKEDLIST)压缩列表(REDISENCODINGZIPLIST)跳跃表(REDISENCODINGSKIPLIST)哈希表(REDISHASH)整数集合(REDISENCODINGINTSET)除了这些常见数据类型，还有一些不常用的数据类型，如BitMap、Geo、HyperLogLog...

1介绍消息中间件是指在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列（MessageQueueMQ），互联网场景中经常使用消息中间件进行消息路由、订阅发布、异步处理等操作，来缓解系统的压力。引入消息队列主要是为了解决如下问题的：1、解耦：如订单系统，可以通过消息队列把削减库存的工作交给库存系统去处理，而不用等实时响应。2、执行有序性：先进先出原理，按照进入消息队列的顺序处理业务事件。3、...

1微服务的基本流量策略微服务提供了一些技术来实现对微服务的流量的管理，其中最典型的就是对流量进行拆分和转发。具体体现在金丝雀发布（灰度发布）、ABTesting以及流量染色等策略方案上，下面会进行详细的介绍。2价值和必要性★价值驱动：支持蓝绿发布、金丝雀发布，无需停服也能保证发布的无缝衔接，提高了服务整体的SLA。全链路的ABTesting，保证不同特征类型的用户可以在独立的链路通道上测试、使用、实验、生产。大幅降低...

1介绍前面的章节，我们学习了微服务中对熔断降级的原理，参考这篇《服务治理：熔断、降级、限流​》。了解了固定窗口算法、滑动窗口算法、漏桶原理和令牌桶原理，本文对Hystrix做进一步的分析。Hystrix是Netflix开源的一款具备熔断、限流、降级能力的容错系统，设计目的是将应用中的系统访问、多链路服务调用、第三方依赖服务的调用，通过流量资源控制的方式隔离开。避免了在分布式系中的某个服务故障沿着调用链向上传递，出现...

1前言我们在第一篇深刻理解高性能Redis的本质的时候就介绍过Redis的几种基本数据结构，它是基于不同业务场景而设计的：动态字符串(REDISSTRING)：整数(REDISENCODINGINT)、字符串(REDISENCODINGRAW)双端列表(REDISENCODINGLINKEDLIST)压缩列表(REDISENCODINGZIPLIST)跳跃表(REDISENCODINGSKIPLIST)哈希表(REDISHASH)整数集合(REDISENCODINGINTSET)除了这常见数据类型，还有一些不常用的数据类型，如BitMap、Geo、HyperLogLog等...

1介绍前面的章节我学习了NameServer的原理，消息的生产发送，以及消息的消费的全过程。我们来回顾一下：RocketMQ消息队列架构主要包括NameServe、Broker(MasterSlave)、Producer、Consumer4个核心部件，基本执行流程如下：NameServer优先启动。NameServer是整个RocketMQ的“中央大脑”，作为RocketMQ的服务注册中心，所以RocketMQ需要先启动NameServer再启动Rocket中的Broker。Broker启动后，需要将自己注册至NameServer中，并...

1为什么断限流分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。1.2雪崩效应常见场景硬件故障：如服务器宕机，机房断电，光纤甚至专线被破坏等。流量激增：如异常...

背景前面一篇我们说到，2020年5月份，Redis官方推出了令人瞩目的Redis6.0，提出很多新特性，包括了客户端缓存(Clientsidecaching)、ACL、ThreadedIO和RedisClusterProxy等诸多新特性。如下：我们也专门对Redis6.0的ThreadedIO（多线程网络IO模式）做了很详细的说明，有兴趣的翻到前面一篇。这一篇咱们就来聊下这个Clientsidecaching（客户端缓存），看看Redis为什么需要客户端缓存、是基于什么原理实现的，以及具体应该怎么使用...

在之前的文章中，我们学习了RocketMQ的原理；RocketMQ中命名服务ServiceName的运行流程；以及消息生产、发送的原理和模式。这一篇，就让我们从消息消费的角度去进一步的学习。1消息消费消息的消费主要是由如下几个核心能力组成的：消费方式：Push（推）或者Pull（拉）消费模式：广播模式和集群模式消息消费反馈流量控制（包括消费并发线程数设置）消息的过滤（Tag,Key）,过滤标签TagATagBTagC1.1消费方式PushorPullRocketMQ消息...

背景我们在第一篇《Redis系列1：深刻理解高性能Redis的本质》中就已经提到了，Redis的网络IO以及键值对指令读写是由单个线程来执行的，避免了不必要的contextswitch和资源竞争，对于性能提升有很大的帮助。而到了2020年的5月份，Redis官方推出了令人瞩目的Redis6.0，提出很多新特性，包含多线程网络IO的概念，如下：新特性内核优化应用优化其他ACL细粒度权限管控(包括ACLLOG)过期Key回收优化，增加配置参数新版本ModuleAPI全面...

在之前的篇章中，我们学习了RocketMQ的原理，以及RocketMQ中命名服务ServiceName的运行流程，本篇从消息的生产、消费来理解一条消息的生命周期。1消息生产在RocketMQ中，消息生产指的是消息生产者往消息队列中写入数据的过程。因为业务场景的复杂性，RocketMQ架构设计了多种不同的写入策略。下面先讨论几种常见的场景：同步发送：整个过程业务是阻塞等待的，消息发送之后等待Broker响应，得到响应结果之后再传递给业务线程。异...

1关于NameServer上一节的MQ系列3：RocketMQ架构分析，我们大致介绍了RocketMQ的基本组件构成，包括NameServer、Broker、Producer以及Consumer四部分。NameServer，指的是服务可以根据给定的名字来进行资源或对象的地址定位，并获取有关的属性信息。在Rocket中也一样，NameServer是RocketMQ的服务注册中心（类似于Kafka集群后面的Zookeeper集群一样，对集群元数据进行管理），根据元数据（ip、port和router信息）来唯一定位服务...

1背景我们前面两篇对主流消息队列的基本构成和技术选型做了详细的分析。从本篇开始，我们会专注当下主流MQ之一的RocketMQ。从他的如下的几个方面去讨论：基础能力（如组织构成、消息发送、消息存储（持久化）、消息通信、消息消费）功能性方面（如消息堆积、消息回溯、消息追踪、消息过滤），高可用性方面（如消息顺序性保障、消息幂等性保障、消息安全性保障、消息事务性保障），性能方面（如时效性，单机吞吐率）参考​​MQ系...

1概述我们所说的Aop（即面向切面编程），即面向接口，也面向方法，在基于IOC的基础上实现。Aop最大的特点是对指定的方法进行拦截并增强，这种增强的方式不需要业务代码进行调整，无需侵入到业务代码中，使业务与非业务处理逻辑分离。以Spring举例，通过事务的注解配置，Spring会自动在业务方法中开启、提交业务，并且在业务处理失败时，执行相应的回滚策略。aop的实现主要包括了两个部分：匹配符合条件的方法(Pointcut)对匹配的...