소스가 죽으면 캐시로 이어가기

우열 없음 async

요구사항

라이브 주문 피드가 업데이트 세 건을 전달한 뒤 연결이 끊어집니다. 대시보드에는 여전히 처음 여섯 행이 필요합니다: 라이브 피드가 전달해 낸 것은 모두 유지하고, 그다음은 어젯밤의 캐시 스냅숏에서 이어가되 그 행들에 (from cache) 표시를 붙이세요. 실패는 코드에 결정적으로 주입되어 있으며, 두 버전 모두 예상 출력 아래에 표시된 줄들을 출력해야 합니다.

예상 출력

ORD-7011 packed
ORD-7012 shipped
ORD-7013 packed
ORD-7014 picking (from cache)
ORD-7015 picking (from cache)
ORD-7016 received (from cache)

나란히 보기

RxDart

FxDart

import 'package:fxdart/fxdart.dart';

/// The live order feed: three updates arrive, then the connection dies.
Stream<String> liveFeed() async* {
  yield 'ORD-7011 packed';
  yield 'ORD-7012 shipped';
  yield 'ORD-7013 packed';
  throw StateError('feed connection lost');
}

/// Last night's cached snapshot of the rest of the queue.
const cachedTail = [
  'ORD-7014 picking',
  'ORD-7015 picking',
  'ORD-7016 received',
  'ORD-7017 received',
];

Future<void> main() async {
  // Pull from the live feed until it dies, keeping everything it managed
  // to deliver — the loop is the explicit error boundary.
  final live = <String>[];
  try {
    await for (final update in liveFeed()) {
      live.add(update);
    }
  } on StateError {
    // The feed died — resume from the cached tail below.
  }

// The dashboard shows the first six updates; take(6) means the cache is
  // only pulled as far as needed — and nothing here is async anymore.
  final updates = fx(live)
      .concat(fx(cachedTail).map((u) => '$u (from cache)'))
      .take(6)
      .toList();

updates.forEach(print);
}

차이가 나는 이유

이것은 오류 채널이 가장 빛나는 순간입니다. 복구 지점이 스트림 전체 단위입니다 — "이 소스가 죽으면 시퀀스의 나머지는 저 소스로 전환한다" — 푸시 오류 채널이 모델링하는 바로 그 모양입니다. onErrorResumeNext는 요구사항 전체를 연산자 하나로 말합니다: 값은 손대지 않고 통과하고, 첫 오류가 구독을 진행 중에 복구 스트림으로 갈아 끼우며, 이미 전달된 세 건의 업데이트는 안전하게 지나가 있습니다.

풀 쪽에는 나중에 오류를 던지는 소스의 값들을 지켜 주는 연산자가 없습니다 — 풀 파이프라인은 오류를 풀 지점에서 드러내고, 실패한 toList는 그전에 온 것들을 버렸을 것입니다. 그래서 경계를 직접 써 내려갑니다: await for 루프가 라이브 행들을 모으고, try/catch가 실패에 이름을 붙이고, concat + map + take가 캐시된 꼬리를 이어 붙입니다. 정직한 두세 줄이 더 들 뿐 — 어휘 하나가 빠진 같은 복구입니다.

우열을 가리기 어렵고, 우아함에서는 RxDart 쪽으로 살짝 기웁니다. 양쪽 모두 여섯 행에서 멈추고, 어느 쪽도 페이지에 필요한 만큼을 넘어 캐시를 읽지 않습니다: 한쪽에서는 take가 구독을 취소하고, 다른 쪽에서는 그저 풀기를 멈춥니다.

벤치마크

Apple M1 Max, RAM 32 GB · Dart 3.12.2 (AOT 컴파일) · 2026-08-18

비동기 예제입니다. 대표 스케일이 1,000,000이 아니라 N = 10,000인 이유 — 원소 하나마다 양쪽 모두 이벤트 루프를 한 바퀴 돌아야 하므로, 실제 await 백만 번은 파이프라인이 아니라 Dart 이벤트 루프를 몇 분씩 재게 됩니다. 지연은 0으로 두고 예제의 동시성 제한은 그대로 유지합니다. 막대가 비교하는 것은 파이프라인 기계 장치 자체입니다.

N = 100

시간 무승부

RxDart 28 µs

FxDart 26 µs

최대 메모리 무승부

RxDart 16.5 MB

FxDart 16.6 MB

N = 10,000

시간 무승부

RxDart 1.80 ms

FxDart 1.97 ms

최대 메모리 무승부

RxDart 23.2 MB

FxDart 23.7 MB

막대는 사이드별로 새 프로세스에서 반복 측정한 중앙값입니다(작은 N은 타이머 해상도를 위해 배치 처리). 두 사이드가 서로 5% 이내이거나 — 사람이 지각할 수 없는 차이인 0.6ms 이내이면 — 무승부로 칩니다. 상대 차이가 근소한 경우는 최대 5회까지 다시 측정합니다. 앱에서는 어느 막대가 짧든 몇 밀리초 이하의 차이는 사용자에게 보이지 않습니다. 메모리는 프로세스 최대 RSS입니다. Dart VM과 데이터셋은 양쪽이 동일하므로, 두 막대의 차이가 곧 파이프라인 자체가 붙들고 있는 양입니다.