|
| 1 | +# Policy snapshot lifecycle |
| 2 | + |
| 3 | +This module implements version-isolated policy snapshots. Each snapshot owns a RocksDB detail |
| 4 | +store, a bitmap index, and the incremental-message position at which both were built. |
| 5 | + |
| 6 | +## Integration flow |
| 7 | + |
| 8 | +1. Implement `FullPolicyLoader` to stream the full-data cut into `PolicySnapshot.upsert` and |
| 9 | + return the cut's message position. |
| 10 | +2. Implement `IncrementalReplayer` to apply upserts/deletes after that position. The builder |
| 11 | + repeats replay until it reaches a stable latest position. |
| 12 | +3. Supply `DefaultSnapshotValidator` (or a stricter domain validator), a |
| 13 | + `FileSystemSnapshotDirectory`, and construct `SnapshotBuilder`. |
| 14 | +4. Call `PolicySnapshotService.start(version)` during startup. Keep the application's readiness |
| 15 | + probe bound to `service.isReady()`; failures remain unready and retry. |
| 16 | +5. Call `refresh(newVersion)` at runtime. A failed candidate is discarded. A valid candidate is |
| 17 | + atomically activated while the old snapshot continues serving existing leases. |
| 18 | +6. Every search must use `try (SnapshotLease lease = registry.acquire())`. Releasing the last old |
| 19 | + lease closes RocksDB and deletes that retired version's directory. |
| 20 | + |
| 21 | +The module intentionally leaves message-broker and full-data-source clients behind interfaces so |
| 22 | +the snapshot consistency rules are independent of Kafka, HTTP, database, or framework choices. |
| 23 | + |
| 24 | +## Package layout |
| 25 | + |
| 26 | +- `api`: serializable Dubbo contract and request/response DTOs. |
| 27 | +- `rpc`: Dubbo search provider and supplier callback provider. |
| 28 | +- `aggregation`: Redis-backed fan-out/fan-in search coordination and local waiters. |
| 29 | +- `redis`: atomic Lua state transitions and Pub/Sub early wake-up. |
| 30 | +- `demo`: asynchronous downstream supplier simulation. |
| 31 | +- `kafka`: JSON policy-change consumer and message DTO. |
| 32 | +- `application`: startup and incremental-update use cases. |
| 33 | +- root `policy` package: versioned RocksDB/Bitmap snapshot domain and lifecycle. |
| 34 | + |
| 35 | +Kafka messages use a globally monotonic `position` so duplicate/out-of-order delivery is ignored. |
| 36 | +If the topic has multiple partitions, the producer must supply this global sequence; otherwise the |
| 37 | +position model should be replaced with a per-partition offset map. |
| 38 | + |
| 39 | +## Async supplier search |
| 40 | + |
| 41 | +`asyncSearch` initializes pending suppliers, state and result TTL atomically in Redis, registers a |
| 42 | +local waiter, double-checks Redis, then dispatches all supplier tasks. Supplier callbacks append |
| 43 | +result chunks and remove a supplier from the pending set only on its final callback. The Lua script |
| 44 | +sets `COMPLETED` and publishes `search-finished` when the last supplier finishes. Pub/Sub only wakes |
| 45 | +the local waiter early; Redis remains the source of truth and is checked every 200 ms. Timeout is |
| 46 | +also a Lua state transition and returns all partial results already recorded. |
0 commit comments