分布式系统多副本设计的挑战
在应用层之下,其实是需要大量分布式中间件支撑的。
那设计开发一个分布式系统,需要关注哪些东西,有哪些挑战呢?
分布式系统,简单可以理解为一些独立的机器通过网络相互传递消息,进行通信。这些机器可能相距很远或者很近。
分布式系统中,需要设定一个非常重要的世界观,就是一切都会失败,磁盘会出现问题、网络会出现问题、数据中心会断电或者遇到地震。
所以,一个分布式系统,需要应对以上的异常情况,保障业务持续运行,这也是分布式系统非常重要的价值之一。
由于一个大型系统,是在地理上的分布,那不同地理位置上距离较远的数据中心的通信就会很慢。一些全球化的互联网应用,机器可能彼此在地球的两端。
不管是磁盘故障、网络抖动、数据中心被摧毁、地理位置过远导致的延迟,这些导致的可用性问题,都可以通过数据复制、冗余的方式解决。
一份数据在多个物理位置的备份,有助于解决可用性和性能,一种空间换时间与可用性的思路。
这些副本数据可以存储在一个数据中心之内,也可以存储在多个数据中心之间。
你拥有的副本越多,容错能力就越强,数据丢失的可能性就越小。
结合数据局部性原理,可以最大限度地减少延迟,就是让副本接近于可能访问它的人。
副本多的另一个好处是,可以尽可能为更多人提供访问,也就是提高了访问吞吐。
副本复制可以解决大部分分布式系统的问题,但也会导致一些新的问题。
好处是,引入多个副本是必不可少的。但你需要做好副本之间数据一致性的处理,特别是对于网络问题的处理,比如网络抖动、网络分区、副本延迟等问题。
对于副本一致性,你需要知道,试图始终保持地理分布副本的完全一致是徒劳的。
在分布式分区的情况下,实现完美一致性的唯一方法就是牺牲数据的可用性。
所以我一直认为,在分布式系统中,没有所谓的强一致性,都是最终一致性,只不过这个最终一致的时间窗口小到业务可以容忍的范围下。
由于在处理地理分布数据时,网络分区是不可避免的,我们通常会选择运行用户看到副本之间的数据差异的设计,也就是优先考虑可用性。也就是CAP原理的综合选择。
如果我们想处理好多个副本之间数据差异的分歧,我们就需要设立一种策略。这个策略允许副本数据在何时被认可,何时被拒绝。
对于策略,首先想到的是数据顺序策略,后来的数据覆盖前一个数据,顺序可以通过时间戳或发号器的方式解决。
如果逻辑上发现新的请求已经滞后了,直接聚焦请求即可。
另一种策略是因果一致性,就是在业务逻辑上推导出一致性,应该先有什么,再有什么。比如先有文章,才能再有评论,而不是先有了评论,还没有文章。
处理一致性背后有一个好用的原则,就是处理的顺序性,比如有时候单线程处理状态数据顺序性,比多线程处理状态数据的顺序性要简单很多,而且业务效果差不多,所以不是任何时候都需要并行、异步的。
在设计基础的分布式组件时,同样需要注意高内聚、低耦合、SOLID原则。
比如,分布式基础设施api的设计,需要极高的收敛性,因为分布式面对的问题都是非功能性的问题,对调用方越透明越好。
如果api不够收敛,调用方式就会多样,也就会导致各种不同的实现差异和使用差异。
好的api可以见名知意,也更利于单测,因为底层能力的可用性是非常重要的,传统qa的冒烟测试是不够的。
相关文章
- 深入理解mybatis原理(五) MyBatis缓存机制的设计与实现
- 低功耗设计方法--频率与电压缩放存在的挑战
- 玩玩webgame开发(4):游戏数据结构设计[通俗易懂]
- 2022年最酷的6个Logo设计灵感干货网站
- BCG界面库_如何用vc设计界面
- 网站建设中十个常见的网页设计错误
- 用c语言手搓一个600行的类c语言解释器: 给编程初学者的解释器教程(2)- 简介和设计
- Dubbo 技术详解,我非常喜欢Dubbo的设计
- 麒麟985和麒麟990已经完成设计,但海思正迎来严峻挑战
- Boost Your Programming Power With Linux Multithreading(linux多线程设计)
- 深入解析Oracle字段设计技巧(oracle字段设计)
- 深入了解MySQL数据表格式,优化你的数据库设计与管理(mysql数据表格式)
- 数据库与Redis优化与设计的挑战(数据库和redis设计题)
- 范式常见问题MySQL 数据库设计中常以三范式为基础,但实际应用中也经常面临各种与反三范式有关的挑战和问题,请看重点分析
- 利用Redis攻击模式调查安全设计中的新挑战(利用redis攻击)
- SearchEngineFriendly的URL设计