基于数据库复制的技术架构讨论
2016-06-07 14:01
288 查看
背景
这里的数据库复制指的是将 主 业务数据库实例上的库通过同步机制(比如 MySQL binlog)准实时(比如最大延迟为 3s)复制到其他数据库实例上,这些实例库只做查询,不做数据写入。这套架构设计的主要优势:
各业务应用能够方便地在自己的 DB 实例上进行业务查询,比如通过 join 主业务库
在不明确业务边界、没有梳理好业务对应技术模块时可以最小成本进行变更或扩展
实现读写分离,提升性能
一些问题
实际在实施过程中主要遇到两个问题:不可能实时完成数据同步,将造成业务上面的不一致,比如调用主库服务更新数据后,在业务库上不能实时查询到已更新的数据
很难保证高可用(在使用阿里 DTS 时出现过多次问题,自己做主从可能会好一些)
为了满足业务发展,复制库的数量会逐步增多(比如新开一个产品可能就需要多复制一套库),以上两个问题可能会导致严重的故障, [CAP] 不能兼得。
服务化
基于数据库复制架构的核心理念是将数据源暴露给应用,开发者直接针对数据源进行开发,是一种非常直接的方式。但随着业务的逐渐清晰,一些业务逻辑是可以抽取形成服务并提供给其他应用使用的。这一点业界有着非常多的实践,比如 [SOA] 、 [ESB] 等。这种架构的核心理念是基于 服务 的,应用开发者是面向服务进行开发,而不是面向数据源,用近些年的流行语来说,这是 微服务 。
一个良好的演进路径应该是:
应用内部服务化:各点针对数据源编程 -> 类似工具函数的复用 -> 抽象函数为本地服务 -> 以本地服务组合来完成业务事务
这个路线基本所有应用框架都已会覆盖,即使编程语言不同,架构范式基本一致,都是 MVC + DB 本地事务
应用分布式服务化:将应用进行拆分 -> 形成服务分类(业务/技术)和分级(1/2/3) -> 通过网络协议暴露各个服务 -> 解决分布式事务问题 -> 以分布式服务组合完成业务事务
这个路线会随着编程语言不同而略有不同,架构范式基本都是注册中心 + 服务链路 RPC + 分布式事务,目前 Java 系可用的框架比较多,比如 [Dubbo] 及其衍生框架,需要考虑异构技术之间的整合
数据库方面基本路线是随着服务的拆分而拆分,主要难点在于消除 join,或者只在某些不可避免的场景少量使用。
以上都是我瞎扯的,实在编不下去了,欢迎大家分享真正的经验 :-p
相关文章推荐
- 基于数据库复制的技术架构讨论
- SQL中改变列的数据类型
- Sqlserver2005日志文件太大如何减小
- Centos 7 Redis 3.2.0
- 地理数据库需要什么类型的维护?
- 地理数据库 (Geodatabase) 版本管理
- powershell mysql转json(Utf8NoBom)
- VS2012+EF6+Mysql配置心路历程
- [Err] ORA-00979: 不是 GROUP BY 表达式
- 解决MySql安装出错问题的有效方法
- Oracle osw启动参数一大坑说明(Redhat Linux 6.5 x64)
- SQL分离附加数据库
- 数据类型
- BEA的Oracle JDBC驱动与Oracle的JDBC驱动区别如此之大,请谨慎选择、使用和调整!
- MongoDB基本命令用
- Python调用MongoDB使用心得
- SQl之PreparedStatement与Statement的区别---------( 二 )
- mysql5.6 主从配置
- SQl之PreparedStatement用法---------( 一 )
- SQL中Group By的使用