使用Spring-MongoDB访问全球分布数据库Cosmos DB(3)

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的保障，较低的拥有成本，多种一致性级别定义，性能和延迟保障，多种模型支持，都对新型应用非常具有吸引力，大家可以尝试一下~