CouchDB集群与变更通知技术解析

# CouchDB集群与变更通知技术解析 ## 1. 一致性哈希与集群基础 一致性哈希是一种简单的方法，可确保始终能找到保存的文档，同时在各个分区之间均匀平衡存储负载。由于哈希函数简单（基于CRC32），用户可自由实现自己的HTTP中介或客户端，将请求解析到数据的正确物理位置。 ### 1.1 冗余存储 一致性哈希解决了如何将单个逻辑数据库均匀拆分为一组分区，并将这些分区分布到多个服务器的问题。但它未解决如何确保存储的数据免受硬件或软件故障导致的数据丢失问题。为保证数据安全，至少需要两份数据副本，最好存放在不同地理位置。 CouchDB复制功能使维护热故障转移冗余从节点或负载均衡的多主数据库变得相对轻松。重要的是要明白，维护冗余副本与确保集群为特定文档ID始终选择相同分区这一更难的任务是相互独立的。为保障数据安全，建议对所有数据至少保留两到三份副本。若封装了冗余性，集群的高层可以将每个分区视为一个单一单元，让逻辑分区自行管理冗余和故障转移。 ### 1.2 冗余代理 为避免硬件故障导致数据丢失，需要运行多个代理节点实例，以防止代理节点崩溃使集群部分不可用。通过运行冗余代理实例并进行负载均衡，可提高集群吞吐量和可靠性。 ### 1.3 视图合并 一致性哈希将文档放在合适的节点上，但文档仍可发出任意键。增量式MapReduce的要点是将函数带到数据所在处，因此不应重新分发发出的键。相反，通过HTTP代理将查询发送到CouchDB节点，并使用Twisted Python Smartproxy合并结果。 Smartproxy将每个视图请求发送到每个节点，在将响应返回给客户端之前需要合并这些响应。幸运的是，此操作不消耗大量资源，因为无论返回多少行，合并都可以在恒定的内存空间中完成。Smartproxy从每个集群节点接收第一行并进行比较，根据CouchDB的排序规则按行键对节点进行排序，然后从排序后的第一个节点中取出顶部行并返回给客户端。若客户端设置了限制，Smartproxy必须提前结束响应，丢弃节点发送的任何额外行。 这种布局简单且松耦合，有助于理解拓扑结构和诊断故障。目前正在进行将此行为迁移到Erlang的工作，这将使管理动态集群成为可能，并将集群控制集成到CouchDB运行时中。 ### 1.4 集群扩展 在Web规模使用CouchDB可能需要能够动态扩展的CouchDB集群。不断发展的网站必须持续增加存储容量，因此需要一种在不关闭集群的情况下增加其规模的策略。某些工作负载可能导致数据大小临时增长，此时还需要一种在不中断服务的情况下缩小集群的流程。 #### 1.4.1 过度分片 过度分片是一种将集群进行分区，使每个物理机器上有多个分片的技术。将分区从一台机器移动到另一台机器比将其拆分为更小的分区更简单，因为代理使用的集群配置映射只需更改以指向新位置的分片，而无需添加新的逻辑分片。而且，移动分区比拆分分区消耗的资源更少。 确定过度分片的程度取决于应用程序和部署情况，但有一些因素会影响决策。若分片数量合适，可使集群实现最佳增长。视图合并所需的内存空间和网络资源，以及从文档ID映射到分区所需的资源，会随着给定代理下的分区数量线性增长。因此，需要限制每个代理管理的分区数量，但又不能对集群大小设置上限。解决方案是使用代理树，根代理将分区分配给一些中间代理，中间代理再代理到数据库节点。 在决定每个代理应管理多少分区时，需要考虑以下因素： | 因素 | 说明 | | ---- | ---- | | 单个服务器节点的可用存储 | 影响可存储的数据量 | | 数据的预计增长率 | 决定集群扩展的频率 | | 代理可用的网络和内存资源 | 限制代理可处理的分区数量 | | 对集群请求可接受的延迟 | 影响用户体验 | 假设每个代理保守地管理64个分片，每个节点有1 TB的数据存储（包括压缩空间，这些节点大约需要2 TB的驱动器空间），在单个代理位于CouchDB数据节点之前，最多可存储64 TB的数据（根据系统所需的冗余级别，可能需要128或192个服务器节点），之后需要增加分区数量。 通过用另一个代理替换数据库节点，并将64个分区中的每个分区重新划分为另外64个分区，可得到4096个分区，树的深度为2。就像初始系统可以在几个节点上容纳64个分区一样，过渡到两层树不需要数千台机器。若假设每个代理必须在自己的节点上运行，且最初数据库节点可以容纳16个分区，那么需要65个代理和256个数据库机器（不包括冗余因素，通常冗余因素会使集群大小增加两到三倍）。要启动一个可以从64 TB平稳增长到4 PB的集群，可以从大约600到1000个服务器节点开始，随着数据量增长并将分区移动到其他机器时添加新节点。 #### 1.4.2 分区操作 集群扩展涉及两个主要过程：将分区从拥挤的节点移动到空节点，以及将大分区拆分为多个子分区。移动分区相对简单，因此在可能的情况下应优先使用，只有当分区变得足够大，每个数据库服务器只能容纳一两个分区时，才运行更消耗资源的重新分区过程。 - **移动分区**：每个分