阿里云RDS金融数据库(三节点版)

背景

土豆哪里去挖？

土豆郊区去挖。

一挖一麻袋？

一挖一麻袋。

挖掘机不仅是城市建设的必备法宝，居然也是挖土豆利器。

但是科技行业一定不喜欢挖掘机，经常会听说xx互联网软件故障提到“光纤被挖断”，导致XX机房故障几小时。

这和数据库有什么关系呢？当然有，一些企业在业务层面可能做到了多机房，多活的架构，但数据库并没有做到0丢失的多机房或多活部署，如果数据库所在机房网络故障，那么对于这些业务来说照样是灾难性的。

作为阿里云RDS金融数据库(三节点版)系列文章 - 案例篇，接下来将介绍一些用户的案例，用户如何利用阿里云RDS金融数据库(三节点版)，获得最佳业务体验。

异地容灾场景

有了异地容灾，“光纤被挖断”再也不可能成为故障借口了。

对于可用性、可靠性都非常敏感的业务，两节点的高可用架构显然无法满足需求，在追求可靠性（0丢失）时，可用性和性能一定会下降（比如备库故障、主备之间的复制链路问题，都会导致用户事务无法提交）。

两地三中心，或者三地三中心的三节点架构，可以同时满足用户的可用性、可靠性需求。

当任意一个机房遭遇“光纤被挖断”的窘境时，其他机房可以顶上，而且确保0丢失。

养兵千日用兵一时，容灾演练也是企业IT的日常工作之一，对于无状态的业务，相对来说多机房、多活比较好部署，但是数据库是有状态应用，多机房部署难度和成本都高了很多。例如网络带宽、延迟，数据同步机制，切换机制，switchover机制，数据补偿机制等，没有哪个是好做的，没有做好的话可能是灾难性的。有了“阿里云RDS金融数据库(三节点版)”，用户不需要再关心数据库的容灾演练问题，因为内置了这个功能。

金融级核心业务

金融核心库，用户关注的是数据库的可靠性->可用性->稳定性->安全性->性能。在这方面相信老百姓更有体会，因为我们的钱都存在银行呀。

拿转账来打个比方，A有10万余额，B有1万余额，A转给B 1万元，最终变成：A有9万余额，B有2万余额。

任何一个步骤出错都不能出现类似这样的问题：A有9万余额，B有1万余额。A有10万余额，B有2万余额。

如果是单事务、单库操作，涉及到数据库的ACID中的事务原子性、一致性的原理，所以宣称支持ACID的数据库，任何时候都不会出现以上问题。三节点同样遵循了数据库的ACID原则。

如果操作不是单个事务，或者涉及到多库操作，那么业务系统可以使用数据库的两阶段事务来保证全局一致性。三节点同样支持数据库的两阶段事务。

如果是跨业务系统的转账，那么需要通过业务层的协议结合两阶段事务来保证全局的一致性。三节点同样支持数据库的两阶段事务。

对业务系统来说，三节点具备单节点的所有功能，同时提升了数据库的可靠性，可用性。任何一个节点故障，不影响业务的正常运行，也不会丢任何数据。

除此之外，阿里云RDS也非常的关注细节，为了让用户体验更好，阿里云的proxy也做了极大的用户体验工作，包括数据库切换时的零感知。

专业的数据库团队，对数据库的深刻理解转换为产品，为用户提供更好的服务，如果你想了解数据库切换时的要素，可以参考阅读这篇文档（文章以PostgreSQL数据库为出发点，讲解了数据库平滑切换的要素）：

《数据库平滑switchover的要素》

企业的核心数据库，比如用户认证系统、用户账户系统、企业ERP系统等。对数据库的要求与金融核心类似，它们同样有容灾的需求，有容灾演练的需求，有多机房部署的需求，有SOX审计的需求。

阿里云RDS金融数据库(三节点版)为金融业务、企业核心数据库保驾护航。

小结

阿里云RDS金融数据库(三节点版)，围绕“可靠性、可用性”为核心设计，为金融业务、企业核心数据库保驾护航。

除了“可靠性、可用性”，阿里云RDS金融数据库(三节点版)还继承了RDS内核多年来的丰富经验和代码沉淀，相比社区版本，有着性能、功能方面的诸多优势。同时阿里云RDS团队也是开源数据库社区的积极贡献者。

欢迎金融业务、企业核心数据库选用。

系列文章

《阿里云RDS金融数据库(三节点版) - 背景篇》

《阿里云RDS金融数据库(三节点版) - 理论篇》

《阿里云RDS金融数据库(三节点版) - 性能篇》

《阿里云RDS金融数据库(三节点版) - 案例篇》