Redis从3.0版本开始支持原生的集群模式，即RedisCluster。RedisCluster，主要是针对海量数据下的高并发、高可用场景，海量数据就是说单机Redis无法完全容纳数据，需要进行数据分片。本章，我就来讲解如何搭建一个3主3从的RedisCluster。关于RedisCluster的基本原理，读者可以参考进阶篇中的《分布式框架之高性能：Redis集群模式》。一、集群部署RedisCluster至少要求有3个Master节点，同时为了保证高可用，每个Master都建议至少有一个Slave，同时Master不能跟自己的Slave部署在同一台机器上。所以，我会在ressmix-dsf
关于Redis哨兵模式的原理，我在进阶篇的《分布式框架之高性能：Redis哨兵模式》已经详细讲解过了，不熟悉的读者可以先去了解下。本章，我将带领大家部署一个3节点的哨兵集群，并介绍如何基于哨兵进行故障转移，以及一些企业级的配置方案。一、哨兵部署我们先来构建一个哨兵集群，一般哨兵集群至少需要三个独立的机器节点，这样才能保证哨兵自身的高可用。我在前几个章节已经带领大家部署了一主二从的Redis架构。本章，我们就在之前的ressmix-dsf01、ressmix-dsf02、ressmix-dsf03上分别部署一个哨兵，运行在5000端口，整个架构逻辑图如下：1.1哨兵配置我以ressmix-dsf
对于一个能够支撑超高并发的大型分布式系统来说，像Redis这类分布式缓存是必不可少。Redis在单机部署的模式下，QPS几乎不可能超过10万+，除非机器配置特别好且Redis操作不太复杂。我们知道，对于数据库来说，如果想要提升读写性能，最简单的方式就是做一主多从+读写分离。对于分布式缓存也是一样的道理，因为缓存一般都是用来支撑读请求的高并发，写请求相对较少（一般也就每秒一两千写请求），所以非常适合读写分离的架构。关于Redis的复制原理，我在进阶篇的《分布式框架之高性能：Redis主从同步》已经详细讲解过了，不熟悉的读者可以先去了解下。一、主从架构搭建在生产环境下，我们必须要将Master节点
上一章，我讲解了Redis的两种持久化方式的基本配置，那么在生产环境中，Redis的持久化到底该如何运用呢？企业级的数据备份和各种灾难下的数据恢复，又是怎么做的呢？本章，我就通过实战演练，讲一讲企业级Redis灾备方案。一、持久化配置策略Redis的持久化配置，就两种——RDB和AOF，在生产环境配置下，主要就是关注它们的一些核心参数。我们来一一看下。1.1RDBRDB的配置，用Redis默认提供的配置方案就够了，这里不再赘述。1.2AOF生产环境，一定要把AOF持久化打开，持久化策略用默认的appendfsynceverysec就可以了。二、数据备份策略我们知道，RDB非常适合做冷备，每次生
Redis作为分布式缓存，数据首先是存储在内存中的，但是为了保证数据不丢失，肯定需要将数据持久化到磁盘上。我在分布式进阶篇中的《Redis数据持久化》已经讲过了Redis的持久化原理。Redis一共提供了两种数据持久化方式：RDB、AOF。本章，我将带领大家在先前的1个CentOS节点上搭建单机Redis，然后通过实战讲解Redis的RDB和AOF持久化配置。一、Redis安装我首先在ressmix-dsf01这个节点上安装单机版本的Redis，后续随着我们讲解的深入，会配置成集群模式。进入/usr/local目录，执行以下命令：wgethttp://download.redis.io/rel
为了后续实战演练的方便，本章我将从零开始，一步一步搭建出一个4节点的CentOS集群。后续章节，我们会在这个集群上部署Redis、Nginx、MySQL、Storm等分布式框架。我的笔记本配置是4核12G，所以4台虚拟机，每台虚拟机分配1G的内存。涉及到的主要软件如下：VirtualBox虚拟机5.2CentOS-6.5-i386-minimaljdk-7u65-linux-i586VanDykeSecureCRTv7.3.5一、CentOS安装首先，安装完VirtualBox后，我们新建虚拟机，进行CentOS的安装，这里节点名称可以自定义，我这里叫做“ressmix-dsf01”，后面还要
我的分布式系列文章写到这里，相信各位童鞋已经对分布式理论和进阶中的核心知识点有了一个清晰的认识，至少应该明白所有分布式系统无外乎是围绕高性能、可扩展、高可用、一致性这四个方面来设计的。从本章开始，我将以一个完整的电子商务支付平台为案例，融合整个系列前两部分介绍过到各种分布式理论和框架，手把手带领大家进行分布式系统的架构设计与落地。实战篇部分的核心要点是缓存架构的设计，由于架构是不断演进的，所以本章我将先从一个小型的电子商务网站为切入点，介绍其架构存在的缺陷，然后逐步引出系统中的一些核心部分，一步一步讲解支撑高并发场景下的缓存技术、解决方案、架构设计。一、系统背景1.1小型电商平台这个小型的电子
Session是一种服务端的机制，使用一种类似于散列表的结构来保存客户端的会话信息。当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为sessionid），如果已包含则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；如果客户端请求不包含sessionid，则为此客户端创建一个session并生成一个相关联的sessionid，这个sessionid将被在本次响应中返回给客户端保存。传统的单体应用，一般会采用web容器提供的seesion机制。但是分布式环境下，
我在分布式框架之高性能：Redis分布式锁一章中，介绍过Redis分布式锁。事实上，生产环境中，Zookeeper分布式锁更加成熟，在工业运用中也更多。本章，我将基于比较常用的Curator开源框架，来聊一聊Curator对ZooKeeper（以下简称ZK）分布式锁的实现。Curator可以看成是ZookeeperClient，类似于Jedis、Redisson之于Redis，读者可以从这里获取到Curator这个ZK客户端的更多资料：http://curator.apache.org。一、基本原理首先大家看看下面的图，如果现在有两个客户端要一起争抢ZK上的一把分布式锁，会是个什么场景？上图中
Hystrix熔断，其实就是打开了断路器（CircuitBreaker）。Hystrix在运行过程中会向每个commandKey对应的断路器报告成功、失败、超时和拒绝的状态，断路器会统计并维护这些数据，根据这些统计信息来确定断路器的状态：打开（open）、半开（half-open）、关闭（close）。打开状态：后续的请求都会被截断，直接走fallback降级；半开状态：默认每隔5s，尝试半开，放入一部分流量进来，相当于对依赖服务进行一次健康检查，如果服务恢复了，则断路器关闭，随后完全恢复调用；关闭状态：断路器完全关闭，走正常的请求调用流程。一、工作原理我们先来看下断路器的基本工作流程，还是下
上一章，我讲解Hystrix命令执行流程时，一直提到Hystrix的fallback降级机制，我们先来回顾一下，在哪些情况下会触发降级：断路器处于打开状态，直接走降级流程；线程池/队列/semaphore满了，请求被reject；执行了请求，但是Command的run()或construct()方法抛出异常；上述三种情况，都属于异常情况，Hystrix会发送异常事件到断路器中去进行统计，如果断路器发现异常事件的占比达到了一定的比例，会直接开启断路，如下图：接下来，我们通过一个示例来看看如何使用Hystrix的降级机制。一、降级示例Fallback降级的逻辑一般写在Command内，一般有两种最
Zookeeper是Apache开源的一款分布式协调框架，它提供了一种多层级的节点命名空间，可以提供诸如数据发布/订阅、分布式协调/通知、集群管理、Master选举、配置管理、分布式锁等各种分布式协调服务。Zookeeper的核心是它底层的ZAB协议。ZAB协议是分布式CAP理论的典型实践，我已经在分布式理论篇中详细讲解过了，感兴趣的读者可以看一看，本文不再赘述。本章，我也不会介绍Zookeeper的各种语法，这些东西大家可以参考Apache官方文档。我主要简单介绍下Zookeeper的系统模型，然后重点讲一讲Zookeeper的几种典型使用场景，特别是作为注册中心时与Eureka的对比。一、
通过前面一章的学习，我们已经了解了如何利用Hystrix来实现资源隔离，本章我将详细讲解一次请求调用在Hystrix底层的整个执行流程。一、Command执行流程我们来分析下下面这张图，它表述了一次Hystrix请求调用的完整底层逻辑：1.1创建请求在Hystrix中，一个Command对象代表了对某个依赖服务的接口发起的一次请求，Command对象一共有两种：HystrixCommand：用于仅仅返回一个结果的调用HystrixObservableCommand：用于可能会返回多条结果的调用1.2请求调用执行Command就可以发起一次对依赖服务接口的调用，一共有四个方法可以选择：execu
本章，我将介绍微服务架构中的另一个非常重要的组件——API网关。网关在分布式系统中实在太重要了，可以提供动态路由、灰度发布、授权认证、性能监控、限流熔断等功能：目前开源界有很多可供选择的API网关，云原生软件基金会（CNCF）的全景图就是一个很好的参考：本章，我会先讲解一个API网关应当具备哪些核心组件，并分析如果我们要自己实现这样一个API网关，系统设计和架构的思路应当是怎样的，然后对几种常见的开源API网关框架进行介绍。最后，我会以SpringCloudZuul为例，介绍Zuul的基本使用。一、核心组件一个API网关，一般至少需要具备如下核心组件：路由：定义一些规则来匹配客户端的请求，根据
本章，我将讲解Hystrix的第一个核心功能——资源隔离。Hystrix采用了BulkheadPartition舱壁隔离技术，来对外部依赖进行资源隔离，进而避免任何外部依赖的故障导致本服务的崩溃。Hystrix进行资源隔离的基本思想是：将对某一个依赖服务的所有调用请求，全部隔离在同一份资源池内，不会去用其它的资源，一共有两种实现方案：线程池隔离和信号量隔离。不理解？没关系，我们先来看下故障场景，然后看看Hystrix的这两种解决方案。一、故障场景我们以上一章的电商系统为例，看下故障场景：商品服务接口调用故障，导致整合服务耗尽了自身的服务器资源。商品服务出现接口故障，开始发生延迟、卡顿；整合服务
在分布式理论篇中，我简单介绍过分布式系统保障接口级高可用的几种常见方式：限流、熔断、降级。目前，业界主要使用Hystrix来做这几项工作。Hystrix是Netflix开源的一个Java框架，提供了保障接口级高可用相关的各种各样的功能，帮助我们控制分布式服务之间的交互。本章，我将先简单介绍下Hystrix提供的核心功能，然后引入一个电子商务平台作为背景案例。后续章节，我对Hystrix核心功能和原理的讲解都会围绕该案例展开。一、Hystrix初览Hystrix官网对该框架能解决的核心问题已经做了概述，我这里再引用官方的几张图片来讲一讲：首先，复杂分布式系统中的各个服务之间都是相互依赖的，每个依
上一章，我通过一个简单的电商系统介绍了SpringCloud的各个组件，以及如何搭配使用构建一个简单的微服务系统。本章，我将讲解Eureka服务注册中心的一些核心原理。除了Eureka可以作为服务注册中心外，主流的还有Consul、Zookeeper、Etcd。这几种注册中心的区别我这里不做赘述，读者可以自行参阅官网的介绍，并根据自己公司的业务场景进行技术选型。虽然Netflix官方表示对Eureka2.x进行无限期搁置，但事实上1.x版本已经非常稳定，而且官方仍在不断维护，所以没有必要危言耸听。另外，很多大公司都是基于Eureka或Zookeeper二次开发，自研注册中心的。一、Eureka
我曾在分布式理论篇——服务化拆分中介绍过微服务，SpringCloud就是微服务架构的集大成者，将一系列优秀的组件进行了整合。通过SpringCloud，我们可以快速构建一套基于微服务架构的分布式系统。SpringCloud的组件相当繁多，其提供的核心组件如下：Eureka：服务注册中心Feign：服务调用Ribbon：负载均衡Zuul/SpringCloudGatway：网关纯粹的讲SpringCloud的各个组件非常枯燥，对于很多初学者童鞋也不太友好。所以，本章我将引入一个电商系统作为案例背景，讲解SpringCloud的各个核心组件的基本使用。读者可以参考SpringCloud的官网资料
SPI全称为ServiceProviderInterface，是一种服务发现机制。SPI的本质是将接口实现类的全限定名，配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类，正因为该特性，我们可以很容易的通过SPI机制为程序提供拓展功能。一、DubboSPIDubbo就是通过SPI机制加载所有组件的。不过，Dubbo并未使用Java原生的SPI机制，而是对其进行了增强。接下来，我们先来了解一下JavaSPI与DubboSPI的用法，然后再来分析DubboSPI的源码。本文章所分析的源码版本均为dubbo-2.6.4。因此大家在阅读文章的过程中，需注意将代
从本章开始，我将介绍分布式系统中与可扩展这一特性息息相关的一些开源框架的基本架构和核心原理。本章，我们先来看下Dubbo这个分布式RPC框架。在分布式理论系列中，我已经讲过了服务化拆分，读者可以先去回顾一下。目前，业界最常用的开源RPC通信框架有Dubbo和Thrift。读者在阅读本章的过程中可以参考Dubbo官方文档：http://dubbo.apache.org/zh-cn/docs/user/quick-start.html。一、基本架构我们先来看看Dubbo的基本架构：在使用dubbo的过程中，与客户端直接交互的有以下五类节点：节点角色说明Provider服务提供方Consumer服务
在分布式系统中，为了保证集群的数据一致性，我们经常会有使用分布式锁的需求。生产环境实现分布式锁，最常用的还是基于Zookeeper，或者使用Redis来实现。本章，我就来讲讲Redis分布式锁的原理。一、RedLockRedis官方支持原生的分布式锁，采用了RedLock算法。这个分布式锁有3个重要的考量点：互斥（只能有一个客户端获取锁）；不能死锁；容错（大部分Redis节点获得这个锁，就认为加锁成功）。1.1使用方法可以通过以下命令来加锁：SET[key][value]NXPX[30000]NX的意思是只有key不存在的时候才会设置成功，别人创建的时候如果发现已经有了就不能加锁了；PX300
Redis从3.0版本开始支持原生的集群模式，即RedisCluster。我在分布式理论基础篇中已经介绍过分布式集群。RedisCluster其实就是一种数据分散集群架构，并可在此基础上进行读写分离。RedisCluster的主要功能如下：Master/Slave模式，支持N个masternode，每个masternode都可以挂载多个slavenode，如果mater挂掉，rediscluster这套机制，就会自动将某个slave切换成master；读写分离，对于每个master来说，写就写到master，然后读就从mater对应的slave去读；RedisCluster，主要是针对海量数据
我们在搭建Redis的主从架构时，主节点一旦由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址，对于很多应用场景这种故障处理的方式是无法接受的。要实现Redis的真正高可用，我们需要完成主从架构下的故障自动转移。Redis官方提供了一套RedisSentinel机制，用于当主节点出现故障时，自动完成故障发现和故障转移。一、基本架构哨兵模式下，我们需要配置一些哨兵节点（为了保证哨兵自身高可用，至少部署3个哨兵节点），这些哨兵节点构成了一个集群，监控着普通的主从节点的状态：RedisSentinel包含了若个Sentinel节点，这样做也带来了两个好处：①对于节点
Redis作为分布式缓存，必然要保证自身的高可用。而分布式系统实现高可用的方式主要就是主从和集群。Redis也不例外，它有自己的Master节点和Slave节点。Redis既支持传统的数据集中集群模式，也支持数据分散集群模式。本章，我们先来看看Redis的数据集中集群模式，也就是Master/Slave模式。对分布式理论还不是很清楚的童鞋，可以回头去看看基础篇的集群章节。在主从架构下，Redis的Master节点和Slave节点都各自保存着完整的数据，Slave节点会从Master节点同步数据：当启动一个slavenode时，它会发送一个PSYNC命令给masternode。psync命令用于
Redis作为分布式缓存，数据首先是存储在内存中的，但是为了保证数据不丢失，肯定需要将数据持久化到磁盘上。所以，本章我们就来讲讲Redis的持久化原理。Redis一共提供了两种数据持久化方式：RDB、AOF。通过RDB或AOF，我们可以将Redis内存中的数据持久化到磁盘上，然后将这些数据备份。如果Redis挂了，可以将备份数据放到指定的目录中，然后重新启动Redis，Redis就会自动根据持久化数据文件中的数据，恢复到内存中，继续对外提供服务。如果我们仅将Redis作为纯内存的缓存来用，那么可以禁止RDB和AOF。一、RDB持久化RDB持久化，是一次性生成内存快照的方式，也就是把当前Redi
本章，我们来看看Redis的内存管理，主要包含Redis的内存模型、内存管理方式以及缓存淘汰策略。一、内存模型1.1对象内存对象内存，是Redis内存占用最大的一块，存储着用户所有的数据。Redis所有的数据都采用key-value格式，每次创建键值对时，至少创建两个类型对象：key对象和value对象。key对象都是字符串，value对象包含五种数据结构类型。所以，对象内存消耗可以简单理解为sizeof（keys）+sizeof（values）。1.2缓冲内存缓冲内存主要包括：客户端缓冲、复制积压缓冲区、AOF缓冲区：客户端缓冲：指的是所有接入到Redis服务器TCP连接的输入输出缓冲；复制
在各类分布式框架中，还有一类是和高性能息息相关的，那就是分布式缓存。目前生产环境常用的开源分布式缓存框架就是Redis和Memcached，它们之间的主要区别，我这里简单比较下：Redis拥有更多的数据结构，支持更丰富的数据操作。Memcached没有原生的集群模式，而Redis原生支持cluster模式。目前Redis在工业环境中用得比较多，所以本系列只介绍Redis。如果读者对Memcached感兴趣，可以参考其官方文档。一、Redis线程模型Redis是典型的单线程架构，所有的读写操作都是在服务端的一条主线程中完成的。Redis客户端与服务端的模型如下图，每次客户端调用都经历了发送命令、
本章，我们来看下Elasticsearch的持久化原理，也就是数据在底层究竟是如何写入到磁盘上的。开始之前，先来了解一个基本概念——Segment。一、SegmentFile我们知道，在Elasticsearch中创建一个index索引时，需要指定shard分片，一个shard分片在底层其实是一个Lucene索引，它由若干个segment文件和对应的commitpoint（提交点文件）构成。segment文件可以理解成底层存储document数据的文件，ES进行检索时最终是从它里面检索出数据的；而commitpoint文件可以理解成一个保存了若干segment信息的列表，它标识着这个commi
本章，我将从分布式系统的几个核心要点去讲解Elasticsearch的基本架构。通过本章的学习，我们会看到，分布式框架的很多架构设计理念都是相通的，无外乎就是围绕着高可用、可扩展、高性能、数据一致性这四方面展开的。一、基本架构1.1进程节点我们在生产环境部署Elasticsearch时，都是一台机器上启动一个Elasticsearch进程实例，比如我们有三台机器，那么三个ES进程实例就构成了一个ES集群，每个实例我们把它叫做一个节点：1.2负载均衡当我们建立Index索引时，必须指定索引有几个primaryshard，以及primaryshard的replicashard数量。比如，创建一个名
从本章开始，我将讲解和高性能相关的另一类分布式框架——分布式搜索引擎。目前开源界主要的搜索引擎框架有三个：Lucene、Elasticsearch、Solr。事实上，Lucene仅仅只是一个库，而Elasticsearch和Solr在底层都是使用了Lucene，相当于对它进行了封装，从而对用户更加友好，使用更加便捷。Elasticsearch是一个开源的分布式、RESTful风格的搜索和数据分析引擎，采用Java编写，内部使用ApacheLucene做索引与搜索，它的目标是使数据搜索和分析变得更简单。简单来说，Elasticsearch就是对Lucene做了一层封装，它提供了一套简单一致的RE