플래시 킬 시스템 설계

프로모션 시스템 설계에 대한 기사를 쓴 적이 있고 깜짝 세일/직할인/주화수안을 언급했는데, 실제 업무에서 플래시 세일 시스템을 실제로 해본 적이 없어서 간단한 플래시 세일 시스템을 상상해봤습니다. "Quiet the Greed" 프로모션 아이디어는 여전히 이전 기사의 디자인을 따릅니다.

분석

플래시 세일 중에 대량의 트래픽이 유입됩니다. 플래시 세일이 시작되기 전에 쿼리가 자주 새로 고쳐집니다. 많은 양의 트래픽이 즉시 데이터베이스에 도달하면 데이터베이스가 붕괴되기 매우 쉽습니다. 따라서 플래시 세일의 주된 임무는 트래픽을 레이어별로 필터링하고 최종적으로 최대한 작고 온화한 트래픽을 데이터베이스에 입력시키는 것입니다. 일반적인 플래시 세일은 많은 수의 사용자가 소량의 상품을 낚아채는 경우입니다. 이러한 요구에 따라 단순히 인벤토리를 캐싱하면 실제로 주문을 생성하기 전에 많은 양의 트래픽을 필터링할 수 있습니다. 하지만 그래도 전혀 어려울 것 같지는 않네요! 난이도를 조금 더 올려보자면, 우리의 플래시 세일이 샤오미 휴대폰을 잡는 것과 같다고 가정하면, 100만 명이 휴대폰 10만 대를 잡는다면 어떨까요? 샤오미 급하게 세일할 때 줄을 서서 기다리는 것도 하나의 방법이고(경험이 별로 좋지는 않지만), 앞으로 우리의 플래시 세일 디자인은 이 아이디어를 기반으로 할 것입니다.

샤오미 얘기를 하다가 "행운도 힘의 일부다!"라는 걸 알게 됐어요.

프론트엔드 전류 제한 방식: random(0, 1): axios.post: wait(30, '모든 것이 끝났습니다!')

몇 가지 코드 세부 사항부터 분석해 보겠습니다. 원칙적으로는 원래 비즈니스 로직을 최소한으로 변경해야 합니다.

또한 다음 글에는 서비스 서킷 브레이커, 멀티레벨 캐싱 등 고급 게임플레이가 없고, 비교적 단순한 비즈니스 설계일 뿐입니다.

Start운영자는 백그라운드에서 플래시세일 프로모션에 변형을 추가하고, 플래시세일 재고/플래시세일 할인율/시작 시간 및 종료 시간 등을 설정합니다. 이런 데이터를 얻을 수 있습니다.

// promotion_variant (促销和变体表「sku」的一个中间表)
{
    'id': 1,
    'variant_id': 1,
    'promotion_id': 1,
    'promotion_type': 'snap_up',
    'discount_rate': 0.5,
    'stock': 100, // 秒杀库存
    'sold': 0, // 秒杀销量
    'quantity_limit': 1, // 限购
    'enabled': 1,
    'product_id': 1,
    'rest': {
        variant_name: 'xxx', // 秒杀期间变体名称
        image: 'xxx', // 秒杀期间变体图片
    }
}

플래시 세일 프로모션이 성공적으로 생성된 후 가장 먼저 프로모션 정보를 캐시하는 것입니다

# PromotionVariantObserver.php

public function saved(PromotionVariant $promotionVariant)
{
  if ($promotionVariant->promotion_type === PromotionType::SNAP_UP) {
    $seconds = $promotionVariant->ended_at->getTimestamp() - time();

    \Cache::put(
      "promotion_variants:$promotionVariant->id",
      $promotionVariant,
      $seconds
    );
  }
}

주문하기

기존 주문 인터페이스를 사용하면 변형 정보를 받은 후 현재 변형이 무엇인지 알 수 없습니다. 프로모션에 참여한 목록은 여기에서 판단 작업에 많은 수의 데이터베이스 쿼리 작업이 필요합니다.

그래서 여기서는 플래시 세일을 위한 새로운 API를 작성합니다. 프런트 엔드에서 현재 변형이 플래시 세일 프로모션에 있음을 감지하면 플래시 세일 주문 API로 전환합니다.

물론, 우리는 여전히 원래 주문 API를 사용하고 있으며 프런트 엔드에 로고를 전달하는 데 문제가 없습니다.

한 가지 설명해야 할 점은 주문이 일반적으로 두 단계로 나누어진다는 것입니다.

