我有一个Azure函数，其中一个CosmosDBTrigger处理使用Application Insights监控的消费游戏。受监控的集合在更改源中有500,000个插入。消费计划在几分钟内将实例数量扩展到15，但只有第一个实例能够处理任何更改。
我认为这是因为租约是由第一个实例保存的。我基本上是为14个实例支付费用。
我注意到你应该能够在名为LeaseOptions的CosmosDBTrigger上设置一个属性，但每次尝试时我都会收到错误："Error CS0655 'LeaseOptions' is not a valid named attribute argument because it is not a valid attribute parameter type"
有没有办法扩展CosmosDBTrigger Azure功能，以便10, 20甚至200个实例一次可以处理它？</ p>
答案 0 :(得分：0)
是的，他们确实会在您注意到的情况下在属性上公开4251460 function calls (4151427 primitive calls) in 17.907 seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
50012 7.236 0.000 17.063 0.000 vc3d_traces.py:554(interpolateToVertices)
50012 3.940 0.000 3.940 0.000 {built-in method numpy.core.multiarray.c_einsum}
50012 3.505 0.000 3.505 0.000 {method 'argmin' of 'numpy.ndarray' objects}
100025 0.291 0.000 0.291 0.000 {method 'reduce' of 'numpy.ufunc' objects}
50012 0.289 0.000 17.352 0.000 frame.py:4238(f)
50012 0.223 0.000 0.223 0.000 {method 'searchsorted' of 'numpy.ndarray' objects}
100024 0.191 0.000 0.346 0.000 indexing.py:1815(_convert_key)
1 0.190 0.190 17.905 17.905 {pandas._libs.lib.reduce}
100024 0.159 0.000 0.504 0.000 fromnumeric.py:1730(sum)
100024 0.155 0.000 0.155 0.000 {method 'get_value' of 'pandas._libs.index.IndexEngine' objects}
，但基本的.NET 101规则禁止在编译时将LeaseOptions等自定义复杂类型存储在属性上，因此编译你得到的时间错误。如果您使用的是WebJob，则可以在启动作业主机时手动配置这些设置，但它在Azure功能模型下无法寻址。
那就是说，当你不配置它时，会在幕后创建默认值，如下所示：
ChangeFeedHostOptions所以，考虑到这一点，我希望期望你应该看到单个函数实例保留在整个分区上的最长时间是CheckpointFrequency null
FeedPollDelay 00:00:05
LeaseAcquireInterval 00:00:13
LeaseExpirationInterval 00:01:00
LeasePrefix null
LeaseRenewInterval 00:00:17
，因为每个17s客户端都是假设的检查请求工作的主机数量（在这种情况下是函数实例）并重新平衡它们之间的分区。你没有看到这一点的事实......令人困惑。
免责声明：我没有亲自与13s合作;我只是查看GitHub仓库中标记为CosmosDbChangeTrigger的代码，以确定它们如何在函数扩展的实现中连接所有这些代码。
答案 1 :(得分：0)
正如德鲁所说，LeaseOptions不可配置，但它是coming soon。
对于扩展，触发器将在实例之间的Change Feed Processor Library's design之后开始共享租约以平衡负载。这种情况会在实例出现的几秒钟内发生，并且根据租约数量对分布的实例数量进行限制。由于每个租约最多代表Partition Key Range，因此每个实例将分配1个租约。在分区键范围的数量上添加更多实例不会添加更多的并行处理。
可能是因为算法可以共享租约而更快地创建/销毁实例。
500,000个插入是分布在多个分区中还是都在同一个分区中？功能是否落后于变更，还是处理速度很快？您是否有其他功能（在本地或在Azure中运行）使用相同的租约集合监视相同的集合？
作为旁注，您没有为实例数量付费，而是the amount of executions。