Un escenario distribuido simple
Descripción del rol
- Cliente Cliente, responsable de iniciar solicitudes
- El servidor servidor recibe la solicitud del cliente y guarda los datos solicitados.
Ahora se implementan tres servidores, y cada servidor guardará la información solicitada por el cliente y la almacenará en un registro. Cuando el cliente inicia una solicitud al Servidor_1, el Servidor_1 registra el registro y lo sincroniza con el Servidor_2, y el Servidor_3 mantiene la coherencia de los datos, lo que no parece ser un problema.
Pero unirse, ¿el cliente solicita varios servidores al mismo tiempo? ver lo que está mal
¿Cómo garantizar que la secuencia de registro de cada servidor sea consistente? Por ejemplo, la última secuencia de registro de cada servidor es log1, log2 o log2, log1
La replicación de datos simple definitivamente no es posible, como la siguiente situación
La secuencia de registro final de Server_1 es log1 log2, la secuencia de registro de Server_2 es log2 log1 y la secuencia de registro de Server_3 es posible.
Este es el clásico problema de consistencia en escenarios distribuidos, el propósito de Paxos es resolver este problema y mantener los datos de todos los servidores consistentes.
Entonces, ¿cómo resuelve Paxos este problema? Esa es la cuestión que se explicará a continuación.
Antes de entender paxos, si el concepto de 2pc no está claro, se recomienda entender primero 2pc y luego ver paxos, porque al final encontrarás que paxos también es una idea de 2pc, pero se han hecho algunas optimizaciones.
paxos
Si hablas directamente de varios conceptos de paxos, como Propuesta, Proponente, Aceptante, etc., aumentará la dificultad de comprensión, por lo que será mucho mejor si uso un ejemplo que es muy común en la vida.
subasta
Subasta, creo que todos están familiarizados con ella, con una pequeña modificación, nuestro proceso de subasta actual es el siguiente:
Sección de ofertas:
1. 每个人都可以发起竞价，告诉其他人竞价的筹码。
2. 同理，其他人发起竞价时，每个人也会收到竞价信息，有两个可能
a. 假如竞价筹码 <= 最大筹码，回复（no）
b. 假如竞价成功 > 最大筹码，记录最大筹码 = 竞价筹码
ⅰ. 如果商品没被购买，回复（yes，null）
ⅱ. 如果商品已被购买，回复（yes，购买筹码，购买人信息）
3. 当一个人发起竞价后，会收到其他人的竞价结果的回复，超过一半人告诉你竞价成功（少数服从多数），就可以发起购买的请求了（会告诉其他所有人）。
复制代码Parte de compra:
1. 发起购买时候，携带两个信息（购买的筹码，个人信息）
2. 当收到其他人的购买请求后，有两种可能：
a. 如果 购买筹码 >= 最大筹码，记录购买者的购买筹码和个人信息，然后回复(yes)。
b. 如果 购买抽买 < 最大筹码，回复(no)。
3. 收到购买回复后，如果为超过半数yes，则表示购买成功，结束流程。反之，提高筹码，重新发起竞价。
复制代码El efecto final a lograr es que los chips de compra de commodities y la información personal registrada por todos sean los mismos.
Descripción del flujo
Veamos primero cómo funciona sin competidores Después de entender el concepto, ahora se expresa en términos especiales.
Nota mental
- Proponer: fichas equivalentes
- Proponente: El miedo que es equivalente a iniciar licitaciones y solicitudes de compra.
- Aceptador: el rol que es equivalente a recibir la solicitud
descripción variable
- id: indica el tamaño del chip
- max_id: Indica el registro actual del chip más grande
- acc_id: Indica las fichas compradas
- acc_val：表示购买人信息
步骤一：协商
收到yes时候，acceptor会将acc_id 和 acc_val 返回
- 假如acc_val都为null，说明还没有设置过val，则将自己的val在第二阶段发送给acceptor
- 存在acc_val不为null的情况，proposer必须无条件使用acc_id最大的acc_val作为第二阶段发送的val
if (id > max_id){
max_id = id;
reutrn (yes, acc_id，acc_val);
} else {
return (no);
}
复制代码步骤二：提交
当步骤一中超过半数的yes时候，进入步骤二：
if (id >= max_id){
max_id = id;
acc_id = id;
acc_val = val;
return yes;
}else {
return no;
}
复制代码接收到达响应的结果有两种
- 收到超过一半的yes，流程结束。
- 少于一般的yes，则自增id，重新执行步骤一。
至此，paxos的流程就走完了，对于发生竞争的情况，paxos是如何做到保持一致的，我的建议是根据上述的判断条件，自己动手模拟下（当初也是自己模拟后，帮助我更快的理解了整个流程）。
参考
- 《凤凰架构》周志明，第6章 Paxos
- 《软件架构设计》余春龙