Azure Cosmos DB一个非常重要的特性就是全球分布,想象一下你有多个应用在全球分布式,用户也分布式在全球,例如你有新产品上市,你在美国总部更新了你的产品目录,SKU,价格,你希望全球各地的用户就可以快速本地访问,保证延迟和性能,保证用户体验,你该如何做昵?如果以传统的方式来做,在CAP定律之下,这是一个非常复杂的系统,而且成本会非常的高,而在Azure Cosmos DB,你只需要点几下鼠标即可,当然全球复制的区域配置也可以通过命令行,编程接口等动态调整。
Azure Cosmos DB全球分布配置及管理
- 打开Azure的管理界面,进入到之前我们创建的Cosmos DB主界面,选择"全局复制数据"菜单,我们可以看到目前。我们创建的MongoDB数据库只在北方地区China North进行读写,没有配置其他复制或者读取区域,但我们可以看到有另外一个可选区域China East可以配置:
注意事项:
地域隔离限制:由于不同国家的法律法规限制,比如中国和德国等,数据复制的区域只限制在物理区域内,比如中国只能选择北京,上海互为复制地区,而不能将数据复制到海外Azure的CosmosDB,所以在世纪互联运营的Azure上你会看到可选区域只有China North和China East,如果是全球的Azure,则可以选择多达30+区域。
读写优化:无论你在哪个区域,当你来访问CosmosDB数据库时,Cosmos DB会就近提供服务来保证读取的延迟和性能
- 那么我们如何确认当前连接的主机时master还是replica昵?我们可以使用MongoDB的原生工具进行查看,需要安装mongodb的客户端,在本次测试中我用的是Ubuntu,安装命令如下:
sudo apt install mongodb-clients
连接到MongoDB的命令如下,username和password和之前使用程序连接一致
mongo -u mycosmos
-p PASSWORD
--host mycosmos.documents.azure.cn
--port 10255
--ssl
- 连接到CosmosDB之后,可以使用show dbs来查看当前的数据库,然后使用db.isMaster()来检查当前数据库的状态,从结果我们可以非常明确的看到,当前连接的服务器是master,主机名称是bjbprdddc03-docdb-1.documents.azure.cn,端口是10255,所在地区是China North:
- 接下来我们配置Azure的全球复制,进入到Azure的主界面,选择"全局复制"菜单,勾选"China East"区域,选择保存即可,配置非常简单,当然也可以使用命令行和SDK来动态配置,需要的话可以查阅相关文档;配置完成之后,可以看到新增加了一个China East只读区域:
- 我们如何检查和访问另外一个复制站点?如何确认另外一个站点已经开始工作昵?首我们先使用命令db.isMaster(), 查看一下当前状态,我们可以卡电脑,全球复制配置完成后,除了之前北京的主机之外,又多了一个上海的主机,即我们配置的复制站点,也可以看到当前连接的是master主机,即北京数据库:
"sh3prdddc06-docdb-1.documents.azure.cn:10255",
"bjbprdddc03-docdb-1.documents.azure.cn:10255"
- 我们使用备份数据库的地址sh3prdddc06-docdb-1.documents.azure.cn进行连接, 连接成功后,提示符会显示"SECONDARY",意思当前连接是是一个副本复制服务器,当前的参数也可以看到:
mongo -u mycosmos
-p PASSWORD
--host sh3prdddc06-docdb-1.documents.azure.cn
--port 10255
--ssl
"ismaster" : false, 代表当前连接的是一个replica
Master服务器和当前服务器显示:
"primary" : "bjbprdddc03-docdb-1.documents.azure.cn:10255",
"me" : "sh3prdddc06-docdb-1.documents.azure.cn:10255"
- 查询当前副本服务的数据,已经和主服务器同步一致:
需要注意:
- Cosmos DB的全球分布数据库的特性,使得连接主机mycosmos.documents.azure.cn访问数据库的时候,Cosmos DB会自动路由你到最近的区域提供服务,从这一点上你可以把前端入口mycosmos.documents.azure.cn的功能看作类似于Traffic manager的功能,后端自动负载和路由
- 当你连接mycosmos.documents.azure.cn:10255写入的时候,写请求会从你当前的区域路由到master主库,然后根据你选择的一致性级别进行同步,一致性级别和延迟之间具有关联,一般来说,一致性级别越高(比如强一致性),延迟会越高,将在后面的文章详细讨论
- 每一个新添加的复制区域,会根据和主库一样的RU大小和存储大小计费
- 如果你的数据库里面有多个collection,你可以针对每个collection来设置他的吞吐量,但目前只能使用命令行来设置,例如Azure CLI 2.0的设置方式如下:
# Scale throughput
az cosmosdb collection update
--collection-name $collectionName
--name $name
--db-name $databaseName
--resource-group $resourceGroupName
--throughput $newThroughput
8. 简单的测试一下异地复制功能,我们使用Spring-MongoDB在主数据库协议两条数据,然后再复制数据库查询:
Bike bike1= new Bike("bj008", "Gen2", "Beijing", "China");
bike1.setLatitude(23.34);
bike1.setLongitude(24.76);
bike1.setUpdateDate(new Date());
Bike bike2= new Bike("sh008", "Gen3", "Shanghai", "China");
bike2.setLatitude(26.34);
bike2.setLongitude(27.76);
bike2.setUpdateDate(new Date());
然后我们在上海复制数据库进行查询,几乎是毫秒级就复制过来,在上海数据中心可以看到复制的数据:
- 最后再简单介绍一下Cosmos DB的计费,基本的费用包括存储费用和保留RU的费用,如果启用了全球复制,除了每个地区的存储费用和RU费用,还会有网络传输费用,按照Azure标准网络费率计算:
存储费用比较简单,按照自己的数据量来预估即可,那么RU费用怎么计算昵? Azure中定义单个请求单位RU用于表示读取(通过自链接或 ID)一个包含 10 个唯一属性值(系统属性除外)的 1 KB 项所需的处理容量。而1K数据的写入则需要5个RU,一个计算RU的例子如下:
而为了用户可以更方便的计算你所需要的RU,微软专门推出了一个用于计算RU的计算器,你可以上传你的例子json文件,请求的需求,计算器会帮你计算需要的RU,非常方便:
https://www.documentdb.com/capacityplanner
可以看到,支持多模型的分布式数据库Azure Cosmos DB,使用和配置都非常方便,可以满足不同业务场景下分布式数据访问的需求,目前广泛应用于车联网,电子商务,游戏等等需要大规模分布式访问的应用,相对于其他类似产品,其全面的SLA的保障,较低的拥有成本,多种一致性级别定义,性能和延迟保障,多种模型支持,都对新型应用非常具有吸引力,大家可以尝试一下~