分布式一致性与共识

在学习微服务RPC，服务注册发现等相关概念时，总是绕不开一个话题分布式一致性，虽然之前在MIT6.824的课程中已经进行深入的学习，但是每每遇到还是对这些概念不甚清晰，因此这篇博客主要是从整合的角度复习之前学过的知识。

常见概念

分布式和单机本质的不同在于没有一个统一的时钟以及一份数据有多个副本，不同的用户请求于不同时间发出，由于网络延迟等问题以不同的顺序，对不同数据副本进行操作，这就带来两个问题：

1. 如何确定谁的请求先来，谁的请求后来，怎么确定一个所谓的“先来后到”？（可以类比Mysql并发控制的感觉）
2. 副本的操作如何及时同步，用户能不能看到最新的副本？

RPC框架整体理解

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction.

— wikipedia

RPC（remote procedure call）远程过程调用，通过封装底层网络通信细节，向跨网络的服务提供如同本地调用一般的远程调用接口

• RPC来源于微服务架构的发展，越来越多业务系统被拆解为多个相互协作的微服务，借助RPC工具能够方便实现不同服务之间相互调用。
• 常见的RPC框架有：Dubbo、Thrift、GRPC、Spring Cloud（部分）

RabbitMQ集群相关

Clustering is meant to be used across LAN. It is not recommended to run clusters that span WAN.

似乎所有的中间件框架最后都要走到集群配置这一步，RabbitMQ通过集群配置实现数据和服务的可要行，官网推荐在局域网中使用RabbitMQ集群，跨网络间的同步建议通过 Shovel or Federation等插件实现。

RabbitMQ集群主要解决服务器崩溃导致的服务不可用以及数据丢失问题，集群中节点同步备份所有的元数据，由于集群本身并不执行队列的备份，通过特殊类型的队列（镜像和quorum）实现队列备份。

1. 队列元数据：并不同步队列本身以及队列中的消息
2. 交换机元数据
3. 绑定元数据
4. vhost元数据

对于队列中存在的部分无法消费的消息（dead-lettered），RabbitMQ提供”死信队列”机制，实现死信的收集处理。死信队列还是普通的队列，只是其于某个队列绑定，当该队列出现私信时会将死信转发到该队列中，提供给该队列消费者处理。

RabbitMQ官网教程RabbitMQ Tutorials中提供了六个入门案例，下面按照案例顺序逐个进行实践操作，了解RabbitMQ的基本应用

1. “Hello World”：简单一对一队列
2. “Work Queues”：一对多队列，模拟任务分配
3. “Publish/Subscrible”：Fanout类型交换机，广播消息
4. “Routing”：direct类型交换机，根据RoutingKey发送到对应队列
5. “Topics”：topic类型交换机，根据RoutingKey的匹配规则发送到对应队列
6. “RPC”：使用消息队列模拟RPC调用
7. “Publish Confirms”：通过发送确认，实现发送端可靠性保证

为了基于Java操作RabbitMQ，需要加入对应的Client依赖

1
2
3
4
5
6

<!-- https://mvnrepository.com/artifact/com.rabbitmq/amqp-client -->
<dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>5.14.2</version>
</dependency>

RabbitMQ基本概念

如下图(来自百度百科)，RabbitMQ是基于高级消息队列协议（AMQP）设计实现的消息中间件，主要包括的概念有交换机(Exchange)、消息队列(queue)、绑定(binding)、通道(channel)等。

Redis支持两种持久化手段，下面分别进行总结

1. RDB（Redis DataBase）：将当前Redis数据库中的所有数据以二进制的形式存储在.rbd文件中，也就是状态备份。
2. AOF（Append Only File）：将写操作持久化在AOF文件中，也就是状态机备份。

RDB

RDB机制将当前Redis存储的所有KV对存储在二进制文件中，持久化的触发时机有两个：

1. 显式调用save或bgsave

2. 满足配置文件中的持久化条件

   • 在过去的xxx秒内，若写入操作超过xx个，则进行RDB持久化
   

Redis支持多机多实例部署，通过多实例部署，可以保证服务不受到单个Redis示例宕机的影响，实现服务的数据的可靠性和高可用，下面结合代码和底层原理，加深对于Redis多机部署的理解，主要内容来自Redis设计与实现

主从复制

Redis的主从复制在我看来较为轻量级，由从节点向主节点申请成为从节点，主节点不断向从节点发送数据，实现同步，与Mysql主从复制不同的是，即使在同步前主从状态不一致，同步后也会变为一致。

通过replicaof命令可制定当前Redis实例为对应实例的从机关系，重启即失效：

1
2
3
4

# replicaof 主机IP 端口
replicaof 192.168.1.1 6379
# 取消作为从机
replicate no one

Redis数据结构

redis有六种主要的数据类型，下面从调用API以及底层实现原理对于Redis中主要数据类型进行总结和整理，主要内容来自redis文档和《Redis设计与实现》。

底层数据结构

字符串(simple dynamic string)

字符串是Redis中最基本的数据类型，键和值的类型均为字符串类型，底层基于支持动态扩容的简单动态字符串（simple dynamic string,SDS）实现，其数据结构示例如下：

1. len：buf数组中已经使用的长度，遵循C语言字符串末尾添加空字符\0的习惯
2. free：buf数组中还剩余的长度

1
2
3
4
5

struct sdshdr{
    int len;
    int free;
    char buf[];
}