后台经常会有小伙伴咨询RedLock相关问题，笔者在此再来一篇文章剖析一下RedLock，希望此文能解决你对它所有的疑惑和误解。 为什么需要RedLock这一点很好理解，因为普通的分布式锁算法在加锁时
前面我们学习了微服务的全景架构，了解到相对于传统单体架构，微服务的优势，以及系统服务化的发展趋势。
对于新启动的项目，我们在权衡之后可以大方的使用微服务架构。但其实大部分情况下，我们还要去维护一些以前研发的单体系统，这些系统可能因为访问流量的膨胀、功能的扩张而显得非常臃肿不堪，急需要向微服务架构
微服务架构中的 每个节点高度服务化，都是具有业务逻辑的， 符合高内聚、低耦合原则以及单一职责原则的单元，包括数据库和数据模型；
不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
在高并发的场景下，异步是一个极其重要的优化方向。前段时间，生产环境发生一次事故，笔者认为事故的场景非常具备典型性 。写这篇文章，笔者想和大家深入探讨该场景的架构优化方案。希望大家读完之后，可以对异步有更深刻的理解。1 业务场景老师登录教研平台，会看到课程列表，点击课程后，课程会以视频的形式展
1 介绍在分布式系统中，由于涉及到多个不同业务module的交互，以及高并发的场景。我们需要系统能够生成一个跨业务module的全网唯一序列号，来保证我们业务操作的独立性和唯一性。 在常见的业务场景中，比如全局订单Id，唯一标识的支付编号等，都需要这个来保证。那生成ID都有哪些解决
★微服务系列微服务1：微服务及其演进史微服务2：微服务全景架构 微服务3：微服务拆分策略微服务4：服务注册与发现微服务5：服务注册与发现（实践篇）1 服务注册中心前面我们对业内几种比较常见的注册中心做了介绍：Eureka、Zookeeper、Consul、Etcd。并且在
★ 微服务系列微服务1：微服务及其演进史微服务2：微服务全景架构 微服务3：微服务拆分策略微服务4：服务注册与发现1 微服务的注册与发现我们前面在全景架构中对服务注册与发现做了大致的说明，本章我们着重详细说明微服务下注册与发现的这个能力。微服务注册与发现类似于生活中的"电话
1 什么是高性能Web架构在互联网业务中，我们经常会面临流量巨大的复杂的分布式场景。这就要求我们在设计系统的时候保证系统具有承载高并发（High Concurrency）的能力，同时能够保证系统的高可用性（High Availability）。所以，具备高性能Web架构通常是指，通过稳健的系统
前面的文章我们介绍了分布式系统和它的CAP原理：一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。参考这篇《分布式事务》
我们知道，一个分布式系统无法同时满足三个特性，所以在设计系统之初，就有一个特性要被妥协和牺牲，因为分区
★微服务系列微服务1：微服务及其演进史微服务2：微服务全景架构 微服务3：微服务拆分策略微服务4：服务注册与发现微服务5：服务注册与发现（实践篇）微服务6：通信之网关微服务7：通信之RPC微服务8：通信之RPC实践篇（附源码）微服务9：服务治理来保证高可用1 微服务带来的挑战在第2篇《微服务
★微服务系列微服务1：微服务及其演进史微服务2：微服务全景架构 微服务3：微服务拆分策略微服务4：服务注册与发现微服务5：服务注册与发现（实践篇）微服务6：通信之网关微服务7：通信之RPC1 什么是RPC通信RPC：Remote Procedure Call Prot
★微服务系列微服务1：微服务及其演进史微服务2：微服务全景架构 微服务3：微服务拆分策略微服务4：服务注册与发现微服务5：服务注册与发现（实践篇）微服务6：通信之网关微服务7：通信之RPC微服务8：通信之RPC实践篇（附源码）1 说明上一节我们我们详细学习了RPC的概念和原理，以及它能够提供
导读：天天评估系统可用性，每次说5个9 、6个9，那么，可用性到底该怎么评估，几个9又是怎么算出来的呢？而我们又可以做些什么，来保障系统的高可用呢?Part One 可用性概念一览永不停机总归是不现实的。那么，在可操作性的范围内，怎样把影响降到最小，而影响又该怎么衡量呢？概念一：MTBF
联系我们
