Day 27- 鬼斧神工 ：Serverless 电商 - 实战 - 後端开发 (三）资料库存取

图片来源：Azure

高负载

在Ecommerce的状态下我们最怕的便是在订单处理跟库存的部分（在购物车以前端处理的状况下），高负载代表的是在同一个时间点会有非常多的存取动作，而每一次的存取需要保证资料一致性，我们会需要使用的Azure CosmosDB的Change Feed来处理每一次的产品数量变更都是保证要被按照顺序读写的。

Change Feed

在Azure CosmosDB 无服务器的说明下。

1. 无服务器帐户只能在单一 Azure 区域中执行。 您无法在建立其他 Azure 区域之後，将其新增至无服务器帐户。
2. 不可能在无服务器帐户上启用 Synapse 连结预览功能 。
3. 无服务器容器上不需要布建输送量，因此下列陈述适用：
4. 您无法在建立无服务器容器时传递任何输送量，因此会传回错误。
5. 您无法读取或更新无服务器容器的输送量，因此会传回错误。
6. 您无法在无服务器帐户中建立共用输送量资料库，而且这麽做会传回错误。
7. 无服务器容器可提供每秒5000要求单位的最大输送量 burstability。
8. 无服务器容器最多可以储存 50 GB 的资料和索引。

所以我们必须去注意到限制问题，一个容器可以提供到5000每秒要求，而在我们一般商家的抢购情况下已经足够使用，当我们需要使用到超过5000每秒要求次数以上时，就要考虑到分区多容器的问题，但不在我们这次文章的讨论范围。

Azure Cosmos DB 中的变更摘要支援是靠接听 Azure Cosmos 容器的任何变更而运作。 然後变更摘要会输出已排序的文件清单，这些文件已依其修改的顺序变更过。 变更会保存，可进行非同步累加处理，而输出可配送给一或多个取用者进行平行处理。

我们任何资料读写预设都会有变更摘要的创立，我们透过变更摘要的功能，可以提前在排队还没写入之前的资料作出计算的动作。

本日小结

今天带大家走完後端最後资料库流程之後，接下来便是将产品完成上线！！我们有邀请到神秘贵宾来帮大家做一次流量负载测试！！