之前《浅谈分布式CAP定理》简单介绍了数据在分布式系统中存在的必然定理。简单回顾一下，一个数据在一个节点需要同步到另外一个节点的过程中，在未完成同步的时候，会出现数据不一致的情况，所以此时必然存在分区容错性（Partition tolerance）。分布式系统只能从一致性（Consistency）或可用性（Availability）之间去选择。

CAP讲的是分布式一致性，而这次我们来聊聊分布式共识性。很多开发者一直以为一致性与共识性是同一个东西，但两者讲的是完全不同的东西。

• 一致性：A点同步B点数据，然后两者之间的数据可以达成一致。
• 共识性：一个或多个节点提议了一个值应当是什么后，采用一种大家都认可的方法，使得系统中所有进程对这个值达成一致意见。

共识性比较常见的场景就是选主，例如redis主挂掉了，集群通用共识性算法选出一个主。比特币之类的电子货币也需要更复杂的共识性算法。

下面我们一步步聊下分布式共识性的一些常见算法与问题。

写过java的都知道，lombok几乎在项目中处于不可或缺的一部分，但是lombok在Gradle的项目中配置并非人人都知道。

很多人在项目依赖中直接这样写

1

compile "org.projectlombok:lombok:1.18.4"

但这样的处理在Gradle 5.0以上被命令禁止了，在4.x的高级版本中编译时也会有对应的告警

1
2
3
4
5

The following annotation processors were detected on the compile classpath: 'lombok.launch.AnnotationProcessorHider$AnnotationProcessor' 
Detecting annotation processors on the compile classpath is deprecated and Gradle 5.0 will ignore them.
Please add them to the annotation processor path instead. 
If you did not intend to use annotation processors, 
you can use the '-proc:none' compiler argument to ignore them.

Docker简述

Docker是一种OS虚拟化技术，是一个开源的应用容器引擎。它可以让开发者将应用打包到一个可移植的容器中，并且该容器可以运行在几乎所有linux系统中（Windows10目前也原生支持，Win10前需要内置虚拟机），正所谓“一次打包，到处运行”。

Docker容器的运行是完全的沙箱机制，相互之间不会有任何关联（除非自己串联集群）。网络、存储、进程等资源，不仅对于不同的容器是相互隔离，对于宿主机和容器直接也是隔离的，除非你手动映射暴露端口或者挂载存储卷。

很多人不理解，Docker和虚拟机到底有什么区别。

之前已经分析过了Spring的IOC(《零基础带你看Spring源码——IOC控制反转》)与AOP(《从源码入手，一文带你读懂Spring AOP面向切面编程》)的源码，本次就来分析下SpringMVC。本文先简述下目前SpringMVC的使用情况，然后通过Demo的简单让大家有一个初步的使用印象，然后带着印象去看其中执行的分发源码。

到底什么是Spring MVC，我们还在用吗？

Spring MVC，官方名字其实是Spring Web MVC，Maven上的包名也是spring-webmvc。从Spring诞生以来，它就是一款基于Servlet Api的web架构。值得一提的是，在Spring5的时候，出了一款新的Web架构，Flux，是基于事件驱动模型（类似nodejs）做的。以后会写一篇来专门介绍一下Flux，敬请关注。

MVC，可以说是“上个世纪”最流行的前后端交互模型。它包含Model（业务模型）、View（用户视图）、Controller（控制器），把各部分分开组织，对代码抽象与隔离的处理可谓是代码设计的典范。

不过自从15年开始，随着各种前端框架的崛起，使得前端后端的关系发生进一步的演变，从MVC架构演变成前后端分离的REST架构了。以前MVC架构每次请求都需要经过控制器->模型->视图的流程，演变成前端请求后端接口，返回JSON的这样一种REST架构。

前面介绍了《进阶的Redis之数据持久化RDB与AOF》和《进阶的Redis之Sentinel原理及实战》，这次来了解下Redis的集群功能，以及其中哈希分片原理。

集群分片模式

如果Redis只用复制功能做主从，那么当数据量巨大的情况下，单机情况下可能已经承受不下一份数据，更不用说是主从都要各自保存一份完整的数据。在这种情况下，数据分片是一个非常好的解决办法。

Redis的Cluster正是用于解决该问题。它主要提供两个功能：

1. 自动对数据分片，落到各个节点上
2. 即使集群部分节点失效或者连接不上，依然可以继续处理命令

对于第二点，它的功能有点类似于Sentienl的故障转移（可以了解下之前Sentinel的文章），在这里不细说。下面详细了解下Redis的槽位分片原理，在此之前，先了解下分布式简单哈希算法和一致性哈希算法，以帮助理解槽位的作用。