目录
cluster 模式
数据请求处理流程
总流程
逻辑channel 到物理channel
数据维护流程
cluster 模式
上一篇其实已经说过 standalone 模式，其实集群模式大同小异，只是在不同机子间使用Kafka或者其他消息中间件保证数据及逻辑的一致性。
Log Broker，如Pulsar这样的系统，是专门设计来处理和管理日志数据的中间件。它主要关注于最近发生的变更操作的日志记录，提供日志的流式处理、发布（publish）和订阅（subscribe）服务。有几个关键特性：
- 日志管理：
- Log Broker负责收集、存储和管理来自不同数据源（如数据库、消息队列、应用程序等）的日志数据。这些数据通常是关于系统状态变更的记录，比如用户注册、订单创建、数据更新等。
- 它能够处理大量的日志数据，支持高并发写入，确保数据的一致性和完整性。
- 流式输出：
- Log Broker提供流式处理的能力，允许数据以近乎实时的方式被处理和分析。这意味着数据一旦被写入，就可以立即被消费或进一步处理，无需等待全部数据收集完成。
- 流式处理使得Log Broker非常适合用于实时数据分析、监控和告警等场景。
- 发布-订阅服务：
- Log Broker支持发布-订阅模型，允许生产者（producers）发布消息到指定的主题（topics），而消费者（consumers）可以订阅这些主题以接收消息。
- 这种模型提供了高度的灵活性和可扩展性，因为生产者和消费者可以独立地扩展，而不会影响彼此。
- 订阅者可以根据需要选择不同的订阅模式，如独占订阅（exclusive subscription）、共享订阅（shared subscription）或故障转移订阅（failover subscription），以满足不同的业务需求。
数据请求处理流程
总流程
在Milvus中，每个Collection可以指定多个分片Shards，每个分片对应一个虚拟通道（vchannel）。这种设计允许系统高效地处理数据，并通过分片来提高并发性和可扩展性。嗯句前面讲的，Milvus在日志代理（Log Broker）中将每个vchannel映射到一个物理通道（pchannel），这样做是为了在底层实现数据的物理存储和管理。
对于插入（Insert）和删除（Delete）等数据修改语言（DML）请求，Milvus采用了基于主键哈希值的分片路由策略。这意味着当一个新的DML请求到达时，系统会计算该请求主键的哈希值，并根据这个哈希值将其路由到相应的分片上。
由于Milvus不支持复杂的事务（Transactions），DML请求的验证被提前到了代理层（Proxy）。代理层会从时间戳服务（TSO，Timestamp Oracle）请求每个DML操作的时间戳。TSO是与根协调器（Root Coordinator）共置的定时模块，负责生成全局一致的时间戳。通过为每个DML请求分配一个时间戳，Milvus能够确定数据处理请求的顺序，即使在高并发场景下也能保证数据的一致性。
此外，为了提高整体吞吐量和避免中央节点过载，代理层会批量地从数据协调器（Data Coordinator）检索信息，包括实体的段（Segments）和主键。这种批量处理的方式减少了与数据协调器的交互次数，从而提高了系统的效率。
总的来说，Milvus通过分片、虚拟通道与物理通道的映射、基于主键哈希的路由策略、时间戳服务以及批量处理等技术手段，实现了高效、可扩展且一致的数据处理能力
逻辑channel 到物理channel
vchannels（虚拟通道）在Milvus的底层日志代理（Log Broker）节点中被维护。每个vchannel在物理上是不可分割的，并且可以被任何节点使用，但同一时间内只能被一个节点使用。这样的设计有助于管理数据流的分配，并确保数据的完整性和一致性。
当数据摄入率（ingestion rate）达到瓶颈时，需要考虑两个主要因素来优化系统性能：
- 日志代理节点的负载情况：
- 检查日志代理节点是否过载。如果节点负载过高，可能是因为单个节点处理的数据量超过了其处理能力。在这种情况下，可以考虑增加日志代理节点的数量来进行水平扩展（scaling out）。通过增加节点，可以将数据处理的负载分散到更多的节点上，从而提高整体的数据处理能力。
- 分片的数量：
- 另一个关键因素是检查是否有足够的分片来确保每个节点的负载均衡。如果分片数量不足，可能会导致某些节点承载了过多的数据处理任务，而其他节点则相对空闲。为了解决这个问题，可以增加集合中的分片数量，以便更均匀地分配数据到各个节点上。这样做可以提高系统的并行处理能力，并减少因单个节点过载而导致的性能瓶颈。
数据维护流程
日志序列写入过程中涉及的四个关键步骤：代理（Proxy）、日志代理（Log Broker）、数据节点（Data Node）和对象存储（Object Storage）。这个过程包括四个主要任务，这些任务被解耦以确保每个任务都由其对应的节点类型处理，从而提高了系统的灵活性和可扩展性。
- DML请求验证：
- 这一任务由代理节点（Proxy）负责。由于Milvus不支持复杂的事务，DML请求的验证被提前到了代理层。代理会检查请求的有效性，并为其请求时间戳服务（TSO）以获取全局一致的时间戳。时间戳用于确定数据请求的处理顺序，确保数据的一致性和并发控制。
- 日志序列的发布-订阅：
- 日志代理节点（Log Broker）负责处理日志序列的发布和订阅。当DML请求通过验证后，代理会将请求转发给日志代理节点。日志代理节点将请求转换成日志序列，并管理这些日志序列的发布和订阅。这样，数据节点可以订阅它们感兴趣的日志序列，以便进行后续的数据处理。
- 应该说从log broker 中发布的订阅消息有很多种，其中 data node 关心的只是DML 与 DDL 相关的，因为这里主要是想描述数据请求，所以其他的就没有绘制。
- 从流式日志到日志快照的转换：
- 数据节点（Data Node）负责将从日志代理接收到的流式日志转换成日志快照。日志快照是数据在特定时间点的静态表示，它们被用于数据的持久化和恢复。通过转换流式日志为日志快照，数据节点可以更有效地管理和访问数据。
- 日志快照的持久化：
- 最后，日志快照被持久化到对象存储（Object Storage）中。对象存储是一种高可靠、可扩展的存储解决方案，适用于存储大量数据。通过将日志快照存储在对象存储中，Milvus可以确保数据的长期保存和可访问性，即使在系统故障或灾难恢复时也能快速恢复数据。
- 需要注意 一个collection实际可以有多个segments 进行存储，查找collection的过程，其实是定位返回多个segments的过程。
- 这里解释下索引：Milvus 是一个为向量数据设计的分布式向量数据库，它支持对向量字段、标量字段和主键字段建立索引。这种索引机制在数据处理和查询优化方面起着关键作用，特别是在处理大规模、高维数据时。
)
