本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客
继续上篇。目前我们的系统如图1,已经可以完成数据生产和更新。但是目前我们的业务是分布式集群,每台机器收到的的消息时间不一样,那每个机器的数据版本在更新数据期间,就可能不一样。那在服务数据升级时,请求被分到不同机器上,那就会导致请求计算使用的数据版本来不一致,可能会影响用户体验。
图1
那如何保证用户请求返回的一致性呢。首先,没有观察者和被观察者就没有一致性这个说法,因为从客观的角度来看,消息一定不会同一时间到达,所以一定会有一段时间,服务的数据版本不一致。除了我们的系统,任何分布式系统都一样,客观角度,在服务变更的时候,没有可能做到机器之间完全一致。这是由客观物理规律决定的,简单的说,光速是固定的,而到达机器的路径长度是不一致的。当然,量子计算机不在本文的讨论范围内。
客观的不一致是不可避免的,但是从观察者的角度来看,不同请求的一致性,还有优化的空间的。最理想的情况就是,在用户的眼中,服务集群的行为和单机一摸一样。那么我们第一个解法就自然出现了,让同一个用户的请求,始终发往同一台机器,目前大部分负载均衡的服务器都支持该功能,不过这不能完全保证一致性,因为机器可能重启或者被置换。另外这种方法,不适合用户量不大,且用户之间请求十分不均匀的情况下,可能导致数据倾斜。
在同一个用户的请求必须分布到不同机器的时候,那服务返回的数据不一致将不可避免。但是客户端如果也在我们的控制范围内,事情似乎也变得简单,我们在客户端记录上次获取的结果使用的数据版本,如果此次请求返回的版本比上次还小,就重试,直到得到获取到的结果使用的数据版本大于等于上次,这个方法并不是没有代价,我是用了部分请求的延迟,换了一致性。正如这个方案表现的这样,系统设计中没有银弹,只有取舍。但是上面这个办法还不够完美,因为客户端重启甚至重装的时候,上次请求的版本就丢失了,而上一次请求已经用了新版本的数据,虽然这种情况,一般不会对版本顺序一致性有高要求,但是如果有,则客户端记录就变得困难。虽然我们可以积累一小段时间的请求,如果版本都一致我们才使用,但如果用户足够多,部分请求还是可能恰好全在老版本机器上,导致重启后,请求到的结果版本反而是老的。所以客户端记录虽然能解决大部分问题,但是小部分极端情况,我们还得在服务端解决一致性问题。
服务端要保证每个用户得到的请求结果是一致的,那就是需要机器之间通信,保证任意一个机器除了用户请求时,知道上次该用户请求到的数据版本。这意味着,用户上次请求的信息,在某个地方持久化了,并且一个用户的多个请求,在不同机器不能同时执行,必须一个机器执行完了,才能执行下一个,这大大降低了请求处理的吞吐量。强一致性(线性一致性和顺序一致性)的代价就是降低了系统吞吐量。
如果系统可以容忍,短时间的版本回退,也就是对客户端来说,服务端是最终一致性,那就大大增加了系统吞吐量。当然最终一致性也会因为“最终”是指需要10秒,还是1小时,而影响系统的复杂度。
这里没有完美的方案,需要根据实际业务做取舍,对于我们的日期间隔计算系统,我的选择是系统为最终一致性,具体做法是在服务侧让用户请求尽量到一台机器,用户如果期望降低不一致的情况,自行在客户端存储版本来过滤。核心原因是,我主观地认为这个场景,保证强一致性增加的收益,远小于增加的服务器资源。但是这个观点不是永恒的,它会随着客户需求,以及资源成本的变化而变化。
通过本章,我们的架构更清晰了,我们明确了架构在一致性问题上的能力边界。虽然架构可以提供节假日查询了,但是用户如果才能查询过去的请求记录呢,我会之后的章节中分享我的经验。