첫 번째 단계는 결제 주문을 생성하는 "결제"입니다. 사용자는 주소, 쿠폰, 결제 방법 등을 선택할 수 있습니다. .

두 번째 단계는 "확인"입니다. 이때 주문이 확인되고 재고가 잠기며 사용자는 결제를 할 수 있습니다. 일반적으로 규정된 시간 내에 결제가 이루어지지 않으면 주문이 취소되고 재고가 잠금 해제됩니다.

따라서 첫 번째 단계에서는 주소 및 쿠폰 선택과 같은 후속 작업이 데이터베이스에 영향을 미치지 않도록 사용자를 필터링하고 대기열에 넣습니다.

# CheckoutController.php

/**
 * @param Request $request
 * @return \Illuminate\Contracts\Routing\ResponseFactory|\Illuminate\Http\Response
 * @throws StockException
 */
public function snapUpCheckout(Request $request)
{
    $variantId = $request->input('variant_id');
    $quantity = $request->input('quantity', 1);

    // 加锁防止超卖
    $lock = \Cache::lock('snap_up:' . $variantId, 10);

    try {
        // 未获取锁的消费者将阻塞在这里
        $lock->block(10);

        $promotionVariant = \Cache::get('promotion_variants:' . $variantId);

        if ($promotionVariant->quantity release();

            throw new StockException('库存不足');
        }

        $promotionVariant->quantity -= $quantity;

        $seconds = $promotionVariant->ended_at->getTimestamp() - time();
        \Cache::put(
            "promotion_variants:$promotionVariant->id",
            $promotionVariant,
            $seconds
        );

    } catch (LockTimeoutException $e) {
        throw new StockException('库存不足');

    } finally {
        optional($lock)->release();
    }

    CheckoutOrder::dispatch([
        'user_id' => \Auth::id(),
        'variant_id' => $variantId,
        'quantity' => $quantity
    ]);

    return response('结账订单创建中');
}

플래시 세일 체크아웃 API에는 데이터베이스 작업이 포함되지 않은 것을 확인할 수 있습니다. 그리고 주문을 생성하는 작업은 Dispatch를 통해 Queue에 배분되며, 사용자는 Queue에 입장한 순서대로 해당 시간 동안 줄을 서서 기다립니다.

이제 질문은 주문이 성공적으로 생성된 후 고객에게 어떻게 알릴 수 있느냐는 것입니다.

클라이언트 알림

여기서 해결 방법은 폴링이나 웹소켓에 불과합니다. 여기서는 서버 성능을 덜 소모하는 웹소켓을 선택하고 laravel에서 제공하는 laravel-echo(laravel-echo-server)를 사용합니다. 사용자의 플래시 세일이 성공하면 프런트엔드와 백엔드가 웹소켓 링크를 설정합니다. 백엔드 결제 주문이 성공적으로 생성되면 프런트엔드에 다음 단계를 진행하라는 알림이 전달됩니다.

Backend

다음으로 백엔드에서 해야 할 일은 "CheckoutOrder" 작업의 주문이 성공적으로 생성된 후 웹소켓의 해당 채널에 "OrderChecked" 이벤트를 보내 결제 주문이 생성되었음을 나타내는 것입니다. 사용자는 다음 단계를 진행할 수 있습니다.

# Job/CheckoutOrder.php

// ...

public function handle()
{
  // 创建结账订单
  // ...

  // 通知客户端. websocket 编程本身就是以事件为导向的，和 laravel 的 event 非常契合。
  event(new OrderChecked($this->data->user_id));
}

// ...

# Event/OrderChecked.php

class OrderChecked implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    private $userId;

    /**
     * Create a new event instance.
     *
     * @param $userId
     */
    public function __construct($userId)
    {
        $this->userId = $userId;
    }

    /**
     * App.User.{id} 是 laravel 初始化时，默认的私有频道，直接使用即可
     * @return \Illuminate\Broadcasting\Channel|array
     */
    public function broadcastOn()
    {
        return new PrivateChannel('App.User.' . $this->userId);
    }
}

현재 구매한 사용자 ID가 1이라고 가정합니다. 요약하면 위 코드는 "OrderChecked" 이벤트를 websocket의 비공개 채널 "App.User.1"에 푸시하는 것입니다.

Front end

아래 코드는 vue-cli 도구를 사용하여 초기화된 기본 프로젝트입니다.

// views/products/show.vue

<script>

import Echo from &#39;laravel-echo&#39;
import io from &#39;socket.io-client&#39;
window.io = io

