2020-05-10

关于从客户端的角度去理解一致性可能产生的误区

Views: 7368 | Add Comments

很多人从客户端并发的角度去讨论一致性, 这其实是一个错误的方向. 并不是说客户端与一致性无关, 相反, 客户端正是要求一致性的需求者.

一致性协议不负责客户端的并发协调. 例如抢红包, 防超卖, 秒杀这类业务需求, 不是 Paxos/Raft 能解决的.

首先, 我们需要定义先后, 何为"先", 何为"后"?

      q1          r1          q2          r2
------+-----------+-----------+-----------+-----

如图, q 是指客户端发起请求的时间点, r 是指客户端收到响应的时间点, 两个请求用 1, 2 来表示. 很显然, 两个请求的先后顺序没有争论.

如果是并发呢? 先后就变得让人迷惑了.

      q1          r1 
------+-----------+-----------
         q2          r2
---------+-----------+-----------

你说, 哪个请求先哪个请求后? 一般认为, 请求 1 先于请求 2. 这个一般也不会有争论.

接着, 是最让人迷惑的地方了.

      q1          r1 
------+-----------+-----------
         q2    r2
---------+-----+-----------

你说, 请求 1 在先还是请求 2 在先? 争论不休吧? 所以, 讨论一个一致性的系统, 必须要求观察者的行为是瞬时的, 不能是并发的.

观察者(客户端)当然可以并发, 但是, 如果客户端自己都不能分清先后的话, 去预期系统(服务端)的执行结果是没有意义的.

一个强一致性的系统(服务端)当然可以处理并发请求, 而且请求的处理也不是瞬时, 这没关系. 我们讨论的是服务器在并发处理这些请求时的一致性可预期的行为, 而不是从客户端的角度看客户端并发时的系统的行为, 这里一定要注意.

事实上, 一个一致性的系统, 只关注行为完成时点的先后的关系, 并不关注行为的发起是什么先后顺序. 所以, 请求到达服务器的时间先后关系没有任何意义.

一致性, 讨论的是完成时, 不关心发起时.

Related posts:

  1. Paxos什么都包含, 也什么都不是
  2. Raft Read Index 的实现
  3. Paxos和Raft读优化 – Quorum Read 和 Read Index
  4. 关于 Paxos 论文中的迷惑之处
  5. Paxos 与分布式强一致性
Posted by ideawu at 2020-05-10 14:30:01

Leave a Comment