且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

为原子数据结构配置和使用Geode区域和锁

更新时间:2023-01-07 20:40:19

DistributedLock和RegionDistributedLock的Region API仅支持具有全局范围的Region.这些DistributedLocks仅在群集内的DistributedLockService名称(区域的完整路径名称)中具有锁定范围.例如,如果服务器上存在全局区域,则该区域的DistributedLocks只能在该服务器或该群集内的其他服务器上使用.

The Region APIs for DistributedLock and RegionDistributedLock only support Regions with Global scope. These DistributedLocks have locking scope within the name of the DistributedLockService (which is the full path name of the Region) only within the cluster. For example, if the Global Region exists on a Server, then the DistributedLocks for that Region can only be used on that Server or on other Servers within that cluster.

缓存客户端最初是分层缓存的一种形式,这意味着一个群集可以作为客户端连接到另一个群集.如果客户端创建了一个实际的全局区域,则该客户端中的DistributedLock将仅在该客户端及其所属的群集中具有作用域.无论如何,分布式锁都不会传播到与该客户端连接的服务器.

Cache Clients were originally a form of hierarchical caching, which means that one cluster could connect to another cluster as a Client. If a Client created an actual Global region, then the DistributedLock within the Client would only have a scope within that Client and the cluster that it belongs to. DistributedLocks do not propagate in anyway to the Servers that such a Client is connected to.

正确的方法是在服务器上存在的全局区域上编写利用DistributedLock API的函数.您可以将这些功能部署到服务器,然后从客户端在服务器上调用它们.

The correct approach would be to write Function(s) that utilize the DistributedLock APIs on Global regions that exist on the Server(s). You would deploy those Functions to the Server and then invoke them on the Server(s) from the Client.

通常,避免使用全局区域,因为每个单独的看跌期权都会在服务器群集中获得一个DistributedLock,这是一个非常昂贵的操作.

In general, use of Global regions is avoided because every individual put acquires a DistributedLock within the Server's cluster, and this is a very expensive operation.

您可以通过在服务器上创建自定义的DistributedLockService,然后使用Functions锁定/解锁需要在该群集中全局同步的代码来对非全局区域执行类似的操作.在这种情况下,区域(对于非全局区域)上的DistributedLock和RegionDistributedLock API将不可用,并且所有锁定都必须​​使用DistributedLockService API在服务器上的功能内完成.

You could do something similar with a non-Global region by creating a custom DistributedLockService on the Servers and then use Functions to lock/unlock around code that you need to be globally synchronized within that cluster. In this case, the DistributedLock and RegionDistributedLock APIs on Region (for the non-Global region) would be unavailable and all locking would have to be done within a Function on the Server using the DistributedLockService API.