《分布式系统的事务处理》笔记(一)——RDBMS事务的难题-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

《分布式系统的事务处理》笔记(一)——RDBMS事务的难题

简介:

本文摘录自《分布式系统的事务处理》。

单机服务器的不足

云技术是近期比较热门的话题,它的基础就是分布式集群技术。传统的单机服务器会有两个问题:

  1. 一台服务器的性能不足,遭遇性能瓶颈
  2. 单机服务器的宕机风险

当然,现在的单服务器内也是应用了多处理器等技术,也有宕机的处理。《smp,numa和mpp体系结构总结

数据的保护

随着业务的发展,扩展服务器别无选择。我们加入更多机器来分担性能以及故障。对于故障,保护数据总是第一要务。通常会有两种手段来扩展数据服务:

  1. 数据分区:数据分块放在不同服务器上。(应该是加快读)
  2. 数据镜像:多个数据备份

对于数据分区,个人估计是为了加快写速(对照RAID0),单台服务器故障会引起部分数据丢失(很可能造成整个数据损坏)。高可用性只能通过数据镜像——数据冗余来保证(工业界认为比较安全的备份数是三份)。加入更多机器会使得数据一致性变得复杂

经典的Use Case:

“A帐号向B帐号汇钱”来说明一下,熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作:

  1. 从A帐号中把余额读出来。
  2. 对A帐号做减法操作。
  3. 把结果写回A帐号中。
  4. 从B帐号中把余额读出来。
  5. 对B帐号做加法操作。
  6. 把结果写回B帐号中。

这六个步骤是一个事务,要么全部做完,要么就都不做(都不成功)。不然A钱扣了,没转进B去就亏了(银行肯定先扣钱,呵呵)。

所以,这个事务执行时,必须要锁定AB账户的读和写。RDBMS会造成比较复杂的问题:

  1. 数据分区:AB账号不在同一个服务器上,需要夸机器的事务处理。如果中途失败,需要回滚
  2. 数据镜像:事务操作在同一台机器,但别的机器上可能会有不一致的数据

事务处理除了考虑性能,还有可用性。在服务器出错时数据不会丢失,服务会由别的服务器代替。目前来看,上万台服务器,每天都可能有几台服务器宕机

  • 容灾:数据不丢,失效备援
  • 数据一致性:事务处理
  • 性能:吞吐量,响应时间

数据副本是分布式系统解决数据丢失异常唯一手段数据分区更多为了性能

  • 为了高可用性,数据多备份
  • 多备份会引起一致性问题
  • 一致性问题会影响性能

这就是软件开发,按下了葫芦起了瓢。(说得好)

一致性模型

简单分为三种类型:

  1. Weak弱一致性可以不一致
  2. Eventually 最终一致性:某个时间窗口之后保证最终一致。限期一致
  3. Strong 强一致性:新数据写入后,必须保证所有副本都是一致的,时刻一致

Weak和Eventually是异步冗余。Strong一般是同步冗余

异步冗余更好的性能,但带来更复杂的控制

同步冗余简单的实现,但意味着性能下降

 

转载请注明:旅途@KryptosX » 《分布式系统的事务处理》笔记(一)——RDBMS事务的难题

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: