12 Matching Annotations
  1. Jul 2025
    1. Examples

      題目沒有寫清楚!!

      output是每次滑動時,最大數串起來的字串。 第一次最大數是4 第二次最大數是5

      結果就是 45

    1. Identify if repeatedly computing the sum of squares of the digits of number 191919 results in 111.

      如果最後能得到 1,那這個數就是快樂數;否則它會陷入一個無限循環的數列。

      🔄 所有數的命運只有兩種:快樂與非快樂數。

      💡 思路: 設一個 slow 指針:每次走一步(算一次數字平方和) 設一個 fast 指針:每次走兩步(算兩次平方和)

      📌 判斷條件: 如果 slow 先到 1 或是 fast 先到 1 → 是快樂數 ✅ 如果 slow 和 fast 在 1 以外的數字相遇 → 出現循環 ❌(不是快樂數)

    2. Finally, the result is processed using the slowPointer, which often points to a meaningful position, such as the middle of the structure or the start of a cycle.

      想像跑操場的樣子

    1. Given SQS's built-in support for retries and exponential backoff and the ease with which visibility timeouts can be configured, we'll use SQS for our system.

      解釋架構圖

      這張架構圖描繪了一個以 Amazon SQSAmazon S3 為核心的網頁爬蟲與解析系統流程。以下是詳細解釋,並結合你提到的 Kafka 與 SQS 的特性來比較:


      🧭 架構流程說明:

      1. DNS → Webpage
      2. 系統首先透過 DNS 解析目標網頁的網域名稱。

      3. Crawler - Fetch & Store Webpage

      4. 爬蟲從網頁抓取 HTML 資料,並將其儲存到 S3 HTML Data
      5. 同時更新 URL Metadata,記錄該 URL 的狀態與最後爬取時間。

      6. Parsing Worker

      7. 從 S3 下載 HTML,解析出文字內容。
      8. 將解析後的文字儲存回 S3。
      9. 若解析過程中提取出新的 URL,則會將這些 URL 放回 Frontier Queue (SQS),以便後續爬取。

      10. SQS Queues

      11. Frontier Queue:管理待爬取的 URL,具備「失敗重試」與「指數退避」機制。
      12. Parsing Queue:管理待解析的 HTML 任務。
      13. 若任務失敗,會進入 Dead Letter Queue (DLQ),以便後續排查或重試。

      🔁 Kafka vs SQS 比較與整合觀點:

      在這個架構中,由於爬蟲與解析任務是「任務導向」且需要「失敗重試」與「狀態確認」,使用 SQS 是更合適的選擇。Kafka 雖然強大,但在這種需要明確任務完成確認的場景中,SQS 的設計更簡潔且具備內建的可靠性機制。


      如果你想進一步了解如何將 Kafka 整合進這個架構(例如用於分析或即時監控),我也可以幫你設計一個擴充架構。你有興趣嗎?

    1. Random partitioning with no key: If you don't provide a key, Kafka will randomly assign a partition to the message, guaranteeing even distribution. The downside is that you lose the ability to guarantee order of messages. If this is not important to your design, then this is a good option.

      解釋與舉例 https://hackmd.io/_gx3rKjhQBKmF_mIcg0hJA?both#%F0%9F%94%B9-%E7%82%BA%E4%BB%80%E9%BA%BC%E3%80%8Crandom-partitioning-with-no-key%E3%80%8D%E6%9C%83%E5%A4%B1%E5%8E%BB%E9%A0%86%E5%BA%8F

    2. This should be the main focus of your scaling strategy in an interview and is the main decision you make when dealing with Kafka clusters (since much of the scaling happens dynamically in managed services nowadays).

      https://hackmd.io/_gx3rKjhQBKmF_mIcg0hJA?both#%F0%9F%94%B9-%E7%95%B6%E4%BD%A0%E4%BD%BF%E7%94%A8-Kafka-%E6%99%82%EF%BC%8C%E9%80%9A%E5%B8%B8%E6%9C%83%E5%B0%88%E6%B3%A8%E5%9C%A8%E5%A6%82%E4%BD%95%E6%93%B4%E5%B1%95%E3%80%8Ctopic%E3%80%8D%EF%BC%8C%E8%80%8C%E4%B8%8D%E6%98%AF%E6%95%B4%E5%80%8B-Kafka-%E9%9B%86%E7%BE%A4%EF%BC%88cluster%EF%BC%89%E3%80%82%E9%80%99%E6%98%AF%E5%9B%A0%E7%82%BA%E6%AF%8F%E5%80%8B-topic-%E7%9A%84%E6%B5%81%E9%87%8F%E5%92%8C%E9%9C%80%E6%B1%82%E5%8F%AF%E8%83%BD%E5%B7%AE%E7%95%B0%E5%BE%88%E5%A4%A7%E3%80%82