分库分表与分布式数据库技术选项分析

最近经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好坏其实有失公允。


分布式事务科普

随着业务的快速发展、业务复杂度越来越高,传统单体应用逐渐暴露出了一些问题,例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等。而微服务架构是将单个服务拆分成一系列小服务,且这些小服务都拥有独立的进程,彼此独立,很好地解决了传统单体应用的上述问题,但是在微服务架构下如何保证事务的一致性呢?本文首先从事务的概念出来,带大家先回顾一下ACID、事务隔离级别、CAP、BASE、2PC、3PC等基本理论,然后再详细讲解分布式事务的解决方案:XA、AT、TCC、Saga、本地消息表、消息事务、最大努力通知等。


越说越迷糊的CAP

在上一篇《Paxos、Raft不是一致性算法/协议?》中,皮皮简单地聊了聊一致性(Consistency)与共识(Consensus)的区别。本文再来继续简单聊一聊CAP。不管大家有没有深入了解过分布式系统,相信对CAP应该还是有个比较熟悉的印象。

CAP定理起源于加州大学柏克莱分校(University of California, Berkeley)的计算机科学家埃里克·布鲁尔(Eric Brewer)在2000年的分布式计算原理研讨会(PODC)上提出的一个猜想。在2002年,麻省理工学院(MIT)的赛斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)发表了布鲁尔猜想的证明,使之成为一个定理。CAP定理也称为布鲁尔定理(Brewer’s theorem)。


Paxos、Raft不是一致性算法?——Consistency不是Consensus

作为互联网中的一员,我们时常沉浸在“分布式”的氛围当中——高可用、高可靠、高性能等等词汇随处可见,CAP、BASE、2PC、Paxos、Raft等等名词也能信手捏来。不过,有些词在我们“并不严谨”的传播中逐渐被误用了,或者说含糊不清了。今天,我们来简单聊聊“Consistency”这个词,即一致性。

Paxos、Raft等通常被误称为“一致性算法”。但是“一致性(Consistency)”和“共识(Consensus)”并不是同一个概念。Paxos、Raft等其实都是共识(Consensus)算法。


分布式文件系统设计,该从哪些方面考虑?

分布式文件系统是分布式领域的一个基础应用,其中最著名的毫无疑问是 HDFS/GFS。如今该领域已经趋向于成熟,但了解它的设计要点和思想,对我们将来面临类似场景 / 问题时,具有借鉴意义。并且,分布式文件系统并非只有 HDFS/GFS 这一种形态,在它之外,还有其他形态各异、各有千秋的产品形态,对它们的了解,也对扩展我们的视野有所俾益。本文试图分析和思考,在分布式文件系统领域,我们要解决哪些问题、有些什么样的方案、以及各自的选择依据。

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×