Bài 10: Khóa phân tán (Distributed Lock) - Giải quyết Race Condition trong Microservices
Mục tiêu bài học: - Hiểu rõ bài toán Race Condition khi scale ứng dụng lên nhiều server (Microservices). - Nắm vững 3 nguyên tắc sống còn của một Distributed Lock an toàn. - Tự build cơ chế Distributed Lock bằng go-redis và kịch bản Lua (Lua Script). 1. Nỗi đau mang tên Race Condition trong Microservices Giả sử bạn có một trang TMĐT. Sản phẩm "iPhone 16" chỉ còn đúng 1 chiếc trong kh... Chi tiết
Xóa thẻ HTML khỏi chuỗi trong JavaScript: đừng dùng regex, và cũng đừng dùng div
Thỉnh thoảng mình lại gặp một yêu cầu nghe rất đơn giản: lấy một đoạn HTML và trả về chữ thuần. Ví dụ trang danh sách bài viết cần hiển thị đoạn trích ngắn của từng bài, nhưng nội dung gốc lưu trong database lại là HTML từ trình soạn thảo. Mình chỉ cần phần chữ, không cần , hay .
Bài này ghi lại vài điều nên làm và không nên làm khi viết hàm stripHtml(), dựa trên một bài viết của...
Chi tiết
# Bài 16 — Trang giỏ hàng & đặt hàng
⬅️ Bài trước | Mục lục | Bài tiếp theo ➡️ 🎯 Mục tiêu - Dựng bảng giỏ hàng: sửa số lượng, xóa sản phẩm, tính tổng tiền - Dùng Modal của Bootstrap để nhập thông tin giao hàng - Gửi đơn hàng lên API và xử lý kết quả - Sửa lỗi công thức tính tiền theo size — không nhất quán trong source gốc ⚠️ 1. Vấn đề công thức tính tiền theo size Đây là đoạn trong source gốc, trong cột "Đơn Giá": Viết lại c... Chi tiết
# Bài 15 — Sắp xếp & lọc sản phẩm (và sửa bug lớn nhất của dự án)
⬅️ Bài trước | Mục lục | Bài tiếp theo ➡️ 🎯 Mục tiêu - Hoàn thiện sidebar: nút sắp xếp và ô lọc khoảng giá - Mổ xẻ 3 bug thật trong Productlist của source gốc - Viết lại Productlist đúng chuẩn với useMemo - Hiểu vì sao useRef là lựa chọn sai ở đây Đây là bài quan trọng nhất về mặt tư duy trong toàn bộ tài liệu. Bạn sẽ học cách nhìn ra bug mà mắt thường không thấy. 💻 1. Hoàn thiện sidebar C... Chi tiết
# Bài 14 — Lưu giỏ hàng khi F5 với redux-persist
⬅️ Bài trước | Mục lục | Bài tiếp theo ➡️ 🎯 Mục tiêu - Hiểu vấn đề: state Redux mất khi tải lại trang - Cấu hình redux-persist để lưu vào localStorage - Dùng PersistGate để chờ dữ liệu được khôi phục - Xử lý cảnh báo serializable và lỗi hydration 📚 1. Vấn đề Thử ngay: thêm vài sản phẩm vào giỏ, rồi bấm F5. → Giỏ hàng về 0. Vì Redux store nằm trong bộ nhớ RAM của trang web. Tải lại trang =... Chi tiết
# Bài 13 — Redux Toolkit & giỏ hàng
⬅️ Bài trước | Mục lục | Bài tiếp theo ➡️ 🎯 Mục tiêu - Hiểu vì sao cần Redux khi đã có useState - Nắm 4 khái niệm: store, slice, action, reducer - Viết cartSlicer với các thao tác thêm/xóa/sửa/xóa hết - Nối Redux vào ứng dụng bằng Provider - Navbar hiện số lượng giỏ hàng, nút "Thêm vào giỏ" hoạt động 📚 1. Vì sao cần Redux? Vấn đề: state cần chia sẻ giữa các component xa nhau AddCardbutton ... Chi tiết
Greenplum Database - Bài học 5: Interconnect Layer: Giao thức mạng nội bộ (UDP/TCP) giúp các Segment giao tiếp tốc độ cao
Ở các bài học trước, chúng ta đã biết dữ liệu của một bảng lớn được băm nhỏ và rải đều ra hàng chục đến hàng trăm Segments độc lập (Shared-Nothing). Mỗi Segment chỉ nhìn thấy phần dữ liệu nằm trên ổ cứng của riêng mình. Vậy điều gì sẽ xảy ra khi bạn chạy một câu lệnh JOIN hai bảng với nhau (ví dụ: SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id), trong khi dòng đơn hàng của kh... Chi tiết
Greenplum Database - Bài học 4: Segment Instances (Primary & Mirror): Nơi dữ liệu thực sự sống và cơ chế tự phục hồi
Ở Bài học 3, chúng ta đã khám phá "bộ não" Master Node (Coordinator) — nơi nắm giữ bản đồ toàn cục nhưng không lưu trữ bất kỳ một dòng dữ liệu người dùng nào. Vậy hàng chục Terabyte hay hàng tỷ bản ghi thực sự nằm ở đâu? Câu trả lời chính là ở tầng Segment Instances. Nếu Master là vị tướng chỉ huy, thì các Segments chính là đội quân công nhân tinh nhuệ trực tiếp giữ kho lương thực (dữ liệu) và... Chi tiết
Greenplum Database - Bài học 3: Master Node (Coordinator) & Standby Master: Bộ não điều phối truy vấn và quản lý Metadata
Ở Bài học 2, chúng ta đã biết một cụm Greenplum hoạt động theo mô hình "Chỉ huy và Quân đoàn". Trong đó, hàng chục đến hàng trăm Segment phía dưới gánh vác phần nặng nhất là lưu trữ dữ liệu và tính toán cơ bắp. Tuy nhiên, một đội quân hùng hậu sẽ trở nên hỗn loạn nếu thiếu đi người chỉ huy. Đó chính là vai trò của Master Node (từ phiên bản Greenplum 7 trở đi được đổi tên chính thức thành Coordi... Chi tiết
Greenplum Database - Bài học 2: Giải phẫu kiến trúc MPP (Massively Parallel Processing): Cách Greenplum chia để trị hàng tỷ bản ghi
Ở Bài học 1, chúng ta đã biết một máy chủ PostgreSQL đơn lẻ dù mạnh đến đâu cũng sẽ gục ngã trước bức tường băng thông ổ cứng (Disk I/O) khi phải quét hàng chục Terabyte dữ liệu. Để vượt qua giới hạn vật lý đó, Greenplum sử dụng kiến trúc MPP (Massively Parallel Processing — Xử lý song song quy mô lớn). Vậy bên dưới nắp capo, kiến trúc MPP thực sự hoạt động như thế nào? Nó khác gì so với các k... Chi tiết
Greenplum Database - Bài học 1: Greenplum là gì? Tại sao PostgreSQL đơn lẻ không đủ cho bài toán Data Warehouse quy mô lớn?
Khi xây dựng các hệ thống phần mềm, hầu hết chúng ta đều bắt đầu với một cơ sở dữ liệu quan hệ (RDBMS) quen thuộc như PostgreSQL hoặc MySQL. Ở giai đoạn đầu, khi dữ liệu chỉ vài chục Gigabyte hoặc vài triệu bản ghi, mọi thứ chạy cực kỳ mượt mà chỉ với vài chỉ mục (Index) được tối ưu tốt. Nhưng khi hệ thống phát triển lên quy mô hàng tỷ bản ghi (tương đương hàng chục đến hàng trăm Terabyte dữ l... Chi tiết
Amazon Aurora MySQL Bài 33: Sử dụng AWS Schema Conversion Tool (SCT) khi chuyển đổi cơ sở dữ liệu sang Aurora MySQL
Ở Bài 32, chúng ta đã tìm hiểu cách di chuyển dữ liệu từ một hệ thống MySQL truyền thống sang Aurora MySQL thông qua DMS. Tuy nhiên, trong thực tế vận hành tại các doanh nghiệp lớn, bài toán migration không chỉ dừng lại ở việc chuyển dữ liệu (Data Migration), mà còn phức tạp hơn rất nhiều khi bạn phải chuyển đổi cấu trúc cơ sở dữ liệu và mã nguồn lập trình bên trong (Schema & Code Conversion) –... Chi tiết
Amazon Aurora MySQL Bài 32: Chiến lược Migration dữ liệu không gián đoạn từ MySQL truyền thống sang Aurora MySQL
Khi công ty quyết định nâng cấp hệ thống từ cơ sở dữ liệu MySQL truyền thống (chạy trên EC2, RDS MySQL tiêu chuẩn, hoặc On-Premise) lên Amazon Aurora MySQL để tận dụng hiệu năng vượt trội và kiến trúc phân tán, bài toán lớn nhất đặt ra cho đội ngũ kỹ thuật là: Làm sao để di chuyển hàng trăm GB dữ liệu mà hệ thống backend KHÔNG PHẢI DOWNTIME (hoặc downtime dưới vài giây)? Bài viết này sẽ mổ xẻ ... Chi tiết
Amazon Aurora MySQL Bài 31: Cơ chế Automated Snapshots và Point-in-Time Recovery (PITR) trong Aurora MySQL
Trong vận hành hệ thống production, việc thực hiện sao lưu dữ liệu (Backup) và khả năng khôi phục hệ thống về một thời điểm trong quá khứ (Point-in-Time Recovery) là chiếc phao cứu sinh cuối cùng khi xảy ra các sự cố thảm họa như lệnh DELETE nhầm không có WHERE, lỗi code deploy làm hỏng dữ liệu, hoặc tấn công mã hóa tống tiền. Bài viết này sẽ mổ xẻ cơ chế chụp ảnh tự động và phục hồi siêu tốc ... Chi tiết
Amazon Aurora MySQL Bài 30: Tổng kết Module 3 & Điểm chuẩn hiệu năng toàn diện trên Aurora MySQL
Sau 10 bài học liên tục mổ xẻ từ tầng phần cứng (Buffer Pool, Cơ chế Storage Quorum) đến tầng phần mềm và ứng dụng (Advanced Query Optimization, Performance Insights, CloudWatch Monitoring, RDS Proxy, Indexing Strategies, và Bulk Write Optimization), chúng ta đã có một bức tranh toàn diện về cách vận hành, tinh chỉnh và khai thác tối đa sức mạnh của Aurora MySQL ở cấp độ Senior/Backend Engineer... Chi tiết
Amazon Aurora MySQL Bài 29: Tối ưu hóa ghi dữ liệu Write-heavy: Batch Insert, Bulk Update và tối ưu hóa Transaction
Trong khi các bài trước tập trung chủ yếu vào việc tối ưu hóa tốc độ đọc (SELECT), thực tế vận hành tại các hệ thống thương mại điện tử lớn (như quản lý hàng tồn kho, ghi nhận log sự kiện, hoặc lưu lịch sử giao dịch) thường xuyên phải đối mặt với các đợt ghi dữ liệu cường độ cao (Write-heavy workloads). Nếu viết code xử lý ghi không khéo, bạn sẽ nhanh chóng làm nghẽn băng thông mạng, tràn hàng ... Chi tiết
Cấu trúc dữ liệu và Giải thuật Bài 58: Cây Phân Đoạn (Segment Tree) - Xử lý truy vấn khoảng dữ liệu (Range Queries) siêu tốc.
Bước sang Chương 12 với các cấu trúc dữ liệu nâng cao, chúng ta đối mặt với một bài toán kinh điển trong các hệ thống phân tích dữ liệu thời gian thực (Real-time Analytics) và giám sát hạ tầng: Range Query (Truy vấn khoảng dữ liệu). Giả sử bạn đang quản lý hàng triệu bản ghi doanh số theo thời gian thực tại Hasaki. Hệ thống cần liên tục thực hiện 2 thao tác với tần suất cực cao: 1. Update (C... Chi tiết
Cấu trúc dữ liệu và Giải thuật Bài 57: Băm nhất quán (Consistent Hashing) - Cân bằng tải và phân phối dữ liệu trong hệ thống phân tán.
Trong các bài học trước, Bảng băm (Hash Table) và hàm băm truyền thống đóng vai trò định vị dữ liệu dựa trên công thức: Index = Hash(Key) % N (với là số lượng server hoặc số bucket). Công thức này hoạt động hoàn hảo trong môi trường đơn máy (Single-node). Tuy nhiên, khi hệ thống backend phát triển thành một cụm Hệ thống phân tán (Distributed System) gồm nhiều cụm Redis, nhiều Shard Database,... Chi tiết
Cấu trúc dữ liệu và Giải thuật Bài 56: Bộ lọc Bloom (Bloom Filter) - Kiểm tra sự tồn tại xác suất siêu tốc và tiết kiệm RAM.
Trong suốt Chương 8, chúng ta đã xem Bảng băm (Hash Table) là tiêu chuẩn vàng để kiểm tra sự tồn tại của dữ liệu với tốc độ . Tuy nhiên, khi quy mô hệ thống chạm ngưỡng hàng chục hoặc hàng trăm triệu bản ghi (ví dụ: danh sách hàng trăm triệu tài khoản user đã đăng ký trên hệ thống của Hasaki, hay danh sách đen các URL độc hại trên Internet), việc lưu trữ toàn bộ chuỗi Key vào RAM để tra cứu bằn... Chi tiết
Cấu trúc dữ liệu và Giải thuật Bài 55: Lập trình động Bottom-Up (Tabulation) - Tối ưu không gian và vòng lặp.
Ở Bài 54, chúng ta đã làm quen với Lập trình động theo trường phái Top-Down (Memoization): Bắt đầu từ bài toán lớn, dùng đệ quy bẻ nhỏ nó ra và lưu kết quả vào một bảng đệm (Map) để tránh tính toán trùng lặp. Tuy nhiên, Top-Down vẫn mang trong mình một điểm yếu mang tính cấu trúc: Nó phụ thuộc vào Call Stack của hệ điều hành. Nếu bài toán yêu cầu độ sâu đệ quy quá lớn (ví dụ ), hệ thống sẽ lập... Chi tiết
Nếu bạn muốn được huấn luyện/Mentor/Coaching hoặc hợp tác với chuyên gia hàng đầu về lập trình ==>Hãy đăng ký bên dưới nhé!
ĐĂNG KÝ/LIÊN HỆ:
- 21 Lê Văn Lương, Phường Nhân Chính, Thanh Xuân, Hà Nội.
- hotrotudaotao@gmail.com
- DINH FAMILY lIBRARY
- YouTube
