在分布式系统的高可用设计中，负载均衡非常关键，我们知道，分布式系统的特性之一就是支持快速扩展，那么集群扩展之后，服务请求如何从服务器列表中选择合适的一台呢？这就需要依赖负载均衡策略。 负载均衡在处理高并发，缓解网络压力，以及支持扩容等方面非常关键，在不同的应用场景下，可以选择不同的负载均衡，下面一起来看一下负载均衡相关的知识。 一、负载均衡的应用 负载均衡是指如何将网络请求派发到集群中的一个或多个
上一篇文章我们分析了限流的常用策略，下面来看一下，高可用的另外两大撒手锏：降级和熔断，关于这两种技术手段如何实施，又有哪些区别呢？ 一、高可用之降级 我们在前面文章中提过服务降级是电商大促等高并发场景的常见稳定性手段，那大家有没有想过，为什么在大促时要开启降级，平时不去应用呢？ 在大促场景下，请求量剧增，可我们的系统资源是有限的，服务器资源是企业的固定成本，这个成本不可能无限扩张，所以说，降级是解
在分布式高可用设计中，限流应该是应用最广泛的技术手段之一，今天一起来讨论一下，为什么需要限流，以及常见的限流算法都有哪些。 一、常见限流算法 限流是服务降级的一种手段，顾名思义，通过限制系统的流量，从而实现保护系统的目的。 合理的限流配置，需要了解系统的吞吐量，所以，限流一般需要结合容量规划和压测来进行。当外部请求接近或者达到系统的最大阈值时，触发限流，采取其他的手段进行降级，保护系统不被压垮。常
今天一起来讨论一下，在面对电商大促、秒杀抢购等高并发的业务场景时，都有哪些高可用的保障手段。 一、从双十一限制退款说起 每年的电商大促活动，规模最大的就是双十一促销，双十一已经从光棍节，演变成了国内最大的电商促销活动。每年的双十一，我都会买一些打折力度比较大的商品，特别是数码产品，比如相机、键盘等，相信你肯定也和我一样，有很多“买买买”的经历。 类似双十一、618 这种促销活动，都会设置整点抢购。
在业务开发中，缓存服务和其他数据服务一样，需要满足高可用性，而高可用最常用的手段就是集群扩展。 一、缓存的集群高可用 目前 Redis 流行的集群方案有 官方 Cluster 方案、twemproxy 代理方案、哨兵模式、Codis 等方案，关于这几种方案的具体应用，我们在下一篇文章详细展开讲解。 缓存服务从单点扩展到集群以后，势必会产生缓存数据的分发问题，假设我们的缓存服务器有 3 台，每台缓存
缓存使用的是内存资源，而内存资源是非常宝贵的，要用有限的服务器资源支撑更多的业务，就必须让那些访问频率不高的缓存删除掉，为新的缓存腾出内存空间。这篇文章，我们一起来看一下，缓存失效有哪些策略。 一、页面置换算法 我们从一开始就提到，缓存技术在计算机系统设计中有着非常广泛的应用，对应到操作系统中，就是缓存页面的调度算法。 在操作系统中，文件的读取会先分配一定的页面空间，也就是我们说的 Page，使用
上篇文章分享了缓存使用中的几个问题场景：缓存穿透、缓存击穿和缓存雪崩，这几个问题聚焦的是缓存本身的稳定性，包括缓存集群和缓存的数据，除了这些，缓存应用中，缓存和上下游系统的数据同步也很重要。这一课时，我们来学习缓存应用中的另一个高频问题：应用缓存以后，缓存和数据库何时同步。 一、数据不一致问题 我们知道，除了少部分配置信息类缓存，比如业务中的黑白名单信息、页面展示配置等，大部分缓存应用一般是作为前
设计缓存系统不得不考虑的问题是缓存穿透、缓存击穿与失效时的雪崩效应，同时，关于这几种问题场景的认识及解决方案，也是面试中的高频考点。今天的内容，可以说是缓存应用的三板斧，下面我们一起来分析一下缓存应用中的这几个热门问题。 一、缓存穿透 先来看一下缓存穿透，顾名思义，是指业务请求穿过了缓存层，落到持久化存储上。在大多数场景下，我们应用缓存是为了承载前端业务请求，缓存被击穿以后，如果请求量比较大，则会
缓存是分布式系统开发中的常见技术，在分布式系统中的缓存，不止 Redis、Memcached 等后端存储；在前端页面、浏览器、网络 CDN 中也都有缓存的身影。 如果是做业务开发的话，提起缓存首先想到的应该是应用 Redis，或者 Memcached 等服务端缓存，其实这些在缓存分类中只是一小部分。然而在整个业务流程中，从前端 Web 请求，到网络传输，再到服务端和数据库服务，各个阶段都有缓存的应
关于消息队列的应用场景有很多，不同消息队列由于在实现上有着细微的差别，所以就有各自适合的应用场景。 如果你的工作以业务开发为主，建议了解一下消息队列背后的设计思想，以及其基本的特性，这样才能在业务开发中应用消息队列时，对消息队列进行合理的选型。这篇文章我们一起来对 RocketMQ 做一个拆解。 一、RocketMQ 应用 RocketMQ 在阿里巴巴被大规模应用，其前身是淘宝的 MetaQ，后来
一、Kafka 的高性能 不知道大家有没有了解过自己电脑的配置？ 我们一般会认为高性能是和高配置联系在一起的，比如大内存比小内存快，8 核的机器比 4 核的机器快。我身边也有一些朋友是攒机爱好者，对各种硬件配置如数家珍。 对于服务器来说，家用电脑的性能与配置的关系也同样适用——价格更昂贵的服务器会有更好的性能——这并不是一件需要大张旗鼓去讲述的事情。但 Kafka 所实现的高性能不需要太高配置的机
管理学上有一个木桶理论，一只水桶能装多少水取决于它最短的那块木板，这个理论推广到分布式系统的可用性上，就是系统整体的可用性取决于系统中最容易出现故障，或者性能最低的组件。系统中的各个组件都要进行高可用设计，防止单点故障，消息队列也不例外，这一篇文章一起来看一下消息中间件的高可用设计。 一、消息队列高可用手段 一般来说，分布式系统的高可用依赖副本技术，副本的引入，使得分布式系统可以更好地进行扩展，当
应用的幂等是在分布式系统设计时必须要考虑的一个方面，如果对幂等没有额外的考虑，那么在消息失败重新投递，或者远程服务重试时，可能会出现许多诡异的问题。这篇文章一起来看一下，在消息队列应用中，如何处理因为重复投递等原因导致的幂等问题。 一、对业务幂等的理解 首先明确一下，幂等并不是问题，而是业务的一个特性。幂等问题体现在对于不满足幂等性的业务，在消息重复消费，或者远程服务调用失败重试时，出现的数据不一
消息传输和消费的有序性，是消息队列应用中一个非常重要的问题，在分布式系统中，很多业务场景都需要考虑消息投递的时序。例如，电商中的订单状态流转、数据库的 binlog 分发，都会对业务的有序性有要求。今天我们一起来看下，消息队列顺序消费的相关内容。 一、消息顺序消费有哪些困难 我们知道，消息队列中的队列是一个有序的数据结构，消息传递是顺序的，但在实际开发中，特别是在分布式场景下，消息的有序性是很难保
为了规范消息队列中生产者和消费者的行为，消息中间件的构建中会实现不同的消费模型。这篇文章讨论的话题来自 RocketMQ 中具体的两种消费模式，是消息队列中两种典型消费模型的实现。接下来我们就一起来看一下消息队列都有哪些消费模型，以及对应的具体实现。 一、消息队列的消费模型 先来看一下消息队列的两种基础模型，也就是点对点和发布订阅方式。 这两种模型来源于消息队列的 JMS 实现标准，消息队列有不同
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
