《分布式系统的事务处理》笔记（一）——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事务的难题