分布式数据库的发展背景以及技术路线

　　在各个行业，随着业务迅猛发展，很多系统都会面临处理高并发、大数据量、超高峰值等多种场景。以金融行业为例，由于互联网的普及，很多互联网业务得到迅猛发展，于是业务系统对应的活跃用户量和数据量也会出现迅猛增长，比如各种场景的在线支付（水费、电费、电话费等各种高频次的小额消费）、网上银行、手机银行等；还有一类场景是具有极高峰值的业务系统，比如 6.18 、双十一、纪念币预约、抢购、秒杀、春节红包、春节火车票等。

　　传统单机数据库的处理能力已经难以支撑这些业务发展，于是，开始探索各种解决各种有效的方案，最常见的就是应用系统通过分库分表进行解决。但是，这种解决方案一方面应用系统需要做大量改造，需要感知数据存储位置，一方面增加了运维的复杂性。于是出现了中间件的方式，如 mycat 等。这种方式实现了数据对应用的透明，但未解决数据库运维的痛点。

　　近年来，互联网、银行业等各行业对处理这类问题逐渐探索形成了自己的思路和解决方案，进一步出现了分布式数据库产品。它们的设计理念和技术路线各不相同，却需要解决一些成熟的分布式数据库产品必然会面临的技术问题。这些问题或者与选择的技术路线有关，或者是做分布式数据库产品必然面临的问题，它们的解决方案和实现机制各不相同，但它们也存在一些共性。因此，本文拟通过对业界分布式数据库产品的研究和探索，介绍一些常见功能的主流方案和技术趋势，以此抛砖引玉，以飨读者。

技术路线
　　目前业界的分布式数据库产品非常多，各有优缺点，本文不会成为某种产品的推荐者或者批判者。按照目前业界现状，技术路线分类如下：

　　基于开源数据库 + 中间件：开源单机数据库（如 mysql 、 postgres 等）已经经过了几十年的应用，产品功能相对稳定，单机数据处理性能也相对比较高。这种方案的优点是可以利用现有单机数据库稳定的产品功能，缺点是中间件的功能实现要受限于单机数据库的功能。比如，中间件要实现一个对数据表列进行加密的功能，如果单机数据库不具备这种功能，中间件只能采用迂回折中的方式。当然，也有足够研究能力的厂商会对单机数据库进行功能优化和改进，比如 mysql 的主从同步机制、热点数据访问等，这对厂商的研发能力和技能储备要求非常高。

　　完全自研：公司组建团队进行产品的自研开发，当然，不可能完全重复造轮子，在实现部分产品功能时可能会采用或者借鉴一些开源软件，比如 TiDB 的数据存储使用了 RocksDB 。数据资产是公司最核心的资源，尤其是银行等金融行业，数据库不能出现重大问题，但数据库的产品功能完善需要经过一段时期的生成环境验证，需要填各种坑。因此，这种方案的优点是天生具有分布式的特性，从设计之初就是针对分布式架构进行设计的，而单机数据库的很多设计当时还未具备分布式的思维理念，缺点是产品的功能需要经过不同场景、不同数据量和不同行业用户的检验、改进和完善，才能具备成熟度，需要团队具备相应的应用场景。自研的数据库产品，有些是采用开源模式，比如 TiDB ，有些是闭源模式，比如 OceanBase 从 1.0 版本 1.0 起已经闭源，网上有些错误的文章都是针对之前它们的开源版本 0.4 进行的研究和讨论。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！