为什么curator不使用连接池来管理连接答案

【问题标题】：why curator does not use the connection pool to manager the connection为什么curator不使用连接池来管理连接
【发布时间】：2019-11-03 21:06:26
【问题描述】：

我是新人使用curator，我发现一些框架使用连接池来管理连接，比如jdbc，redis。但是我在curator中没有找到连接池。为什么curator不提供连接池来减少每个连接消耗的资源。

【问题讨论】：

你指的是什么连接池？另外，连接池有什么好处？
谢谢你的回复。我的意思是当我们需要100个连接时，curator会创建100个连接，为什么不使用一个包含10个连接的连接池（仅举例），当我需要时，我可以从池中取出，用完再放回池中。这样，我们可以在建立连接时节省一些资源。我只是一个新手，这只是我的一些想法。
Curator 不会创建 100 个连接。每个 CuratorFramework 实例只有 1 个连接，因为只需要 1 个连接。我真的不知道你指的是什么。

标签： apache-zookeeper apache-curator

【解决方案1】：

一个 CuratorFramework 实例包装了一个 ZooKeeper 实例，该实例又维护与 ZooKeeper 节点的连接。

ZooKeeper 提供以下订购保证：

Linearizable writes：所有更新 ZooKeeper 状态的请求都是可序列化的，并且尊重优先级；

FIFO 客户端顺序：来自给定客户端的所有请求都按照客户端发送的顺序执行。

假设有两个CuratorFramework实例A和B的连接池。我们向A发出写请求以创建znode/a并将A返回到连接池。然后我们从连接池中得到另一个CuratorFramework 实例。这次我们得到了 B。我们向 B 发出读取请求以读取 /a。有可能我们无法获得/a，因为不能保证读请求会放在写请求之后。只有相同的连接，才能保证顺序。所以连接池有这个数据不一致的问题。

另一个问题是临时 znode。使用一个 CuratorFramework 实例创建的临时 znode 仅对其自身可见。使用连接池，我们只能在使用创建它们的同一 CuratorFramework 实例时读取临时 znode。

【讨论】：