Redis là gì? Bài học này đủ để bắt đầu | Là một Backend bạn đã từng gặp những trường hợp này chưa?
HTML-код
- Опубликовано: 27 сен 2022
- Redis là gì? Nếu đơn giản chỉ làm Cache thì Một Backend đã không đổ máu với giờ cao điểm lad WRITE.
Video thuộc series: "Lộ trình trở thành Backend với những kiến trúc".
Phần 1: [Lộ trình trở thành BACKEND Developer TÔI đã quyết tâm khi nhìn thấy kiến trúc của hệ thống này]( • Lộ trình trở thành BAC... )
Phần 2: [Backend Developer Nếu ai hỏi xong LoadBalancer rồi thì CHÚNG TA sẽ làm gì? Hãy đưa video này cho họ]( • Cách thiết kế hệ thống... )
Phần 3: High Availability là gì? Tiết lộ CÔNG THỨC tính cho phép hệ thống DIE mỗi NĂM vs 3 cách triển khai ( • High Availability là g... )
Phần 4: Api Gateway kết hợp Backend for FrontEnd (BFF) như HỔ mọc thêm CÁNH | Lộ trình trở thành Backend. - • Api Gateway kết hợp Ba...
Phần 5: Redis là gì? Nếu đơn giản chỉ làm Cache thì Một Backend đã không đổ máu với giờ cao điểm lad WRITE | • Redis là gì? Bài học n...
🚩 Subscribe ➜ / tipsjavascript
#redis #cache #api
✅ Follow Me:
Blog: anonystick.com
Facebook: / tipjs
RUclips: / tipsjavascript
Một người rất tâm huyết cống hiến cho cộng đồng. Hy vọng có ngày nào đó có cơ hội giao lưu.
Hay quá anh ơi. Cảm ơn anh ạ
Quá mê luôn anh ơi, a dạy dễ hiểu, cụ thể, chi tiết và rất thực tế❤
Một kênh quá hay ạ
quá hay anh ạ, hóng video Rabbit MQ của a
Tuyệt vời anh ơi!
Hay quá, cảm ơn Anh
Cảm ơn tác giả nhiều.
Vừa hay. Vừa hài. Cảm ơn thầy nhìu lắm!
Hài chỗ nào vậy em?
Quá hay luôn ạ ❤
Không đơn thuần là nói về Redis, anh nói về kiến trúc thực tế rất hữu ích. Cảm ơn anh :v
Cảm ơn bạn đã quan tâm
Rất hay thầy ạ. Cảm ơn thầy rất nhiều
Cảm ơn bạn
rất hay và chi tiết ạ
cảm ơn anh đã chia sẽ
Qúa hay, cảm ơn anh đã chia sẽ
Cảm ơn em
Đúng lúc đang tìm hiểu về Redis. Cảm ơn anh rất nhiều, mong anh ra nhiều video bổ ích hơn nữa ☘
Redis này nó nhìn vậy chứ ko đơn giản
hay quá anh ơi
cảm ơn anh, nếu có thời gian rảnh hy vọng a có video về HA Redis ah.
Mới xong á em
tôi sai, tôi sai :)) Cảm ơn a đã chia sẻ. Chúc a sức khoẻ
Rất hay ạ
Quá hay ạ🎉🎉🎉
Ngồi cả ngày nghe thầy giảng cũng được nữa.Nghe xong đầu óc thông thoáng hẳn ra.😂
Tks bạn. Mới có video mới hén
Cảm ơn thầy
Hay quá a ơi
Thật hả?? Kkk tks em
Em vào xem vì anh để tiêu đề gắt quá :). =============>10 điểm
Một trong những kênh dạy lập trình nói tiếng Việt chất lượng nhất.
Cảm ơn thầy
Cảm ơn em đồng hành
thấy trước khi tìm hiểu gì mà xem thầy là thấy hay vl , có hứng thú học vl luôn =))) , kênh chất lượng quá thầy ơi
Cảm ơn bạn... Vui vì giúp được bạn..
cảm ơn anh
Cảm ơn em
hi anh, series này khá là thú vị và hay.
anh có thể gom các video liên quan trong series này và đưa vào 1 playlist để em or mọi người tiện follow tuần tự không ạ.
_Thanks a_
Quá xịn luônnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
Quá hay.
Quá hay anh ơi
Tks em nhiều!
Thanks
Video anh rất thực tế, RapidMQ và Message Queue em đang tìm hiểu mong anh có thể sớm chia sẻ những kiến thức thực tế xây dựng hệ thống lớn như vậy. Cảm ơn anh rất nhiều
Ok Đức. Chiến
@@anonystick Nếu được anh làm thêm về kafka và event-driven architecture được không ạ?
Kiến thức anh chia sẽ rất hay, các bài toán này khả năng cũng là các vấn đề chung cho các hệ thống eCommerce, chắc cũng đã có nhiều lời giải, nhiều công cụ như anh nói trên. Cái chính là hiểu rồi nhưng làm sao để có cơ hội triển khai vậy anh, rất nhiều ông lớn đã có trên thị trường : ) .
Bạn phải tìm giải pháp mới chứ, các tips anh chỉ ko chỉ ứng dụng eCommerce đâu??
thank a nhiều
Em học được thêm bài học về giải quyết vấn đề bằng đổi thứ tự của các thao tác ạ. Em cảm ơn anh đã chia sẻ đến mọi người. Em chúc anh và gia đình nhiều niềm vui và sức khoẻ ạ ^^
cảm ơn người anh em
hay quá
chung quy lại vấn đề về việc dùng cache ở đây chính là ở câu chuyện consistency data của cache so với dữ liệu thực, nên vấn đề ở đây phải xử lý được khi xảy ra high concurrency là tìm cách consistency đc data. Theo mình nghĩ là nếu cả 2 ghi cùng lúc thì nên del key trong cache đi chắc cx đc : ) mình thì ko rõ lắm vì cx mới học
rat bo ich, mong a them phan code thuc hanh cho newbie nhu bon e hieu them a
Hay quá a. e có 1 vấn đề mong được a giải đáp ạ. nếu trong trường hợp cache miss cao hơn cache hit thì tốc độ của nó sẽ chậm hơn. vậy có cách nào để biết được tỉ lệ giữa cache miss và cache hit kh a, từ đó mình sẽ biết trường hợp nào nên sử dụng cache và trường hợp nào kh cần sử dụng cache ạ!
Sư phụ giải thích dễ hiểu thật. Ngu như Em mà vẫn hiểu đc
Cảm ơn em
Mặc dù kênh anh là tips javascript nhưng em thấy kênh anh có rất nhiều kiến thức có thể áp dụng cho các ngôn ngữ khác.
Đúng á em. Quan trọng là logic thuật toán, còn ngôn ngữ là công cụ
nghiệp vụ thi những ngôn ngữ nào cũng tương tự cơ chế như nhau mà
Giải pháp lưu trữ cache của anh hay quá, nhưng có 1 điều là làm tăng thời gian của request, set cache, delete cache, vs rabbitmq sẽ có độ trễ.
Buông và nắm. Chấp nhận thôi em à. Hi
Qúa đẳng cấp, cảm ơn tiền bối.
Tks bro
Cám ơn video của a đã đưa ra kiến trúc tối ưu nhất cho việc sử dụng redis, db, message brocker.
Chỗ sử dụng rabbitMQ đồng bộ data từ db vào redis em tìm cũng ít thông tin, và implement nó có vẻ cũng phức tạp. Cần add trigger vào save của những thằng mình muốn cache à a?
Em thấy mô hình cuối cũng ko đảm bảo. G/s CR7 đã set db và delete cache. M10 miss cache, read DB, chuẩn bị set lại cache. Ngay trc khi M10 set cache, CR7 set db giá trị mới, rồi delete cache. Sau đó, M10 mới thực hiện set cache, thì nó set vào redis giá trị cũ, trong khi DB có giá trị mới rồi. Khả năng M10 khi read db, phải lock luôn row đó, set cache xong thì release lock. Như vậy, đảm bảo ko ai có thể xen vào giữa quá trình read db và set cache.
Do vậy ta mới hướng hệ thống ecommerce về thiết kế event.
Hi anh sau khi nghe video anh chia sẽ em rút ra 2 kết luận, xin các anh chị cho ý kiến:
1. Vấn đề trong việc săn voucher trên UI hiển thị còn lại 3 mà click vô thì đã hết hàng là do nó get cache cũ.
2. Redis đóng vai trò trong việc đồng bộ hóa data cho cache. Bảo đảm tính nhất quán của cache và DB.
Xin các anh chị cho ý kiến. Em xin cảm ơn.
Mình nghĩ redis chỉ đóng vai trò như 1 cache db cho phép truy vấn và ghi dữ liệu nhanh hơn, còn việc đồng bộ giữa cache và mysql db thì do rabbitmq chịu trách nhiệm
anh ơi tất cả các video của anh từng đăng đều nằm trên kênh đúng không anh
Em chào anh. A ơi, theo như em hiểu thì video này đang giải quyết cho TH W/R đồng thời. Vậy TH W/W đồng thời ở phút 12 của video thì giải quyết ntn ạ.
Em cám ơn anh. Chúc a và gđ năm mới sức khỏe và thành công.
giai thich dai dong
Hi anh, cảm ơn anh về bài chia sẻ rất hay ạ , nhưng anh cho em hỏi thêm xíu ở cái đoạn cuối thêm message queue , mục đích và ý nghĩa thêm nó vào ở đây làm gì ạ. Cảm ơn anh nhiều , mong anh hồi đáp ạ
Anh làm thêm redis stack anh ơi.
Có mà...
Video của anh rất thực tế. Em chỉ thắc mắc một chỗ trong mô hình mà a suggest, tại sao ta không set lại cache sau khi đã set db mà đợi đến bước thứ 4 để làm điều đó, cảm ơn anh!
tôi nghĩ là nó nhanh, thời gian nó read nhanh hơn thời gian mà cache nó update, mỗi lần read, update nên check xem cache đã là mới nhất hay chưa, chứ nếu update luôn sang cache thì cần gì phải check xem cache đã là mới nhất chưa (quan điểm cá nhân)
vậy là db dự liệu quan trọng hơn, còn cache chỉ là bộ nhớ tạm thôi
Chính xác. Đều bữa này cài cloud cũng rẻ nên chơi đi em
Anh làm thêm về RabbitMQ đi ạ
Ok bạn. Chờ vài video hén
Hi Típ! A hướng dẫn quá hay về cách bán thời gian.. e vô tình lướt ngang tìm hiểu về lập trình web, và đang mong lung ko biết học lập trình web bắt đầu từ đâu, nhờ A hướng dẫn tư vấn bước đi sao vững ạ! Thân chào A hồi đáp!
Pm Anh hen em
Vấn đề không phải là ở cache mà đơn giản là hai user dùng chung một resource ( ở đây là db ) nên mới đẻ ra vấn đề conflict. Nên cách giải quyết ở đây là người ta mới dùng event bus ( như rabitMQ hay kafka ) để đảm bảo các consumer ( ở đây là user ) có tính nhất quán với nhau trọng việc nhận sự kiện ( update DB ) thát zít
😅
Like
Cho mình hỏi, tại Hình cuối cùng, tại bước 5 set Cache. chỗ này là DB sẽ kết nối với Redis cache để set data hay là 1 ứng dụng(java, c#) thực hiện kết nối ?
7:25 Hình số 3 này sao lại là "Write and write cache" vậy ạ? Em tưởng nó vẫn là "Read and write cache" giống hình 2 nhưng trong tình huống quá trình write cache diễn ra chậm chưa thực hiện được bước "set db" thôi chứ ạ ?
6:00 Tại sao trong sơ đồ "read vs write cache", mình không bỏ bước del cache, thay vào đó khi set db thì sẽ set cache luôn ạ?
Hình cuối hơi sai sai anh ơi chỗ này như mô hình thì đâu cần RabbitMQ ??
anh ơi cụ thể con RabbitMQ kia chi tiết như nào ạ
anh ơi em đọc bố gì bảo 'trời hôm nay đẹp quá' xong mới chết
lúc nào cũng vì 1 nguyên nhận nào đó mạng chậm @@ ví dụ 7 bước thì 7! trường hợp do mạng chậm ạ =(((
cho e hỏi mình chỗ dùng rabbit mq database đã update CR7 rồi là từ db trigger qua rabbit mq để cập nhật lại cache hả anh? Hay là mình dùng backend call qua rabbit mq để cập nhật lại cache ạ?
Anh cho em hỏi thêm với ạ giả sử như shoppe họ cache sản phẩm như thế nào ạ? Vì thực tế số lượng sản phẩm rất lớn nếu cache toàn bộ sản phẩm trên redis và thực hiện lấy sản phẩm kèm filter, order trên code thì tốc độ em nghĩ rất chậm
Em cảm ơn anh vì những kiến thức này ạ. Không biết em có thể tham gia nhóm discord của mình được không ạ. Nếu có thì anh có thể cho em xin link để tham gia được không ạ
Link tag giới thiệu đó em. Tks em!
Hi anh, trong video anh có nói delete cache thì tốt hơn set cache ghi đè lên, cho em hỏi tại sao lại tốt hơn ạ?
Thanks anh.
set cache là một hoạt động tiêu tốn thời gian nhiều hơn là delete. Thử hình dung tính toán phức tạp về số...
Anh ơi, anh có thể giải thích giúp em cơ chế Redis loại bỏ đi các dữ liệu đã đạt tới thời gian hết hạn không ạ ?
Ok em
Bucket Design Pattern Mongodb anh chưa làm phần update, delete 1 element trong mảng không biết là anh có thể nói nhanh hướng làm được không ạ
Chưa có thời gian á bạn
Cache của user nào thì user đó set chứ sao lại user này set cache của user khác nhỉ?
Tất nhiên rồi. Cache là in ram memory
A ơi, cho tôi hỏi heathcheck tôi dùng Redis để check Ck được không
Backend thì ghi đồng thời vào db và cache chứ không nhất thiết phải chờ queue xử lý
Cuộc sống quá đẹp
non quá. Có là ghi đồng thời, chấp thread update db khởi chạy trước thì vẫn thua thread redis trong thời gian đó các lệnh update redis khác vẫn ập vào làm lệch data với db. Đó là vấn đề tương tự như race condition khá cơ bản
u la troi .a ra toan clip hay ko
U là trời là phú yên à?
@@anonystick da ko SG a :))) u la trời
@@baole2691 so cute :)
Ở sơ đồ cuối cùng ấy anh, cần gì phải để RabbitQP ở đó nhỉ, sau khi lưu vào DB xong thì update lại cached luôn ạ ?
Ngoài ra nếu để nhất quán dữ liệu nhất có thể giữa Redis và Mysql thì e có thêm phương án là:
Ngay ở bước đầu tiên, chúng ta sử dụng lock. Cr7 hoặc M10, ai thực hiện việc write trước thì sẽ tạo ra cặp key value như sau: lock_product_01: true
Rồi sau đó mới bắt đầu việc update database và update lại Redis và xong thì xoá key trên
Thằng đến sau thì check xem đã tồn tại key lock_product_01 hay chưa, nếu có rồi thì đợi (dùng message broker), còn chưa có thì xử lý việc update database & Redis
anh cho ý kiến ạ
nếu như lock lại thì trong trường hợp mạng kém, sẽ làm treo hệ thống!
Em thấy nhiều video của anh hay nhưng title nhiều cái video nó không hợp lí lắm nên khó tiếp cận lắm anh.
Nghĩa là title khó hiểu à em? Để anh khắc phục
Đối với đồ án tốt nghiệp ở đại học của em thì em nên tích hợp redis này kh ạ. Em cảm ơn a
Luôn đi em... CHo thầy ngỡ ngàng..
Hi anh, anh đang dùng theme gì của vscode vậy ạ?
em cám ơn
Cobalt2 nha em
anh cho em hỏi người mới học back end thì học từ playlist nào vậy ạ em cảm ơn anh nhiều
Đây em. Chúc em vui vẻ... ruclips.net/p/PLw0w5s5b9NK4ucXizOF-eKAXKvn9ruCw8
@@anonystick a ơi em mới học c c++ python cấu trúc giữ liệu giải thuật trên trường điểm tương đối cao với cả em tự học css với html và 1 chút js cơ bản thì có nên học node js luôn ko a hay là học thêm cái gì trc ạ
Db làm cách nào set đc cache vậy a
Câu hỏi hay. Chuẩn bị nha em
Mô hình cuối, lúc M10 đọc trong cache thì miss cache, lúc đó xuống db read data. Vậy bước nào để rabbit mq update data từ db lên cache.
Từ sql to redis nha Toàn.
Set binlog thì càng tốt
😅 đến học code cũng gặp fan Cr7
ở mô hình cuối tại sao lại có rabbitmq ở đó vậy ạ
RabbitMQ có nhiệm vụ điều phối, ví dụ 1giây chỉ cho phép 10 thằng làm việc...
A cho e hỏi một tí như a bảo là tối ưu nhất là set db trước rồi mới update cache như vậy thì mỗi lần thao tác mình lại xuống db query dẫn đền làm mất hết tác dụng của cache là làm cho thao tác của mình nhanh hơn, e nghĩ vậy, thanks a đã đọc câu hỏi của một đứa fresher như a ạ 🙇
vẫn query trên cache chứ bạn
Làm như này thì cũng chỉ chậm ở lần đầu tiên request, ở những request sau thì cache vẫn có tác dụng mà và còn đảm bảo được tính nhất quán của data.
Không phải xuống DB Query bạn ạ. Khi query mình vẫn query ở cache trước, nếu miss cache thì mới query trong db sau đó set lại cache. Trường hợp của anh Tips chỉ ra là khi mình cập nhật db (nghĩa là write) thì sẽ phải cập nhật trong db trước, sau đó xóa cache chứ không phải ngược lại
cho em hỏi là các request get list thì mình có nên cache ko ạ. nếu có thì cache kiểu gì ạ
Để cache một list thì nó phải là list không thay đổi. Ví dụ lịch sử mua chứng khoán ngày 01 đến 30. Thì em có cache theo query theo ngày vì lịch sử không có đổi về giao dịch chứng khoán. Còn mà list thay đổi liên tục như new feeds của FB thì em không thể. Or phải dùng cách pull or push.
@@anonystick em cảm ơn ạ
không có thực hàng nên sẽ rất khó xác thực lý thuyết này
anh nói khó hiểu quá
hay quá anh ơi
Cảm ơn em!