阿里运维张瑞聊Oracle和MySQL怎么一起撑起业务需求的事儿

开始）

这事儿得从阿里早年的业务特点说起,那时候，阿里很多核心系统，比如淘宝的交易、账务这些，用的都是Oracle数据库，Oracle确实厉害，用张瑞的话说，它像个重装坦克”，特别稳定、功能强大，尤其是在处理复杂的交易、保证数据强一致性方面，非常可靠，那时候业务要快速发展，求稳是第一位的，所以选择Oracle是很自然的事情。

随着业务量爆炸式增长,尤其是像双十一这种大促活动的出现，问题就来了，Oracle虽然好，但有两个大麻烦：一是太贵了，硬件成本（高端的小型机、存储设备）和软件许可费用都非常高，业务规模越大，这个成本压力就越吓人；二是扩展性有瓶颈，简单说就是“竖着长”可以（通过提升单机性能），但很难“横着长”（通过增加普通服务器来分摊压力），眼看交易量一年比一年高，全靠Oracle“硬扛”下去，成本和技术风险都会大到无法承受。

这时候,阿里就开始琢磨怎么把一些业务迁移到开源的MySQL上，MySQL的特点是“轻快”，像一群灵活的步兵，它成本低，可以用普通的PC服务器部署，很容易实现水平扩展，就是弄很多台MySQL机器组成一个集群，共同分担压力，但MySQL当时在复杂查询、事务一致性等方面，确实不如Oracle那么“强悍”。

那怎么办呢？总不能把所有业务都一刀切地从一个数据库搬到另一个数据库吧？那样风险太大了，张瑞他们采取的策略不是“替换”，而是“协同作战”，让Oracle和MySQL各自干自己最擅长的事儿，这个思路的核心，用他们的话讲叫“去IOE”，但这个过程不是一蹴而就的，而是非常精细的“拆”与“合”。

具体是怎么操作的呢？一个大原则是：“核心”用Oracle，“外围”和“海量数据”用MySQL。

他们对业务进行了非常细致的梳理和拆分,像“下单”、“支付”这种需要瞬间完成、一分钱都不能错的核心交易环节，暂时还是让Oracle这个“重装坦克”来保障，因为它的事务强一致性能力能确保万无一失。

他们把那些数据量特别大、但一致性要求可以稍微放宽一些的业务，或者是一些查询非常频繁的“读多写少”的业务，逐步迁移到MySQL集群上，最典型的例子就是“用户评价”、“商品浏览记录”、“日志数据”等，这些数据可能每秒产生几十万上百万条，如果存在Oracle里，成本高得吓人，而且Oracle也未必擅长处理这种海量的插入和简单查询，但MySQL集群处理起来就非常合适，通过分库分表，可以把数据分散到上百台甚至上千台便宜的服务器上，轻松扛住压力。

这就形成了一个很有意思的架构：用户下一个订单，核心的交易创建和扣减库存在Oracle中完成，保证准确；这个订单生成后，相关的信息会被异步地同步到MySQL集群里，用于后续的订单查询、生成报表、用户行为分析等，这样一来，Oracle只负责最核心、最关键的“写操作”，压力大大减轻；而MySQL则承担了海量的“读操作”和部分非核心的“写操作”。

张瑞还提到一个关键点,就是这种“混搭”架构对技术团队的要求更高了，他们需要开发很多中间件和工具，来保证数据在Oracle和MySQL之间可靠地同步，还要处理好分布式事务的问题，确保即便是在两个不同的数据库系统里，业务逻辑最终也是一致的，这背后是大量的技术攻坚和运维经验的积累。

总结起来,阿里并不是简单粗暴地用MySQL取代了Oracle，而是在那个特定的发展阶段，找到了一条务实的道路：让Oracle坚守数据一致性的“堡垒”，让MySQL去扩展业务规模的“疆域”，通过这种分工协作，既利用了Oracle的稳定可靠，又享受了MySQL的扩展性和低成本，平稳地支撑了业务在那段时期的极速膨胀，这个过程也体现了阿里技术演进的一个核心思想：技术选型没有绝对的好与坏，最重要的是适合业务当前和未来一段时间的需求，并能平滑地应对变化。 结束）