export default {
  name: &#39;App&#39;,
  methods: {
    async snapUpCheckout () {
      try {
        // await post -> snap-up-checkout
        this.toCheckout()
      } catch (error) {
        // 秒杀失败
      }
    },
    toCheckout () {
      // 建立 websocket 连接
      const echo = new Echo({
        broadcaster: &#39;socket.io&#39;,
        host: &#39;http://api.e-commerce.test:6001&#39;,
        auth: {
          headers: {
            Authorization: &#39;Bearer &#39; + this.store.auth.token
          }
        }
      })

      // 监听私有频道 App.User.{id} 的 OrderChecked 事件
      echo.private(&#39;App.User.&#39; + this.store.user.id).listen(&#39;OrderChecked&#39;, (e) => {
        // redirect to checkou page
      })
    }
  }
}
</script>

laravel-echo를 사용할 때 주의할 점은 비공개 채널을 사용하기 때문에 laravel-echo는 인증을 위해 기본적으로 서버 API

에 게시 요청을 보낸다는 것입니다. 그러나 블레이드 템플릿 대신 프런트엔드 및 백엔드 범주가 사용되기 때문에 필요한 인증을 수행하기 위한 csrf 토큰과 세션을 쉽게 얻을 수 없습니다.

그래서 브로드캐스트 및 laravel-echo-server의 구성을 약간 수정해야 합니다

# BroadcastServiceProvider.php

public function boot()
{
  // 将认证路由改为 /api/broadcasting/auth 从而避免 csrf 验证
  // 添加中间件 auth:api (jwt 使用 api.auth) 进行身份验证，避免访问 session ,并使 Auth::user() 生效。
  Broadcast::routes(["prefix" => "api", "middleware" => ["auth:api"]]);

  require base_path('routes/channels.php');
}

// laravel-echo-server.json

// 认证路由添加 api 前缀，与上面的修改对应
"authEndpoint": "/api/broadcasting/auth"

/broadcasting/auth인벤토리 잠금 해제

이 주문에 대해 "인벤토리"가 잠겨 있는 경우 연결이 끊어지면 사용자는 인벤토리를 잠금 해제해야 합니다. 웹소켓 연결이나 장기간 방치로 인해 의미없는 인벤토리 점유를 방지합니다.

여기서의 인벤토리는 데이터베이스 인벤토리가 아닌 캐시 인벤토리를 의미합니다. 이때는 주문이 성공적으로 생성되더라도 여전히 체크아웃 상태(주소, 결제수단 등이 선택되지 않은 상태)이기 때문에 개인센터에서는 보이지 않기 때문입니다. 데이터베이스 인벤토리는 사용자가 주문을 확인한 경우에만 잠깁니다.

따라서 여기서 이상적인 구현은 사용자가 웹소켓 연결을 끊은 후 주문의 잠긴 인벤토리를 반환하는 것입니다. 결제 주문이 생성된 후 오랫동안 운영되지 않은 주문에 대한 재고를 반환하기 위해 지연 대기열이 생성됩니다.

하지만 laravel-echo는 브로드캐스트 시스템이며 클라이언트 연결 해제 이벤트에 대한 콜백을 제공하지 않습니다. laravel-echo-server Add와 같이 laravel이 수신하는 클라이언트 이벤트를 구현하는 몇 가지 방법이 있습니다. laravel에 알리는 후크가 필요하지만 laravel-echo-server의 구현을 수정해야 합니다. 여기서는 플래시 세일 아이디어를 제공하는 데 중점을 두지 않겠습니다.

Summary

위 그림은 플래시 킬 시스템의 논리적 요약입니다. 이 시점에서 전체 플래시 세일 과정은 끝났습니다. 일반적으로 코드의 양은 많지 않으며 로직도 비교적 간단합니다.

그림에서 볼 수 있듯이 전체 프로세스에서는 대기열에서만 mysql과 상호 작용합니다. currentlimit을 통해 최대 범위에 적응합니다. MySQL의 경제성. mysql 성능이 충분할 때 사용자는 동시에 많은 수의 대기열을 통해 주문을 소비할 수 있으며 사용자는 대기열 프로세스를 전혀 인식하지 못할 것입니다.

질문이 있거나 더 좋은 아이디어가 있으면 토론을 위해 메시지를 남겨주세요~

더 많은 라라벨 관련 기술 기사를 보려면 라라벨 튜토리얼#을 방문하세요. 🎜🎜#칼럼.

위 내용은 플래시 킬 시스템 설계의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!