分布式数据库如何平衡一致性和读写延迟.docxVIP

分布式数据库如何平衡一致性和读写延迟？ 为了提供高可用能力、避免数据丢失，在分布式数据库或存储系统中需要设立数据副本机制，而副本的引入，可以说是分布式存储中的“万恶之源”。多副本之间应该满足强一致吗？强一致会导致请求延迟增加多少？强一致约束下能提供哪些可用性？诸如此类，种种问题，不一而足。 此外，分布式系统中的 CAP 原理可以被表述为：在网络分区存在的情况下，强一致与可用性是不可兼得的。由此发展出符合 BASE 标准的 NoSQL 数据库，在这类数据库中，以最终一致性取代强一致性。 那么，我们所说的强一致和最终一致究竟是指什么呢？ 强一致意味着多副本数据间的绝对一致吗？显然，在分布式系统中，由于网络通信延迟的存在，多副本的严格一致是不可能的。 那是代表返回写入请求时多副本已经达到完全一致了吗？熟悉 Raft 的朋友会立即指出，不一定，Raft 就只需要在 quorum 中（超过半数）副本达成一致即可返回写入成功。 抑或是只需要 quorum 的一致即可吗？这取决于具体的算法，如果我们不限定读取操作只被 leader 处理，那么，达成 quorum 一致之后仍然可能读取到旧数据。 而在实际系统中，一致性问题的解法可能更加复杂，需要在一致性、读写延迟中做出权衡。 以时序数据库 TDengine 为例，我们为元数据的读写提供强一致性；时序数据在部分场景中则需要降低读写延迟、提高吞吐，仅