Re: [請益] 後端工程師除了CRUD之外還要精進什麼?

[ybite (小犬/小B)]

隨便試著寫一下考卷 賺個P幣

※ 引述《taliao (雲淡風清)》之銘言：
: 有趣的問題，來一些激盪吧～
: Q: 你怎麼知道 CRUD 分別吃多少系統資源？需要多少 IOPS / CPU?
: Q: 承上，要如何知道 CURD 吃了哪些資源？
: Q: 承上，怎麼解開這些資源的分配問題？
其實這題超難回答。實務上會分為 Script 所吃的資源跟儲存對象所吃的資源。
Script 來說 Python/Ruby/Node.js 等每個 Process 都會吃到 CPU + 記憶體
儲存對象除了 CPU 跟記憶體之外也會吃到 Disk I/O。

當你做 Create 的動作時，Script 端會需要用 CPU 跟記憶體去運算邏輯
把插入的指令傳給資料庫，資料庫除了 CPU 運算，以及將資料寫入磁碟的 I/O 外
還會視資料庫的索引跟快取優化去做其他優化的記憶體/磁碟 I/O 運算

因此一個準確的 IOPS/CPU 不太容易得出，但是我們可以透過系統監測
透過實質的 CPU、記憶體、I/O 使用率去得到系統大致的運轉狀態
並使用資料庫系統的 EXPLAIN 得知儲存上的瓶頸點

: Q: 1 個連線的 CRUD、10 個連線的 CRUD、100 個的 CRUD ..... 類推，
:    他們的架構是怎樣？

很簡單的 CRUD

            1 個連線
1個實體 =============== DB

實務上的 CRUD 架構

Load balancer -- A XX個實體 == 連線 Pool == DB with sharding
              -- B XX個實體 == 連線 Pool ==
              -- C XX個實體 == 連線 Pool ==
              -- D XX個實體 == 連線 Pool ==


: Q: CRUD 的對象是 RDBMS? NoSQL? Block Storage? Cache? Buffer?
: Q: 承上: CRUD 的對象怎麼選？我只會 MySQL 啦，都往裡面塞就是了 .....

這題每個人答案應該都不一樣，以下是我個人見解。
Block Storage 跟 Buffer 我不知道他想表達什麼，先 Skip QQ

RDBMS 解決問題的方式是透過表格與關聯，複雜的查詢可以透過 JOIN 關聯解決。
通常適用於大多數的使用情境，但需要定義固定 Schema 是一個考量點。

NoSQL 要視其使用的資料結構和分散式儲存的策略來選擇
嚴格說來某些 Cache (e.g. Redis) 甚至都可以算是一種 NoSQL 了

你需要儲存簡單的資料結構就可以塞在 Redis
你需要一個給我 JSON 內容我就可以塞進去的儲存空間就可以用 MongoDB

: Q: 前端怎麼知道 CRUD 瓶頸在哪？

最爛的答案：開發者工具，看哪一個 Request 吃掉最多秒數......

: Q: CRUD 的操作對象，不管是 RDBMS, NoSQL, Storage, Cache，
:    瞬間流量衝進來怎麼處理？會遇到什麼問題？
: Q: 線上的系統 CRUD 出問題了，怎麼知道哪裡出問題？

就像連假高速公路塞車一樣，一超出設計極限，哪邊就會炸掉
這個時候就要找出系統的瓶頸點，試著去一個一個解決問題

首先你 Script 的執行實體夠不夠多？不夠的話就會塞在最前面
這個時候的症狀是你的 QPS (等待人數) 很多，但你的櫃台開不夠多所以塞住
這個時候就要打一個 Process Manager 讓它 Spawn 好幾個實體進去

如果櫃台都開很多了，結果每一個櫃台處理業務的時候都後台當住
這個時候就要思考 Storage 上是不是有瓶頸點

首先，在 DB 跟 Script 之間要不要做 Connection Pool
再來，你有沒有優化資料庫的 Query？哪些 Query 特別慢？
EXPLAIN 出來發現哪裏有問題？要怎麼打 Index 或著重新設計結構來優化？

: Q: 當現有的架構要拆分的時候 (microservices)，你的 CRUD 還是 CRUD?

