蜗牛的高铁

最近打算使用MinIO替代原来使用的FastDFS，所以一直在学习MinIO的知识。这篇文章是基于MinIO多节点多驱动的部署进行研究。

十年前做项目的时候基本都是单体应用开发，那个时候缓存基本都是使用JVM的内存，后来随着应用的拆分，我们使用独立的缓存服务器，一开始主要是存储会话数据，后来将一些不常改变但是经常使用的字典数据也使用缓存存储。如果只是使用一个存储节点，对于中小项目来说是够用的，即使抛开缓存大小的问题但也面临着高可用的问题，所以本文就Redis缓存的扩展性和可用性深入研究一下。

在分布式系统中，为了提高系统的可用性，达到99.999%的指标，我们通常会对服务节点做集群，采用主从互备的方式增强服务的可用性。在主从互备的集群中，主节点和从节点需要保证数据一致，主节点服务出现问题后，需要在从节点中选举出一个新的主节点，那么常用的分布式选举算法有Bully算法、Raft算法、ZAB算法。本节主要对ZAB算法进行分析。

在分布式系统中，为了提高系统的可用性，达到99.999%的指标，我们通常会对服务节点做集群，采用主从互备的方式增强服务的可用性。在主从互备的集群中，主节点和从节点需要保证数据一致，主节点服务出现问题后，需要在从节点中选举出一个新的主节点，那么常用的分布式选举算法有Bully算法、Raft算法、ZAB算法。本节主要对Raft算法进行分析

假设集群环境中有五个节点，ID从小到大分别是1、2、3、4、5，这五个节点相互连接，每个节点都知道其他节点的ID，节点暂且称为N1、N2、N3、N4、N5，其中数字表示大小，在初始化的时候N5直接选举为主节点，其他四个节点为从节点。运行期间N5突然故障，剩下的其中一个节点发现主节点服务故障，发起“选举”消息，比如N1节点最先发现主节点宕机，那么N1节点向N2、N3、N4、N5节点发起“我要选举”的消息，N2、N3、N4返回给N1节点“同意选举”消息。N1节点无法成为主节点，只能等待主节点的通知消息。

在分布式系统中，随着服务的拆分，数据也随之拆分，通过对数据库的合理设计，数据库的水平扩展就可以解决这个问题了。这就是“众人拾柴火焰高”、“人多力量大”。那么在分布式存储中，我们怎么进行合理的设计，去缓解数据库压力，提高数据操作效率呢？我主要从分表分库、主从复制、数据扩容三方面去梳理一下知识点。...

之前做项目时，业务拆分粒度比较大，数据库也自然而然的拆分了，这当中遇到最主要的问题就包含数据相关问题，比如：字典数据问题，我们知道在列表展示数据的时候通常会用到字典数据，假如字典数据做同步那么直接关联查询就可以搞定，如果字典数据不做同步，那么又该怎么实现列表数据展示？本节内容我就分布式系统中数据库存储的热点问题进行梳理。

自从我接触分布式系统以来，困扰我的最大两件事，第一是业务拆分，第二个就是分布式事务的问题。在做单体应用的时候，我们只处理一个库的数据，一个@Transaction注解就能搞定。而在分布式系统中，随着业务服务的拆分，数据库自然而然的也会拆分，所以原本的单库事务就变成了多个数据库的事务操作，所以我们就要想尽各种办法去保证数据的一致性。通过重新梳理分布式事务的知识，我总结了两理论、一模型、两协议、三方案。

RPC是Remote Procedure Call(远程过程调用)，即一台服务器上的服务可以像调用本进程内的方法一样去调用远程服务器上的方法，简单点理解就是让不同网络节点的服务相互调用，是一种典型的分布式节点间同步通信的实现方式。...

在分布式系统中，不管单个服务器多么强大，总有资源枯竭的时候，所以不管怎么优化，都会遇到性能的瓶颈。举个例子，我们把学校餐厅看作一个分布式系统，那么学校餐厅卖小炒看作一个服务，假如就一个厨师，厨师技能再高，同时可以操作多个灶，出菜量远供不上学生点菜的量，所以我们就应该多几个厨师，这样会比一个厨师强多了。......