◼ Apache Ignite Свойства продукта

Apache Ignite 2

Partition awareness и affinity routing thin client

Публичные свойства продукта, восстановленные по тестовым свидетельствам.

Partition awareness и affinity routing thin client

Эта страница — публичная реконструкция продуктовой спецификации по исходникам тестов Apache Ignite 2 на ревизии 486a6367610c4c891b729e89373695ef83165345.

Тесты partition awareness описывают, как thin client использует topology и affinity metadata, чтобы направлять поддержанные операции к наиболее подходящему известному server connection.

Пользовательские гарантии

Трассируемые требования

После имени теста указывается только негативный или неоднозначный статус, например status=failed, status=flaky, status=ignored или status=mixed.

THIN-PA-STABLE-01 — single-key cache operations route by affinity on стабильный topology

Требование: Для стабильных топологий, partition-aware routing должен обрабатывать primitive keys, complex keys, affinity-key annotations/configuration, replicated caches, backup counts, node filters, и custom affinity mapper cases.

Зачем это нужно: Приложения get lower-latency routing без manually selecting server endpoints.

Граница: В основном свидетельство: routing/protocol behavior является asserted more directly than operation result semantics.

Тесты-доказательства:

THIN-PA-GROUPING-01 — affinity mappings являются reused only когда compatible

Требование: The client должен группировать caches с equivalent affinity mappings и request separate mappings когда effective affinity differs.

Зачем это нужно: This limits metadata traffic без routing requests через an incompatible mapping.

Граница: Свидетельство из protocol/request-count assertions; не доказывает все custom affinity combinations.

Тесты-доказательства:

THIN-PA-AUX-OPS-01 — scan query, set и atomic-long operations participate где supported

Требование: Partition-bound scan queries, IgniteSet operations, collocated sets, и AtomicLong reads должен use affinity-aware routing in проверенные cases.

Зачем это нужно: Non-cache-key APIs должен benefit из affinity metadata когда their data placement является known.

Граница: Свидетельство: доказывает routing participation, не full semantic correctness of каждый operation.

Тесты-доказательства:

THIN-PA-TOPOLOGY-01 — routing refreshes после topology/session changes

Требование: The client должен обновлять or recreate routing state после connection loss, node join/leave, cluster restart с lower/same topology version, session close-before-handshake, и create-session-after-close.

Зачем это нужно: Long-running clients должен continue routing correctly после operational topology changes.

Граница: Weaker где tests exercise timing/session races и fallback paths; точные fallback target является не always established.

Тесты-доказательства:

THIN-PA-MULTIDC-01 — data-center aware routing выбирает configured local endpoints

Требование: With multi-DC settings, partition-aware и non-partition-aware requests должен prefer allowed/local endpoint sets и обрабатывают no-node-in-DC cases as проверенные.

Зачем это нужно: Операторы can bias thin-client traffic toward the intended data center.

Граница: Более слабое свидетельство для configured examples only; не outage-handling or fairness guarantee.

Тесты-доказательства:

THIN-PA-RES-METRICS-01 — resources и metrics reflect partition-awareness lifecycle

Требование: Partition-awareness resources должны освобождаться после client close/cache destroy, metrics должны считать affinity hits/misses, и balancing должен распределять connections in the проверенные setup.

Зачем это нужно: Пользователям нужны observable routing quality и без retained routing state после lifecycle cleanup.

Граница: Свидетельство: balancing является scenario-bound и не general fairness proof.

Тесты-доказательства:

Важные границы