我的猜測：嚴格說來還是 CRUD
只是本來單一架構中不同資料的互動，會變成不同微服務之間的溝通

: Q: 當系統是分散式的時候，CRUD ... 要怎麼辦？

我不知道怎麼回答 QQ

: Q: 你的 CRUD 考慮的是 ACID or BASE? 還是這啥？

ACID 是傳統 RDBMS 為了資料安全性做的保障
BASE 是 NoSQL 為了犧牲一部份保障換取更高效率或擴張性做的妥協
願不願意接受這個妥協要視服務本身的特性而定

如果你的資料量非常大，而且可以接受幾微秒的資料不一致性，那 BASE 就可以了

: Q: 寫十年的 CRUD 然後都做一樣的事情？那中年一定失業。
:    但是可以處理瞬間百萬 qps 的 CRUD，你中年一定很忙。
: 下一系列的 Q
: Q: 哪裡有百萬 qps 的系統啊？qps 是啥？
: Q: 當有的時候，你準備好了嗎？
: Q: 台灣沒有百萬的 qps 啊，國外有，你準備好了嗎？
: Q: golang 很屌，可處理百萬 qps，是這樣？node.js 不行？C# 不行？
: Q: 買一台 2048 core 的機器就可以搞定了，需要說那麼多嗎？ .....
: ....

其實我覺得任何程式語言處理百萬 QPS，技術上只要機器夠大就可以
但是你了不了解這個程式語言的特性，它能做什麼，怎麼優化它
才是一個長期而且可能沒有盡頭的學問

如果你的框架很大，如何優化記憶體使用？
你的程式語言是編譯的還是直譯的？如果是直譯，直譯器有沒有 JIT？
記憶體如何管理/需不需要 GC？如何偵測 Memory Leak？

這些問題的答案會隨你用的程式語言跟框架而不同
而同樣的機器可以應付多少 Request per sec 也隨技術上花了多少力氣而不同

---
大概是這樣，鞭小力一點 QQ

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.168.79.225
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1527961025.A.BC9.html
推 locklose: 推
推 dsilver: 推
推 vn509942: 感謝分享
推 bheegrl: 推分享
推 handwu: 推
推 showken: 推
推 lds74: 推分享
推 APTON: 推
推 devilkool: 感謝分享
推 Ekmund: 雖說是最爛的答案 但前端有什麼更好用的手段嗎QQ？
推 accessdenied: 前端可以學一下Jmeter瞭解怎麼做壓力測試和統計分析
推 ripple0129: 分散式CRUD是啥，還是單一資料庫吧，不然consistency
→ ripple0129: 處理起來要人命吧。多資料庫也是按照商業邏輯來拆分
→ ripple0129: 關聯性。
推 akito117: 推
→ free112136: 前端用jmeter做壓力測試？小弟愚昧，還請accessdenied
→ free112136: 演示一下用jemter測"前端"的"壓力"測試
→ alan3100: saga pattern 如何在分散式系統實現trans或部分rollback
推 accessdenied: @free哥你是要測瀏覽器的壓力還是測backend的壓力？
→ accessdenied: 這篇在說後端喔！如何從前端測後端CRUD的壓力，中
→ accessdenied: 文去唸唸好嗎？找碴也不用秀閱讀障礙吧？
推 free112136: 你回文自己說前端，是你不會說話還是我有閱讀障礙就
→ free112136: 看各位看官的心理那把尺嘍
推 accessdenied: 文章是「前端怎麼知道CRUD的瓶頸」這句話你有閱讀
→ accessdenied: 障礙吧？CRUD會發生在前端嗎？文章也討論從Request
→ accessdenied:  time判斷了，你閱讀能力這麼差一定是歪國人
→ accessdenied: Jmeter就是一個end to end從前端來觀測後端效能的工
→ accessdenied: 具，麻煩月領30K的不要出來丟臉好嗎？
→ accessdenied: 300萬和30K之間沒有溝通頻率好嗎！
推 free112136: 300萬原來是這樣崩潰的…你繼續吧！
推 accessdenied: 你也繼續領30K吧......
推 wanlinlin: 推